story-155: A finding about the story's own change is fixed by the stage that owns it, whatever that stage is

[jerodw]

A verifier that wanted a finding about the story's own change fixed had two routes, and most findings fit neither. A correctable finding re-enters at the documenter and is bounded to repairs "to the words alone." A blocking issue fails the verdict, spends a retry and archives the attempt. Nothing in between.

So a finding whose fix is one line in a file the documenter does not own could be had only by failing the whole run. story-154 met that exactly: it left prompts/documenter.md never stating the confinement it had just imposed, and the fix — a paragraph in the implementer's file, not prose-only — was reachable only by failing a run already at retry 1 of 2 and $51. It passed and filed the finding instead. That was the cheaper call available, and it should not have been the only alternative.

A repair pass has the correction pass's cost and the retry routing's reach

The verifier names a repairable finding's category; the coordinator looks it up in the retry_routing table it already reads, and re-enters that stage. So a finding is fixed by the stage that owns its file rather than by whichever stage the declaration happens to name.

The budget is 2, on the correction pass's arithmetic: a pass fixes what a verification raised, and the verification after it can find something the first findings did not reach. A separate story to carry a leftover finding costs more than a second pass in the run that found it.

It is bounded because it may change behaviour, which is what separates it from the correction pass. It carries the findings and no guidance, so the stage is entered to fix what was named rather than to revisit the work. It routes only after the clean-clone check on the routing verdict has passed. And it returns to a verification that runs the check again on the repaired tree.

What this run says about itself

Three attempts, thirteen briefs filed, none acted on. Both numbers need reading.

None acted on because the mechanism this story builds was not live during it — the harness executing a run is the one the developer invoked, not the one on the branch — and because the first two attempts were dominated by red suites carried forward, where the verifier was routing validation failures and the findings were beside the point.

Thirteen briefs are six defects. Four were filed two and three times over, under a different slug each time, and in one case under a different category on each reading — robustness, then cross-path-parity, then robustness again. A brief is filed under its kind, category, sorted paths and slug; all three variable parts drift between attempts, so no two keys collide and every re-finding becomes a new brief. The duplicates are closed as duplicates; that a run files one defect once per attempt is filed as #336.

Planned from the brief filed under 321.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NJzpgnY9aJ7K2godyjrJJR