Doc-honesty gates verify the generator's OUTPUT, never its CONTENT — load-bearing prose in a template is structurally invisible #880

The hole

Every generated-artifact freshness gate in this repo checks that the rendered artifact matches a re-render. None of them check the generator's own content. So any load-bearing claim that lives in a template renders "correctly" forever and cannot be caught.

Concretely: scripts/claim_check.py --emit-status renders scripts/templates/feature_matrix.md.tmpl → docs/status/FEATURE_MATRIX.md, and the staleness gate compares doc↔render. If the template prose is wrong, the render faithfully reproduces the wrong prose and the gate is green.

Why this is worth an issue rather than a patch

It has now produced the same class of defect in two consecutive releases, both caught only by a human-equivalent cold read at tag time:

• v0.51.0 — the matrix described shipped features ("div/rem", "popcnt", "calls") as "not yet" / "declined".
• v0.52.0 — the aarch64 row called linear-memory OOB-trap a "follow-on" while aarch64: linear-memory load/store emit NO bounds check and --safety-bounds is a no-op (all modes byte-identical) — OOB reads/writes up to 4GiB past the guest memory instead of trapping #865 shipped it as the enforcing default in that very release.

Both were one-line template fixes. The recurrence is the signal: the tooling cannot see this class, so it will keep happening.

The generalization

claim_check.py already does the right thing for numbers — it re-derives counts from the tree, so a stale number reddens CI. It does nothing for prose. And prose in this repo carries real claims: which ops lower, which decline, what is enforced vs. a follow-on. That's exactly the "honest decline" surface the project's identity rests on.

Possible directions (not prescribing)

1. Derive the capability prose the way counts are derived — e.g. generate the per-backend "supported / loud-declines" lists from the selector's own decline sites, so the matrix cannot claim something the code contradicts.
2. Cross-check prose against the oracles: if aarch64_bounds_865_differential.py exists and passes, a template asserting OOB-trap is a "follow-on" is a contradiction a gate could detect.
3. Pin claim-bearing template phrases in claims.yaml (the mechanism already exists) so changing a shipped capability forces a ledger bump.
4. At minimum: audit the remaining templates now for other load-bearing prose that no gate can see.

Filed off the v0.52.0 cold review, which put it well: "every generated-artifact freshness gate in this repo verifies the generator's output, never the generator's content."