docs: adopt release-candidate closeout cadence

docs/PROJECT_ONBOARDING.md

@@ -255,6 +255,28 @@ layout.
 Done when a developer unfamiliar with the repository can use DocForge without loading the entire
 manual or inventing another documentation workflow.
 
+### 11. Release-candidate documentation cadence
+
+- [ ] Read the relevant canonical nodes during intake.
+- [ ] Record the expected documentation impact in the working plan.
+- [ ] Keep canonical sources and DocForge proposals unchanged during implementation and focused
+  test loops.
+- [ ] Freeze one release candidate after implementation stops changing.
+- [ ] Run the complete project gate, deployment preflight, candidate deployment, live checks, and
+  release-identity checks before proposing documentation updates.
+- [ ] Return to implementation when candidate validation fails.
+- [ ] Register one atomic changeset that covers every affected canonical node after the candidate
+  is green.
+- [ ] Inspect the exact diff and previews, then apply only the reviewed changeset hash.
+- [ ] Run documentation-only validation and render checks after application.
+- [ ] Permit at most one narrow evidence-only correction for facts that could not exist before
+  deployment.
+- [ ] Commit, tag, and publish the final revision only after implementation and canonical
+  documentation agree.
+
+Done when documentation describes the verified release candidate instead of intermediate attempts,
+and the project normally performs one canonical documentation write per release slice.
+
 ## CLI and MCP boundary
 
 Initial assessment and scaffolding belong to the CLI because an MCP server cannot be registered