Worktree isolation was correct: when a runner reports worktree_path, it means the engine edited an isolated, throwaway git worktree instead of the real repository, and the orchestrator is supposed to run verify_command inside that worktree; checking the real repo would verify a tree the engine never touched. Post-task verification was correct too: it runs the configured check and reports pass or fail. Put those two correct pieces together with no validation at the seam between them, and the result was a bug that neither feature’s own tests could ever have found, because it lives entirely in the space between them.
The seam nobody checked
worktree_path was taken verbatim from the runner’s stdout. Nothing confirmed it was an absolute path before using it to decide where verify_command would run. A relative path in that field resolved against whatever the orchestrator process’s own working directory happened to be at the moment verify ran: not necessarily the worktree, not necessarily anywhere related to this task at all. Verify would run anyway, against whatever that resolution landed on, produce a pass or fail result, and report it with exactly the same confidence as a result from the correct directory. The failure mode wasn’t a crash. It was a verify step checking the wrong universe and reporting back as if it had checked the right one.
The class of bug, not just the instance
The specific fix is narrow: dispatch() now refuses a relative worktree_path before any event is appended, and the contract documentation now states plainly that the field must be absolute. But the underlying shape generalizes past this one field. Any time one part of a system produces a filesystem path (through a subprocess’s stdout, another tool’s structured output, a config value pulled from somewhere external) and a different part of the system uses that path to decide where a safety-relevant check runs, the two parts are composing across a trust boundary whether anyone designed it that way or not. If neither side validates what crosses that boundary, the failure is silent by default: the receiving side just resolves the path somehow and proceeds, because filesystem path resolution never refuses on its own.
The refusal, not just the fix
The corrected behavior doesn’t just validate and continue with a corrected path; it refuses outright, before the task is marked dispatched at all, leaving it re-attemptable. This matches the same fail-closed instinct this arc keeps returning to: a safety check that silently degrades to checking something else is worse than a safety check that visibly refuses to run. A missing worktree directory, separately, is now explicitly reported as a failed verify rather than raising an uncaught exception; the two fixes together mean the seam between isolation and verification now has exactly two outcomes: verify runs against the right directory, or the task is loudly not-dispatched. Never a quiet third option.
What next
This arc’s build-quality findings close here. The last post turns from what the tool does to what it’s allowed to claim about itself: the difference between the evidence that proves the machinery works and the evidence that would prove the mission it exists for actually succeeded.
What Next
Two Gates, Two Claims
V1 proves the machinery works against a demo. Go-live proves the mission succeeds on something real. Conflating the two claims ruins both of them.