story-113: A refile over a failure is reported

[jerodw]

Story

A refile over a failure is reported.

story-095 made a terminally-failed queue entry stop suppressing a finding, which is right: a failed entry is a finding that reached nobody, and suppressing on it would lose that finding permanently with no signal. So the next inspection files it again — and the re-enqueue overwrites the entry at the same key with a fresh one, discarding the attempt count and the last error.

Those two fields are the only lasting record that filing this identity keeps failing, and l5-status shows a last error only for an entry that failed terminally. So the steady state was: fail terminally, refile, erase the evidence, fail the same way, erase again. A transport that is misconfigured — a bad token, a label that does not exist, an archived repository — looked exactly like one that is flaky, on every inspection, forever.

What changed

The local index now keeps the keys the queue holds in the terminal failed state, and says so two ways: a count on the local-queue line, and a note beneath each brief filed over one — refiled over a terminal failure: the local queue held this key failed.

Three things about the shape:

• failed is evidence and never a suppression source. story-095's rule is untouched, and the code says so where the field is declared. Nothing that decides suppression reads it.
• The count is reported on every inspection the index was read on, including one that held none — the same grounds the line itself rests on: a source silent when it found nothing cannot be told from one that did not run.
• The queue is listed once for both the pending and the failed keys rather than read twice.

No retry ceiling, deliberately. "Stop refiling after K failures" is the suppression story-095 refused and it fails the same way: a finding that reached nobody would be lost with no signal. The answer to a filing that keeps failing is a developer reading that it keeps failing.

Evidence

• Suite: 5293 passed, 1 skipped (exit 0)
• Clean clone with the story committed: exit 0
• Verification passed, no blocking issues
• 0 retries, 0 self-routes, no correction pass, $15.33
• New module tests/test_a_refile_over_a_failure_is_reported.py (610 lines); 7 files changed, +729 / −31

Notes for review

The falsifiability note is worth reading rather than skimming. The verifier could not demonstrate the new tests failing: the sandbox refused the edit that would have removed the mark from file_findings and re-run the module. It judged falsifiability by reading the assertions instead, observing that the load-bearing ones are positive — an exact slug list, an exact failed-key set, a literal count in the printed line — rather than absence checks that would pass against a silent implementation.

That is a reasonable substitute and it is not the same thing as having shown it. Worth knowing that this environment's own restrictions are what stopped the check the repository would normally insist on.

The second note is routine: the suite verdict is the coordinator's injected result rather than a run the verifier made.

🤖 Generated with Claude Code

https://claude.ai/code/session_019WkxmJ5ArLEaC2RDPGkbRU