fix: count successful index regenerations in the repair ledger#3625
Conversation
A successful index-only repair reported repaired:0 while committing a real fix, so repairable_seen never balanced against the outcome counts. The regeneration success path now counts each cleared index-kind finding, matching the frontmatter path.
fro-bot
left a comment
fro-bot
left a comment
There was a problem hiding this comment.
The ledger was lying about its own work. Frontmatter repairs and the failure path both counted, but the index-regeneration success path pushed cleared findings into targetedFindings and never incremented repaired — so the first real heal reported {repairable_seen: 1, repaired: 0}. The fix (scripts/wiki-repair.ts:142) is a single repaired += 1 that mirrors the outOfScope += 1 already sitting in the else branch. Symmetric, minimal, correct.
The invariant assertions are the real value here. repairable_seen == repaired + out_of_scope + path_refused now holds across the modified scenarios, and the new test (counts both index-drift and orphan-page ... when one regeneration clears both) builds a genuine two-finding snapshot, confirms the baseline carries both kinds, and proves a single regeneration is credited for both. That's the exact live-run shape from run 28683062455 pinned into a regression guard.
Verified locally: 27 module tests pass, tsc --noEmit clean. Diff against origin/main confirms the source delta is exactly one line — no drive-by changes. Repo rules clear: no any, no @ts-expect-error, no console, explicit return types intact. No workflow, dependency, or automation-safety surface touched.
Verdict: PASS
Blocking issues
None
Non-blocking concerns
scripts/wiki-repair.ts:220computesrepairableSeenfrom raw baseline findings, while frontmatter processing dedupes by path atscripts/wiki-repair.ts:157. If lint ever emits two frontmatter findings for the same page (e.g.missing-frontmatter+invalid-frontmatter),repairableSeenwould exceedrepaired + outOfScope + pathRefusedand the new invariant would break. Pre-existing, out of scope for this PR, and not currently reachable given lint's one-finding-per-page behavior — flagging so it doesn't drift into a silent footgun later.
Missing tests
None. Happy path (single regeneration), the two-finding boundary, and the existing failure/out-of-scope paths are all covered.
Risk assessment: LOW
Pure ledger-accounting change in a maintenance script. No index-regeneration logic altered — only its bookkeeping. No CI, workflow, dependency, or permissions surface. TDD RED/GREEN documented and independently corroborated by the one-line diff and passing suite.
Run Summary
2 participants
What
The first live run of the wiki repair loop (run 28683062455) healed real index drift — one regeneration commit on
data— but reported{repairable_seen: 1, repaired: 0}. The index-regeneration success path pushed cleared findings into the verification target set without counting them as repaired; frontmatter repairs and the failure path both counted correctly.One-line fix plus ledger-invariant assertions:
repairable_seen == repaired + out_of_scope + path_refusednow holds in every scenario, including a new test where one regeneration clears two findings.Verification