Skip to content

story-154: Every stage that may write outside its own subject is governed by a check that records what it wrote - #322

Merged
jerodw merged 3 commits into
mainfrom
story/story-154
Sep 17, 2026
Merged

jerodw merged 3 commits into
mainfrom
story/story-154

Conversation

@jerodw

@jerodw jerodw commented Sep 16, 2026

Copy link
Copy Markdown
Owner

The implementer declares what it may not create and carries a revert check. The tester declares what it may only change and carries one too. The documenter — which runs after the last suite the coordinator ran, and before the verifier that judges the tree — declared neither, so nothing asked what it wrote and nothing recorded it.

It was writing production code. Three consecutive runs: story-148's documenter edited orchestration/story_inspection.py, story-149's edited a test module, story-150's edited scripts/l5-plan. In each case a meaningful share of the implementation was authored by the stage whose subject is documentation, and a reader of the run could not tell it apart from the implementer's work, because only one of those has a governed record.

The confinement is the documents the target already names

Both shipped workflows now confine the documenter to the architecture_docs its configuration declares, and give it the revert check the two stages before it carry. The key already existed and was already read; what is new is that it bounds a stage rather than only naming what the claim-support check scans.

That shape was chosen over the two beside it deliberately. The implementer's may_not_create bounds what may be added while leaving modification free, which is wrong here — the risk is modification. The tester's may_only_change takes a directory prefix, and the documenter's subject is a set of documents rather than a directory. Reading the set from the target's own declaration keeps the harness from holding a path the target should own.

An edit outside it is not forbidden — it is asked about

The revert check is the instrument, and it decides what it has always decided: an edit outside the confinement stands where the suite fails without it, and is undone where the suite passes. A forced adaptation is still permitted. What changes is that the question is now asked of this stage at all, and the answer is recorded where a reader meets it.

prompts/documenter.md gains what a correction pass may touch: the files the findings name, and the architecture documents always. An edit elsewhere goes to the revert check, and a correction that cannot land in a file the stage may change is reported rather than attempted somewhere else.

A note for review

The inspection routed six findings about this change and the verdict acted on one, filing five. Two of those five are arguably this story's own work — the documenter prompt does not state the confinement it now runs under, and the refactor verifier is not shown the revert-check record its sibling now sees.

Neither was declined on the merits. Both are one-line fixes in files the correction pass may not reach, and the pass is bounded to repairs "to the words alone" for good reason. The verifier's only route to either was a blocking issue — failing the verdict and spending a retry, on a run already at retry 1 of 2. Filing them was the cheaper call available, and that the cheaper call was the only alternative to a failed run is filed as #321.

Planned from the brief filed under 294.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NJzpgnY9aJ7K2godyjrJJR

… governed by a check that records what it wrote
…rned by a check that records what it wrote

Implemented by the l5 harness story workflow.
@jerodw
jerodw merged commit d97a829 into main Sep 17, 2026
3 checks passed
@jerodw
jerodw deleted the story/story-154 branch September 17, 2026 00:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant