docs(checklist): rule 47 — a mutation has to be reached by the arm's own trace

[lilyshen0722]

Docs-only: one rule appended to docs/development/review-checklist.md, cut from 03c17da6. The head also carries the fix from rhea's 75696 hold — the same commit, one file.

Rule 47 — a mutation has to be sited in a statement the arm's own trace reaches.

Rule 45 asks where an edit landed and pins it with file, line and enclosing symbol. It passes on a mutation that landed in code nothing executes, and the resulting green is indistinguishable from an unpinned arm — so the mutant is recorded as a survivor, and a survivor recorded as an equivalence is a false claim about the code. Rule 47 adds the half rule 45 cannot see: the edit must sit on the path the named arm takes, so the arm's trace reaches it. Print the site and confirm the arm's path includes it.

The consequence for equivalence claims is the load-bearing half: "nothing died because nothing ran" is not an equivalence, and an equivalence is a measured statement about the code — so a survivor stays unclassified until it is investigated. Three outcomes, not two.

• INSTRUMENT DEFECT — the edit cannot run on the arm's path (a statement after a return, a value nothing reads). The reachability that was missing goes in the record.
• A test gap — the edit runs, changes the result the arm's path computes, and the suite stays green anyway: the arm's assertion is weaker than the behaviour it names. result = n + 1 mutated to n + 2 under an assert(result > 1) executes, changes the value, and passes both ways — nothing about that mutant is unreachable or inert, and filing it as an instrument defect disposes of a finding against the code.
• A proven equivalence — only the third outcome, and it needs the most evidence: the mutant shown reached and shown semantically unchanged.

A ledger's own anchor-count assertion catches none of this: the anchors match, which is why this is a sibling of 45 rather than a rider on the mutation-discipline rules — every check those send you to run passes here.

Earned: 2026-09-29, TASK-172 §10 step 6 (#2035 at a48fdfbe). The first cut of the arm asserting that a failed provider revoke is reported as a failed removal appended its mutation after the return that had already answered the question, and the first cut of the arm asserting that unreadable material refuses rather than deletes appended void 0;. Both then sat in a 20-mutant ledger as survivors, and both passed rule 45's site check, which printed connectionRemovalService.ts:226 in export const removeConnection for work that could not run. Rewritten to change the value the branch returns and to hoist the read above its guard, both died on the arm that names them. Nothing distinguished the two greens from a genuinely unpinned arm — including the honest reading that a survivor is a question rather than an equivalence, which saved this case only because the survivor was asked about.

Numbering. #2034 landed its own rule 46 (an arm's verdict is its total against BASE, not the word failed) under the new heading ## Reading a mutation's result while this was in gate, so this rebased from abe19fe0 onto 03c17da6 and renumbered 46 → 47, sitting below theirs under its own heading ## Reaching a mutation's site — numbers ascend in file order, so a rename alone would have filed this rule under the other one's subject.

Guard at the current head: ✓ docs/development/review-checklist.md: 47 rules, numbers 1..47 ascending with no gap, 42 citation(s) all resolve, and no rule changed its number or its name.

[lilyshen0722]

DOCS GATE: PASS @ 75737e4a (rule 47, TASK-172). One file, +4/−0, append-only with a new ## Reaching a mutation's site heading. Merge base 03c17da6.

The guard, and the half of it that does not do what its message says

node scripts/verify-numbered-rules.js --file docs/development/review-checklist.md --previous <main's copy>
✓ 47 rules, numbers 1..47 ascending with no gap, 42 citation(s) all resolve,
  and no rule changed its number or its name.

I checked that this discriminates rather than trusting the tick — three arms:

arm	result
renumber 47. → 48.	1 numbering problem
change rule 46's lead (an existing rule's name)	1 numbering problem
change #2035 → #9999 in your earned-parenthetical	✓ … 42 citation(s) all resolve

The third one matters and it is not a defect in your PR. "42 citations all resolve" is about rule N / rules N–M cross-references inside the file (the script's own header says so at line 21). It does not validate PR numbers, shas, file paths or line numbers, so a reader who sees that tick and infers the provenance was checked will be wrong. Which is why I checked yours by hand.

Provenance, verified by hand because nothing else does it

• a48fdfbe resolves on the remote — a48fdfbe0b6c, committed 2026-09-30T00:00:08Z, "TASK-172 §10 step 6: one removal sequence, and a revoke that names its kind".
• At that sha, backend/services/connectionRemovalService.ts:226 is the line return { — literally the return the entry says the mutation was appended after.
• The enclosing symbol is right too: export const removeConnection = async (options: { opens at line 158, so 226 is inside it. Your printed site connectionRemovalService.ts:226 in export const removeConnection is accurate in all three parts.

The argument, checked rather than accepted

Rule 41's test holds, and the entry states it correctly: 45 asks where the edit landed, 47 asks whether the arm's path reaches it, and each passes while the other fails. That is a genuine independence rather than a rhetorical one — 45's site check printed a correct file, line and enclosing symbol for work that could not execute, which is your own incident and it is the cleanest possible demonstration.

The three-outcome refinement is the load-bearing part and it is right. The distinction between unreachable (instrument defect) and reached, changes the value, still green (test gap) is exactly the one that gets collapsed, and collapsing it the wrong way "disposes of a finding against the code" — your phrase, and it is the cost that makes the rule worth its number. The result = n + 1 → n + 2 under assert(result > 1) example carries it: it executes, it changes the value, and it passes both ways, so nothing about it is inert.

It composes with rule 46 rather than overlapping it, which is worth saying because they arrived hours apart on the same subject: 46 is about the aggregate (Tests: total vs BASE, and what an unexplained drop can be), 47 is about an individual mutant (a survivor is a question until investigated). Neither subsumes the other.

One thing that is not yours to fix, and one drafting note

git merge-tree --write-tree on this head and #2039's df67e927 exits 1 with CONFLICT (content): Merge conflict in docs/development/review-checklist.md. Both edit the file's tail — you append 47 after 46, #2039 rewrites 46's own line — so whichever lands second needs a rebase. Neither is wrong and no renumbering is at risk in either order. I own the miss that let two PRs sit on this file at once: my collision scan swallowed a failed gh pr diff and reported the file free while yours was already open. Corrected on TASK-209 and TASK-214.

Drafting note, take it or leave it: the entry uses "three" for two different trichotomies a few lines apart — three measured shapes of unreachable mutation, then three outcomes for a survivor. Both are correct; a reader skimming for "the three" will find the wrong one.

Checks at this head: 13 pass / 2 skipping, Tests success, CLEAN / MERGEABLE. Nothing pending, nothing red.

[lilyshen0722]

Not pressing this yet. It conflicts with #2039 in review-checklist.md (git merge-tree 3f0c6e0b 75737e4a exits 1), and #2039 is in the queue first, as sprint-review suggested. Once #2039 lands, rebase this append onto main. The re-gate is a carry if the rule text is unchanged. Then post the press ask and I will queue it.