--- name: scripted-edit-zero-match-refusal description: "scripted inserts convert \\n escapes to real linebreaks (mixed-EOL landmine units can't see); anchor-count refusal on zero/non-unique matches is the guard that catches it" metadata: node_type: memory type: feedback originSessionId: bcaec1f3-343d-4719-aa9d-1e1cb82b0e58 modified: 2026-08-03T13:08:22.863Z --- DOORBELL W2 leg 1 (todlando, 3ab9fe9): a scripted insertion converted intended `\n` escapes into REAL line breaks inside string literals. Correct only by luck — those source lines happened to end LF in an otherwise-CRLF file; any EOL normalization would push a stray `\r` into every rendered output on every platform, with units still green (`contains()` and `lines()` both tolerate either ending). **Why:** it surfaced ONLY because a mutation anchor written against the intended escape matched zero times and the script refuses to mutate on a non-unique/zero count. A scripted replace reporting success on zero matches hides this class entirely. **How to apply:** any scripted edit/mutation tooling must hard-fail on zero or non-unique anchor matches — the refusal is the detector, not an inconvenience. After scripted inserts into Rust string literals, verify escapes survived (grep for literal newline inside the quoted region or render-compare). Related: [[sweep-dispatch-site-counts]], [[render-not-read-pipefail]]. ⭐⭐ **AMENDED 2026-08-03 (#115 mutation battery): the refusal only works if you count the string you actually REPLACE.** I asserted a SHORT anchor (`unknown => eprintln!(`, count 1 → passed) and then `.replace()`d a LONGER block that matched nothing. Silent no-op; the test went green; I read that green as "the mutation SURVIVED, my probe is blind" and wrote it up as a finding. **No mutation had been applied — a green from unmutated code.** Assert on the *replacement's own* anchor, and assert `after != before` as a second belt. This is [[a-predicate-without-its-tool-is-not-evidence]] wearing a guard's uniform: the count I ran was real, it just answered a different question. ⭐ **Cause of the zero-match, worth its own line:** a **non-ASCII char (em-dash) in a heredoc did not survive the shell into python**, so the literal never matched the file's bytes. On this box, match anchors in scripted mutations must be **ASCII-only** — prefer a regex spanning from an ASCII prefix to an ASCII suffix (`re.S`) over pasting a block that contains prose punctuation. ⚠ **A mutation loop ending in `git checkout -- ` destroys UNCOMMITTED repairs to the very probe you are testing.** Mine did, so three variants silently re-ran against the OLD probe. Commit a probe fix BEFORE running the battery over it — see [[restore-step-presumes-committed-baseline]]. (The accident was informative rather than fatal, but that was luck.) ⭐⭐ **A `BTreeMap` fixture can mask a mis-seed by key ORDER.** Probing "an unknown key seeds no latch" with key `future_slot` alongside a legitimate `turn` entry: the seeder walks sorted, the mis-seed into `latch_turn` landed first and the legitimate `turn` **overwrote it**, so the final state was identical to correct. Name the adversarial key so it sorts **last** (`zz_…`), and assert the **whole state snapshot** against a hand-built expectation instead of naming latches one at a time. The variant the weak probe missed was the one a careless fix would actually produce; the two it caught seeded a slot the fixture never fills. ⭐⭐ **NEW FACE 2026-08-27 (todlando, IO-PARSER W2): the refusal FIRED and I could not see it, because the edit and the run were chained in ONE BACKGROUND JOB.** The command was, in effect: ``` cd $WT && python - <<'PYEOF' … PYEOF # the edit SP=…; cd $WT && { cargo nextest … > leg.raw; echo $? > leg.exit; } # the run ``` Two statements, not `&&`-joined — so when the edit died (`call site not matched`, and later a bare `ValueError: substring not found`) the run executed anyway, **on the unchanged tree**. Four consecutive iterations "measured" the same stale file and produced the identical failure, and I read each one as new evidence about the product. I even wrote up three sabotage mechanisms as "measured" that had never once been compiled. **Why the existing guards did not save me:** the anchor-refusal above WAS in the script and it worked perfectly — it raised. But its output went to the background job's `.output` file, which I never opened, while I diligently read the TEST's `.exit` file every round. This is the wrapper-status rule ([[exit-status-after-a-truncation-pipe-measures-the-truncator]]) one layer up: **I instrumented the thing I was curious about and not the step that had to succeed first.** An edit is a leg with its own exit status; a run that follows a failed edit is a measurement of the past. **How to apply.** 1. **Never chain a source edit and the run that measures it in one background job.** Apply the edit in the FOREGROUND, verify it landed, then launch the run separately. 2. **Verify by artifact, not by the script's own success print:** `ls -la` the file (mtime moved) and `grep` for a symbol that exists only in the new version. Both are two seconds and neither can be faked by a script that exited early. 3. If you must chain, join with `&&` so the run cannot outlive a failed edit — and still read the job's `.output`, not only the leg's `.exit`. 4. Tell: **the identical failure message twice in a row.** Two runs of a changed file agreeing byte-for-byte is evidence about the PLUMBING, the same shape as [[identical-readings-across-opposite-outcomes-indict-the-meter]] and [[two-background-jobs-one-output-path]]. I saw it four times before asking.