---
name: correct-by-replacement-not-annotation
description: "Appending a correction after a false claim leaves the false claim readable first — replace the wrong sentence, don't annotate it; and sweep the whole registry for the pasted class, not just the flagged instance."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: f6c93d11-34a3-4995-b1dd-a923f4947c6c
  modified: 2026-07-31T14:58:11.648Z
---

When a reviewer flags a stated claim as false (doyle's W4 gate, 2026-07-31: a
`traceable-reqs.toml` comment asserting `int ACTIVATED` while `required_stages`
omitted `int`), fix it by **replacing the false sentence**, not by appending a
correction after it. My first fix (@e2dd31d) left `int ACTIVATED milestone A W4
T11` standing and added `NO int STAGE HERE —` behind it, so the comment still
OPENED with the lie; a reader or grep hits the claim before the retraction.
@9f01863 replaced the sentence outright.

**Why:** a comment is read top-down and grepped by substring. A retraction only
works if nothing before it asserts the opposite. "Corrected" text that still
contains the original false claim fails the same audit that caught it.

**How to apply:**
- Rewrite the wrong sentence in place. State the true stage, that no evidence
  exists, and why the run in question does not supply it.
- Then **sweep for the pasted class**, not just the flagged instance. Doyle
  named one req; the same activation sentence had been pasted onto two more
  (`REQ-KNOCK-FLOOD`, `REQ-KNOCK-INBOX-DAEMON-OWNED`). Scan all blocks for
  "comment claims a stage its `required_stages` lacks" — negation-aware, and
  expect `UNACTIVATED` to match `ACTIVATED` as a substring artifact.
- When a claim IS genuine, activate rather than withdraw — but record the
  **limit** of the tier in the same edit (the ladder proved the stamp crossed
  the wire and bound the grant; it did NOT prove a forged knocker is refused,
  so that leg stays unit-tier). Doyle called limit-recording plus the
  class-sweep "the difference between fixing a finding and fixing the class."
- Mutation-prove a newly activated stage is load-bearing: mask the evidence
  tag → gate must exit 1 with the req at `[--]`; restore and re-verify.
  Careful: `git checkout -- <file>` restores to HEAD, which **discards
  uncommitted edits** in that file — my sha-verified restore caught exactly
  that and I had to re-apply the module-doc change.

Same family as [[single-source-discriminant-marker]] and
[[uniform-table-blindness-sweep]]. See [[w4-knocking-wave]] for the wave.

## SECOND INSTANCE — an ACTION-BEARING document, deployah 2026-09-09 (v0.68.0 r3)

Same rule, new medium, and the new medium is worse. The first instance was a false CLAIM in a
`traceable-reqs.toml` comment: the cost is a reader who believes it. This instance was a stale
TARGET in an operative release runbook (`CASCADE-v0.68.0.md`): the cost is an executor who **acts**
on it — here an ff-merge and a `git tag` against `c4919243` after doyle ordered rider 5 on top of
it, i.e. tagging a sha with a known-flaky cell as the shipped release.

**What I actually did wrong, which is the point:** I appended a forty-line `HEAD PENDING` banner to
the FOOT of the file — accurate, detailed, and it left line 2 still reading
`RULED SHA = c4919243  <-- r3 HEAD`. Every action line in sections 1 and 2 still named the dead sha.
I had written a thorough correction and fixed nothing an executor would ever reach.

⭐ **A LONG, CORRECT APPENDED CORRECTION IS THE MOST DANGEROUS KIND**, because its length feels like
diligence. The effort spent on the annotation is what convinces you the job is done. Volume of
correction is not placement of correction.

**How to apply, on top of the existing entry:**
- Ask **where the reader ACTS**, not where you are writing. In a runbook that is the header and the
  command lines; in a comment it is the first sentence. Fix THAT, then append the detail if you want
  it. Both, in the same edit — the append is not a substitute and not a stage.
- Then **enumerate and CLASSIFY every hit** of the retired value action-vs-history — `grep -c` alone
  proves nothing ([[a-stale-target-makes-a-check-pass-harder-not-fail]]). Mine: 13 hits = 3 ACTION
  (two ff-merge lines, one tag line) + 10 history/notes. Only the 3 are the defect.
- **Audit your own replacement text as strictly as the text it replaced.** My new header asserted
  the stale action lines were "in sections 1, 2 and 4"; section 4 publishes by `--tag` and names no
  sha, so the correction shipped its own false claim, in the one file whose purpose is precision.
  Caught only by re-reading what I had just written. A correction is not exempt from review because
  it is a correction.
- If the document is preserved with a checksum manifest, the edit **stales your own proof** —
  rehash and re-verify from the repo root in the same pass, or the next reader's `sha256sum -c`
  fails and they cannot tell tampering from your fix.