The Documentation Commit Pattern

In one line: Review code, relevant decisions/docs and verification together; keep each artifact in its authorized audience and source system.

For an affected boundary, the review package identifies:

1. The candidate code/configuration and intended behavior.
2. Relevant accepted intent/ADR revisions; proposed amendments need the responsible owner's approval.
3. Updated pages or a reasoned no-doc-change disposition.
4. Actual generation, build, link, test and rendered-output evidence, with scope and gaps.
5. Current work/decision pointers and an optional generated repository snapshot.

Private memory need not—and generally should not—be copied into a shared feature commit. A snapshot cannot contain its own commit hash. Preserve genuine audit/version history while keeping public presentation generic.

The doc-pointers manifest supports a scoped code-to-document presence check. When installed and invoked, templates/scripts/check-doc-sync.sh evaluates declared mappings; [skip-docs: <reason>] supplies a visible bypass receipt under the project's exception policy. It does not prove that a touched page is accurate or that a skip was semantically justified. Validate the selected revision range and manifest coverage.

Generated-freshness, link and ADR-register checks have similarly bounded claims. Effective CI requirements and bypass permissions require separate verification; a checked-in workflow is not proof of enforcement.