Maintain documentation content
Review documentation whenever a package release changes commands, stubs, compatibility, version, or architecture. The release-impact check proves this site consumes the synchronized manifest; core must separately enable its release trigger or required check.
Lifecycle and cadence
| Stage | Required evidence |
|---|---|
| Release planning | Core maintainer marks documentation impact and identifies affected manifest inputs. |
| Change review | Source revision, lastReviewed history, command/reference drift, and linked routes are checked. |
| Release validation | Link, coverage, budget, accessibility, security, and deployment evidence pass. |
| Periodic audit | Run a content audit every calendar quarter and on each release. Record owner, date, and findings privately. |
| Stale content | Flag an unreviewed source revision, broken link, unsupported version, or unverifiable claim. Name an owner and due date. |
| Retirement | Redirect only an approved replacement route, remove orphan assets and navigation, then re-run coverage and links. |
Staleness report
Use Git history for each page’s displayed review date, the generated manifest snapshot for its source revision, and the link and coverage checks for machine evidence. A page without attributable current evidence is stale; do not salvage old planning material into the public corpus.
Private launch evidence
Keep launch reports, audit findings, and maintenance calendar in the private roadmap repository. The public site documents the contributor workflow, not internal launch ceremony.