fix(scripts): re-pin the silent-revert clean row to the true closest sub-threshold miss

[kyle-sexton]

Closes #2865.

What this fixes

scripts/silent-revert-incidents.txt pins a clean row that is supposed to be the closest a non-incident got to the 200-line threshold without crossing it — the row that breaks first if a threshold change starts taxing ordinary development. The pinned commit was not that, and its note named a number that is not a pull request.

Defect 1 (the re-pin). Measured over the file's own 500-commit corpus (7b47d2253~500..7b47d2253) at the pinned invocations (#2843, GIT_CONFIG_GLOBAL=/dev/null GIT_CONFIG_NOSYSTEM=1), the pinned c8470efd0 scores 136 blamed lines — sixth-closest of the eight commits in the 100–199 band. The true closest miss is 9a2307c43 (#2189) at 195 lines from 3584ae1fa (#2183) — a margin of 5 lines, not the ~71 the old row implied. 9a2307c43 is now the lead clean row.

Defect 2 (the wrong PR number). The old note credited the deleted content to #2679, which is a closed issue in this repository, not a pull request (gh pr view 2679 cannot resolve it). The blamed lines trace to 6370a44e7, the squash commit that landed #2715 — gh api .../commits/6370a44e7/pulls returns only #2715, and the commit's own body says Builds on merged #2715 → #2692 → #2690. The row is kept as a second guard with its note corrected, rather than dropped: it is still a verified-legitimate quiet commit, and keeping it costs a few lines of prose.

Defect 3 (the "once a month" rate) was already fixed by #2847, which removed the rate claim from scripts/check-silent-revert.sh entirely. Nothing in this PR touches it.

What this does NOT do

Neither clean-row figure is CI-asserted, before or after this change. clean rows carry no bracketed attribution field (#2879) — their assertion is the absence of findings, which has no per-culprit count to pin — so the 195 and 136 are hand-measured prose, not watched numbers. The old row's recorded 129 drifting to a measured 136 under the pinned invocations without anything going red is exactly that gap, and the section comment now states it so a reader does not mistake the re-pin for an assertion. Both counts are written as floors ("no fewer than") because attribute_file drops git blame's stderr (#2880), so any line blame fails on is silently not counted.

Verification

• Spot-checked both figures against PR fix(scripts): read revert subjects and assert the canary's replay attributions #2843's pinned invocations before editing: 9a2307c43 reproduces 195 (75 lines song-forms-examples.md, 67 box-model.md, culprit 3584ae1fa), c8470efd0 reproduces 136 (109 lines persist-findings.md, culprit 6370a44e7).
• bash scripts/check-silent-revert.test.sh: 101 passed, 0 failed on this branch.
• scripts/check-silent-revert.sh --verify-known-incidents: exit 0 — all three fires rows reproduce their attributions exactly, and both clean rows stay quiet.
• scripts/check-silent-revert.sh --verify-restoration: exit 0 — all 5 markers present.
• A fresh-context verifier independently swept all 500 corpus commits twice (complete coverage: 487 ok + 2 acknowledged + 11 finding commits = 500) and reproduced every figure in the file. Its verdict: 195 at 9a2307c43 is the highest sub-threshold score — the next highest is 188 (3d69448cb) — so the lead clean row pins the true closest miss. The two acknowledged commits were re-run with the ack file disabled and score 447 and 323, both above the threshold, so neither could displace it.

Related

• fix(scripts): read revert subjects and assert the canary's replay attributions #2843, fix(scripts): re-derive the overlap calibration from the pinned detector's counts #2847, feat(scripts): assert a recorded silent-revert incident's content came back #2873 — the three PRs that reshaped the canary and this file ahead of this change; the figures here are measured under fix(scripts): read revert subjects and assert the canary's replay attributions #2843's pinned invocations.
• silent-revert canary: clean rows carry no attribution assertion, so their figures rot silently #2879 — records that clean rows carry no bracketed attribution field, which is why neither figure in this PR is CI-asserted.
• silent-revert canary: attribute_file swallows git stderr, so corpus finding counts are lower bounds #2880 — records that attribute_file drops git blame's stderr, which is why both counts are written as floors.
• silent-revert canary: the incident corpus misattributes the #2633 revert to a PR that never merged #2831 / fix(scripts): correct the silent-revert incident corpus attribution #2832 — the same wrong-PR-number defect shape, corrected earlier on the fires rows.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LwdkpWf6bptu3AqTMoeg2H

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[claude]

Claude encountered an error after 0s —— View job

---

I'll analyze this and get back to you.

[claude]

Claude encountered an error after 0s —— View job

---

I'll analyze this and get back to you.

[claude]

Claude finished @kyle-sexton's task in 4m 58s —— View job

---

Code review — scripts/silent-revert-incidents.txt

• Gather context (PR diff, CLAUDE.md, skill instructions)
• Review the diff for correctness
• Independently verify the re-pinned counts where feasible
• Post findings

No blocking findings. This is a data/calibration-file change (no application logic touched), and the parts I could independently check are consistent with what the PR claims.

What I verified directly (via git cat-file / git rev-parse / git diff --name-only against the actual repo objects, not by re-running the claimed test/verification commands):

• Both pinned SHAs resolve to real commits: 9a2307c43 and c8470efd0.
• 9a2307c43's subject line is literally ...(#2189), and its file-level diff includes plugins/songwriting/context/pat-pattison/research/song-forms-examples.md and box-model.md — matching the PR body's spot-check.
• 6370a44e7 has exactly one parent line in its raw object — confirming the second commit's correction ("squash commit, not a merge commit") is right, and the file text (L178) now says "squash" rather than "merge."
• c8470efd0's diff includes plugins/mutation-testing/skills/audit/context/persist-findings.md, matching the "persist-findings context doc" note (L177).
• c8470efd0's commit body contains, verbatim, "Builds on merged feat(mutation-testing): persist survivors as a conforming findings file behind a flag #2715 → docs(conventions): add the detector-findings owner doc #2692 → feat(review): merge findings across producers and mark consumption explicitly #2690; rebased onto main" — an exact match to the quote at L181–182.
• The two commits' author timestamps are 1,581s apart (≈26m18s), matching the "rewritten 26 minutes later" claim at L178–179.

What I could not verify: the sandbox for this lane only permits plain read-only git plumbing (cat-file, rev-parse, diff --name-only); commands using pipes, env-var prefixes, or script execution (needed to replicate attribute_file's blame-based line counts, or to run check-silent-revert.sh/its test suite) required approval I don't have here. So the two headline figures — 195 and 136 blamed lines — and the PR's stated 101 passed, 0 failed test run are author-claimed and unverified by me, not independently reproduced. Everything I could check around them (SHAs, PR numbers, file paths, an exact commit-message quote, and the minute-delta) checked out, which is reasonable circumstantial support.

Two structural notes, not findings: the new/edited rows correctly omit a bracketed attribution field per the file's own documented rule that clean rows carry no such field (#2879), and the top-of-file description at L10–15 was updated consistently to describe "commits" (plural) now that there are two clean rows.
· branch

[claude]

Claude finished @kyle-sexton's task in 1m 38s —— View job

---

Security review (/review:security-review)

• Gather context (diff via gh pr diff, PR description, repo conventions)
• Apply skip gate
• Report

Skip gate: no security-relevant surface.

This PR touches a single file, scripts/silent-revert-incidents.txt (+28/-7), and the change is entirely prose/data: it re-pins which commit is recorded as the closest sub-threshold "clean" example for a documentation-canary detector, corrects a PR-number citation in a comment, and adds explanatory text about why the two clean rows' line counts aren't CI-asserted. There is no code, no script logic, no GitHub Actions workflow, no permissions/config, and no input-handling change in this diff — nothing that introduces an injection surface, an authz/access-control change, credential handling, or a supply-chain/workflow-trigger risk for this lane to evaluate.

Per the skip gate in this lane's instructions, I'm stopping here and posting nothing else — there is nothing for a security review to flag in this PR.

[github-actions]

Last security-reviewed head: 1d04b1fd9163ad75cfc2a9ef1972fd71e6a42807. On the next push, the relevance gate compares only the commits since this SHA; delete this comment to force a full re-review.

[github-actions]

Claude has reviewed this PR 1 time. The lane skips further automatic reviews after 5; deleting this comment resets the count.