Record story-114 in the story table

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019WkxmJ5ArLEaC2RDPGkbRU

Author: jerodw

README.md

@@ -72,6 +72,7 @@ Each story below is a step the book's roadmap calls for, or a failure the build
 | 111 | A stage records every file it touched: story-101's tester changed a file and left it out of its own changed-files record, nothing caught it, and nothing could fix it — the record is another stage's output under a blocked path, so the correction pass declined it and the run ended with an account known to be wrong and structurally unfixable. That matters more than one missing line, because those records are what the governance layer reads: what a run touched, which stage created a governed path, what the revert check and the baseline merge turn on, and what a post-story inspection takes into scope. The coordinator now signs the tree before a stage runs and compares afterwards over tracked and untracked paths alike, sharing blocked-path resolution with the readers that already exist so the check and the enforcement cannot disagree, and routes an omission back to the one stage that may correct it | Ch. 15, governance boundaries; Ch. 18, evidence |
 | 112 | A stage can check its own outputs: a stage learned it had left a required output unwritten only after its turn ended, when the coordinator checked and re-entered it — a whole invocation to produce one file, six times in nine stories. Its prompt already said so as forcefully as prose can, which is the move this replaces. A stage may now run the check itself at any point in its turn, and a turn-end hook catches what it would have caught; the hook blocks at most once, fails open on every malformed payload and unreadable file, and decides nothing, because the coordinator's own check remains the authority and reads nothing the hook wrote. One derivation answers both, since two spellings of *written freshly and valid* would drift silently in the worst direction — a stage told it was complete and re-entered anyway | Ch. 18, hardening |
 | 113 | A refile over a failure is reported: a terminally-failed queue entry stops suppressing a finding, so the next inspection files it again — and the re-enqueue overwrites the entry at the same key, discarding the attempt count and the last error, which are the only lasting record that filing this identity keeps failing. So a misconfigured transport looked exactly like a flaky one, on every inspection, forever. The local index now keeps the keys held in the terminal failed state and says so twice: as a count on the queue line, reported even when it is zero, and as a note beneath each brief filed over one. The failed set is evidence and never a suppression source, and no retry ceiling was added — stopping after so many failures is the suppression that loses a finding nobody ever saw | Ch. 17, external systems; Ch. 18, evidence |
+| 114 | What the Inspector files is not noise: a promotion policy written against output a developer had read rather than against a prediction of it — 46 open briefs from thirteen post-story inspections, none closed and none planned. Two things the request predicted did not survive that reading, so the policy is narrower than it would have been: briefs are not thin, the median being 313 words with file:line evidence and its workflow choice argued, and the cap is inert, having dropped nothing on any inspection ever. What the corpus shows instead is arithmetic — filing runs at about three and a half briefs per completed story and planning drains none of them — so the lever is a severity floor rather than a quality bar, one number applied where the cap already lives so both producers get it from the same call. The prompt is told the floor as well as the filter that enforces it, which is not a duplicated fact: the filter decides, and the prompt exists so an invocation does not spend three hundred words on a brief that will be dropped on arrival | Ch. 18, inspection |
 
 Still ahead, in the order Chapters 18 and 19 recommend: per-agent logs and a watcher, a fuller hook-based tool policy in place of the static `allowed_tools` allowlist, an adjudicator, git worktrees and parallel story execution, and a real initialization library.