corpus: freeze the damage, patch one class at a time, and say where one rule stops

[gHashTag]

Closes #2160

Stacked on w699-restore-loop-tools (#2159), not on master — damage_repair.py imports the field extractor from diffbin.py, which lives on that branch. Base it on master and the import breaks. Review #2159 first.

No spec under specs/ is modified by anything here. Repairs are written to a scratch tree; specs/ is read-only to both new tools.

What the tools do

tri damage-freeze — writes the snapshot, 125 rows with class id, shape, file, line, field, verbatim rhs, ±2 lines of context, and the file digest. docs/corpus/damage_snapshot_2026-08-15.json, corpus_sha256 = 1b5a37b7a89efb782db7efd2ca7af728d4ed48b1c13ac2a35088c7926b16afd9.

tri damage-repair — one candidate per class, reversible diff, effect measured. Refuses to run if any file digest has moved since the freeze, because a patch applied to a changed file is applied to a different file than the one surveyed.

The mechanism

Intact: name : "TypeText",. Damaged: the opening quote became [. children : "[4]?QuadNode", → children : [[4]?QuadNode",. One fact, both signals, one-character patch, self-inverse.

The split, which is the result

	lines	classes
substitution yields a closed string → candidate proposed	107	12
type text truncated too, element type gone → no patch	18	3

[[]Const [, → "[]Const [, is not closed. []Const []Const u8 and []Const [N]u8 are both plausible; the file has no evidence. Held as needs-human-language-decision, owner: language owner. Criterion: state what an unclosed element type in slice position means and whether a placeholder is permitted.

Double validation

Deleting the line also makes a file parse. So: (1) t27c parse exits 0; (2) the field is back with a non-empty type and nothing previously present vanished.

Two units, because a hypothesis of mine was wrong

Per-class: 6 parse-restored, 6 still-malformed, 0 ambiguous, 3 needs-human-language-decision.

I read those six as co-located unrestorable damage. Checked: false — 0 destroyed lines across all seven files. Real cause: co-located damage from other restorable classes, untouched by a single-class run. Hence --combined:

effect	files
parse-restored	49
still-malformed	11
ambiguous	2
needs-human-language-decision	3

A third defect, visible only after the first two were fixed

10 of 11 remaining files fail at pub const Name(T) = struct { — Unexpected token in expression: KwStruct. Parser gap on generic const struct declarations, not corpus damage. bitset.t27 fails at Expected LParen, got KwTest — separate, unclassified. Both need their own issues; neither is in scope here.

Re-run differential

623 unchanged, 8 field-loss, 1 strict-improvement, 2 malformed-input-tradeoff, 0 unknown (was 616 / 13 / 1 / 4 / 0).

8 of 8 remaining field-loss files contain a destroyed line — exact correlation.

field-loss ≠ 0, so the gate on #2151 is not met. #2151 stays undecided and must not be merged.

Fixtures, tested rather than assumed

15 positive (one per class, carrying shape/origin/candidate/expected effect) + 6 negative pinning the false signals: target : < 5000ns, match arms, multi-line arrays, function signatures, raw strings, intact convention.

Discriminating power: reconstructed first signal set fires on 6 of 6 negatives, current on 0. On the real corpus naive = 1378 lines, current = 125.

loop-tools-tracked extended to both new tools and verified to FAIL (exit 1) while untracked and PASS after commit.

Not claimed

• Not that 125 is all the damage — two textual signals only; balanced, quote-even, plausible-looking wrong types are invisible and unbounded here
• Not that parser: nesting decides the separator, never the terminator (#2127) #2151 is regression-free
• Nothing about performance: 63 unparsed files still excluded from cost, full-run hang undiagnosed

fpga-formal / fpga-synthesis red is the master baseline (#2153). check-first-party-doc-language.sh has 8 pre-existing errors on master; none is a file from this branch.

[gHashTag]

Disclosure: this stacked PR is NOT gate-equivalent to a master-based one

gh pr checks on this PR lists nine checks, all green. Four of the checks that guard master did not run at all, and their absence is silent — a green tick sheet here does not mean what a green tick sheet on a master-based PR means.

Cause, read from the workflow files rather than inferred:

workflow	trigger
.github/workflows/now-sync-gate.yml (check-now-freshness)	pull_request: branches: [master]
.github/workflows/issue-gate.yml (check-linked-issue)	pull_request_target: branches: [master]
.github/workflows/seal-staleness-warn.yml	pull_request: branches: [master]

Base here is w699-restore-loop-tools, so none of them match. This is a general property of stacked PRs in this repository, not something specific to this branch, and it is worth knowing before any stacked PR is read as verified.

Ran the two content gates by hand instead, so the claim is measured rather than assumed:

• check-now-freshness: docs/NOW.md carries Last updated: 2026-08-15, inside the accepted [yesterday..tomorrow] UTC window (today UTC is 2026-08-14). New section is at the top of the file.
• check-linked-issue: PR body line 1 is Closes #2160, and corpus damage: freeze, per-class candidate patch, and what one rule does not reach (#2154 follow-up) #2160 exists and is OPEN. Verified in that order, because the gate passes on syntax alone and would accept a reference to an issue that was never created.
• seal-staleness-warn is not applicable: bootstrap/src/compiler.rs, bootstrap/stage0/FROZEN_HASH and repro/numerics/nmse_manifest.json are untouched by this branch.

Not verified by hand: whatever check and validate do beyond the above — those run under a different trigger set and their master-base behaviour on this diff is unmeasured. When #2159 lands, this branch will need retargeting to master and a real gate run before it can be called verified.