Three runs of tests/mutation_tests_fire_control_cut5.sh left mutated files on
disk (ArcAllowsFire hardcoded true in Weapon.cs, InstantWeapon.cs's arc gate
deleted, FireControl.cs still carrying 5.1's own mutation) despite its
`trap restore_all EXIT INT TERM`: a trap cannot survive a SIGKILL of the
process group, and nothing before this cut ever checked that a `cp -p`
restore actually reproduced the original bytes.
Records each target file's sha256 before any mutation runs. Every restore --
per-mutation, immediately after each check_mutation, and at exit -- re-hashes
and aborts loudly on a mismatch instead of trusting `cp -p` silently. The
final summary and the exit-time trap both print an explicit tree-clean
PASS/FAIL verdict so a reader never has to infer it. The no-op control stays
first, unchanged.
Investigated the two anchors reported as "found 0" (Zone.cs's Death
subscription, Weapon.cs's InArc line) before touching anything, per the
mandate not to hand-edit them into a shape that happens to match: on this
worktree at HEAD, both anchors are single-line literals with no embedded
newline, so CRLF-vs-LF in the surrounding file cannot affect whether the
substring is found -- the CRLF theory does not hold up. Both anchors match
exactly once against the current, clean tree (verified directly with the
same perl matcher this script uses, and confirmed by a full harness run).
The mutated replacement text for each of those two anchors is byte-for-byte
identical to the exact leaked mutation the task description names as having
been left on disk by an earlier run (Weapon.cs's `return true;`, Zone.cs's
deleted Death subscription) -- i.e. the "anchor never matches" failures were
not an independent matching-mechanism bug, but a direct symptom of the same
leaked-mutation-state problem this cut's hash verification now closes. No
anchor literal was changed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
35b8b6a550