Somewhere in the V1 build, a failed-dispatch path printed a helpful line: block the session, it said, to send the task back for rework. The state model even had a name for the mechanism: dag.py documented a SESSION_UNBLOCK rework marker as part of its per-task states. Both the message and the marker described a real capability. Neither of them had ever actually worked, and neither had ever been tested, because nobody had ever needed to walk that exact path in practice, until a systematic review went looking for what the code actually permitted instead of trusting what it printed.
The path that was never legal
The event vocabulary’s transition table said review permitted exactly one next step: close. Every dispatched DAG task lands in review by construction: a dag dispatch always ends with its verify result appended as a session_review event, success or failure alike. So a task whose verify step failed had exactly one legal move available to the system: close it, as if it were done. The advertised rework path (block it, fix it, unblock it, re-dispatch it) required a review → blocked edge that the transition table had never granted. Not a bug in the implementation of the rework path. The rework path had no implementation to have a bug in. It was pure fiction, told confidently by a tool that believed its own documentation.
What actually found it
The V1 diff got a full ARB review: eight independent finder angles over the same code (line-by-line, removed-behavior, cross-file tracer, reuse, simplification, efficiency, altitude, and conventions), deduplicated, then run through a verification pass. Ten findings survived, confirmed rather than plausible. This one came from the angle that traces claims across files rather than reading any single file in isolation: it didn’t ask “does this function have a bug,” it asked “does this transition table actually permit what this other file’s error message promises,” and followed the two files far enough apart that normal development, normal use, even normal code review focused on one change at a time, had never put them side by side.
The fix and the loop it proved
The fix is one new legal edge: review now permits session_block, added as an explicit amendment to the canonical vocabulary rather than a quiet patch. That one edge makes the whole rework loop real for the first time: dag dispatch fails verify → session_block with a reason → session_unblock → the task returns to ready → re-dispatch. The loop is now pinned by a test that actually walks all five steps, so “the rework path works” stopped being a claim in a help string and became a fact a test asserts every run.
What next
Catching an illegal-path claim is a code-shape finding. The next post in this arc is a different kind of finding from the same review pass: a bug that only exists because two separately-correct safety features were composed together for the first time, in a way neither one’s own tests had ever exercised.
What Next
Verifying the Wrong Universe
Worktree isolation and post-task verification were each correct on their own. Composed together, verify silently ran against a repo the engine had never touched.