Living document
Public Governance and Release Boundary
Public maintenance rules for SEO, llms.txt, i18n, design, and security boundaries.
Public surfaces move together
- When public routes change, update sitemap.xml, robots.txt, llms.txt, navigation, and footer links.
- Chinese and English pages must keep product claims, login boundaries, metadata, and calls to action semantically aligned.
- Design changes follow the shared TokenDance / AgentHub system and use TokenDance Blue instead of reintroducing the old purple accent.
- Public docs do not record production paths, secrets, private logs, or rollback commands.
Docs authoring rules
| Scenario | Must include | Must not include |
|---|---|---|
| Product page | Positioning, current status, entry point, target reader, and next step | Roadmap work written as completed |
| Integration page | base URL, environment variables, minimal verification, error triage, and credential boundary | Real keys, private hosts, or internal model names |
| Identity page | TokenDance ID OIDC, product-local session, and authorization boundary | Direct third-party OAuth in product apps or login as authorization |
| Experimental page | Experiment purpose, current capability, trial path, and low-commitment boundary | Enterprise SLA, stable marketplace, or default production support |
Pre-release checks
- Run lint, TypeScript, and build.
- Check /zh, /en, /zh/docs, /en/docs, and every changed zh/en docs route.
- Current key docs routes include /zh/docs/ecosystem-architecture, /en/docs/ecosystem-architecture, /zh/docs/gateway, /en/docs/gateway, /zh/docs/product-status, and /en/docs/product-status.
- Check llms.txt and sitemap.xml URLs against real routes.
- Add desktop and mobile screenshots when UI changes, confirming no overflow, old color drift, or incorrect login boundary.
Release gates
| Gate | Required proof |
|---|---|
| SEO / discovery | robots.txt, sitemap.xml, and llms.txt cover changed routes |
| i18n parity | Chinese and English claims, login boundaries, CTA, and metadata stay semantically aligned |
| Gateway wording | TokenDance API keys and TokenDance ID sessions are described as separate credentials |
| Identity boundary | Third-party providers belong to TokenDance ID; products consume OIDC |
| Security risk | Public repositories contain no secrets, private paths, real keys, or rollback commands |
| Visual QA | Homepage and docs routes pass desktop/mobile checks with no overflow or old purple drift |
Reader QA
- A first-time TokenDance reader can choose the right product from /docs.
- A model API reader can find Gateway base URL, key boundaries, SDK examples, and error-triage direction.
- A login integrator can explain the difference between TokenDance ID and product-local authorization.
- A reader of an experimental project can tell what is trial-ready and what is not a stable commitment.
Maintenance commands
powershell
pnpm build
# From the TokenDance workspace root
.\scripts\verify-public-surfaces.ps1
.\scripts\verify-i18n-parity.ps1
.\scripts\verify-design-tokens.ps1
.\scripts\verify-doc-freshness.ps1
.\scripts\verify-governance.ps1 -SkipDiffCheck