Review and release gates

Keep the change focused

Create a branch from the current canonical base and keep one reviewable milestone in the PR. Do not mix an approved documentation reorganisation with unrelated blog, search, paper-publishing, or engine implementation work merely because they share infrastructure.

Implementation and tests move together

Update the executable contracts that prove the new behaviour: unit/architecture tests, route and fragment checks, browser/accessibility tests, build validation, and visual baselines where appearance changes. Generated outputs must remain derived from canonical sources.

Visual changes require visual review

When a Web or diagram change affects rendering, GitHub Actions should publish review artefacts. A snapshot update is not evidence by itself: inspect the actual output, diagnose unintended changes, and only then commit the accepted baseline.

Evaluate the current head

Required checks must pass on the PR's current head. A green run for an older commit, a cancelled run, a stale baseline, or a partially successful matrix does not make the current change ready. Investigate failures rather than treating aggregate colour as the specification.

Public claims must match maturity

If implementation or measurement has not reached a claimed capability, keep the wording at research, proposal, decision, or design-contract level. A PR that changes public claims must update the corresponding metadata/evidence labels in the same review.

Ready means reproducible and reviewable

• Canonical sources and generated outputs agree.
• Required checks pass on current head.
• Visual artefacts exist and have been inspected when applicable.
• Routes, fragments, metadata, accessibility, and no-JavaScript meaning remain valid.
• Documentation/provenance reflects the actual implementation state.
• No superseded or speculative claim is silently promoted.

For the Web-specific command sequence, use Run the Web validation gate.