feedback_commit_message_must_match_frontmatter

If a commit message says “risk-register v1.1”, the risk-register’s own frontmatter must show version: "1.1" in the same commit. Updating only references to the file in other files (master-plan, arch-state) while leaving the file itself at v1.0 is a misleading commit-message that creates silent drift.

Why: Real incident discovered 2026-04-28T19:00 by Rich’s probe-question. Commit 92ec7a7 (2026-04-27, “docs: cross-file consistency cleanup (items 1-7) — arch-state v2.90 + risk-register v1.1 + topology v1.1 + cross-validation script”) claimed risk-register was bumped to v1.1 — but only updated references in arch-state + master-plan to “v1.1”. The actual risk-register/frontmatter stayed at version: "1.0" for ~12 hours. Master-plan v1.6 + v1.7 then pinned risk_register_version_pinned: "v1.1" against a file that was actually at v1.0. The cross-validation script validate-build-plan-sync.sh couldn’t catch this because it only checks BUILD-PLAN.md ↔ pointer ↔ master-plan coherence, not arch-state ↔ risk-register/repo-topology pin coherence.

How to apply:

1. When authoring a “cross-file consistency cleanup” commit, the file whose version is being bumped MUST have its frontmatter version field updated in the same commit. Updating only references in other files = lying.
2. Before committing a “v1.0 → v1.1” claim, git diff the file in question and confirm its frontmatter shows the new version
3. Forward fix: extend validate-build-plan-sync.sh to verify (a) every file’s frontmatter version matches what other files pin it at; (b) every companion_files.X.version_pinned entry matches the actual file X’s frontmatter version. Until that lands, the discipline is “Rich-asks-good-probe-questions” — works but doesn’t scale.
4. This is the same class of issue as the concurrent-session race lesson (commit-message claims don’t match commit content). Two cases in 24 hours suggests structural fix needed, not just discipline.