dispatch() failed a completed slice by attributing a concurrent peer's file to the worker. The
worker was worktree-bound, had already committed, and left a clean tree.
Measured 2026-08-27
Dispatch of issue-732, session 66fb006c, 48 turns, ended:
Error: Worktree-bound worker leaked writes into the MAIN checkout despite the path deny:
docs/openclinxr/bothyboard-agent-customer-2026-08-27.md
Treat this dispatch as failed and investigate the isolation boundary before running
concurrent writers again.
The named file is not the worker's. It is the third of a series in main:
| file |
mtime |
bothyboard-overtake-gh-projects-agent-brief-2026-08-27.md |
16:10 |
bothyboard-agent-next-2026-08-27.md |
18:53 |
bothyboard-agent-customer-2026-08-27.md |
19:39 |
Its front matter reads from: grok@simnova/OpenClinXR, audience: bothy-board-dev-agent. The first
two predate the dispatch, which started at about 19:05. The subject is a board substrate, not
visemes.
Meanwhile the worker had committed aa3a35a3 to wt/issue-732 and its worktree was clean. The work
was sound: contract-verify-cli passed 3 of 3 on that branch and it has since landed as 2f07ba8b.
What the detector actually measures
It compares the main checkout before and after the dispatch and attributes any new file to the
worker. On a single-writer machine that is sound. This repo runs two agents against one checkout,
and the second writes to main by design.
Cost
One dispatch reported as failed when it had succeeded. The recovery needed a manual
contract-verify-cli and a manual integrate, because a failed dispatch writes no contract report —
the same recovery a resume needs.
The larger cost is the message: it tells the reader to "investigate the isolation boundary before
running concurrent writers again", which points at a defect that is not there. A reader who believes
it stops dispatching.
The shape, and what it must not become
The check has to distinguish the worker's writes from anyone else's. Candidates, unranked and none
verified: attribute by file ownership or process, snapshot only the paths the deny covers, or scope
the comparison to paths the slice's contract names.
It must not be deleted. A worktree-bound worker writing to main is a real failure mode and this is
the only check for it.
It must not simply ignore docs/. The peer writes elsewhere too, and a path exclusion would blind
the check to a genuine leak in the same directory.
Not measured
How many earlier dispatches this has failed. Per #731 there is no refusal log, and a dispatch failure
of this kind writes no ledger row beyond completed — this one shows completed 48 with no
proofsOk, so the failure is not distinguishable from a normal completion in the ledger.
Whether the deny itself held. The worker did not write to main as far as I can tell, but I verified
that by reading the file's provenance, not by watching the deny fire.
factory_step: instrument
unblocks: staging
dispatch()failed a completed slice by attributing a concurrent peer's file to the worker. Theworker was worktree-bound, had already committed, and left a clean tree.
Measured 2026-08-27
Dispatch of
issue-732, session66fb006c, 48 turns, ended:The named file is not the worker's. It is the third of a series in main:
bothyboard-overtake-gh-projects-agent-brief-2026-08-27.mdbothyboard-agent-next-2026-08-27.mdbothyboard-agent-customer-2026-08-27.mdIts front matter reads
from: grok@simnova/OpenClinXR,audience: bothy-board-dev-agent. The firsttwo predate the dispatch, which started at about 19:05. The subject is a board substrate, not
visemes.
Meanwhile the worker had committed
aa3a35a3towt/issue-732and its worktree was clean. The workwas sound:
contract-verify-clipassed 3 of 3 on that branch and it has since landed as2f07ba8b.What the detector actually measures
It compares the main checkout before and after the dispatch and attributes any new file to the
worker. On a single-writer machine that is sound. This repo runs two agents against one checkout,
and the second writes to main by design.
Cost
One dispatch reported as failed when it had succeeded. The recovery needed a manual
contract-verify-cliand a manual integrate, because a failed dispatch writes no contract report —the same recovery a resume needs.
The larger cost is the message: it tells the reader to "investigate the isolation boundary before
running concurrent writers again", which points at a defect that is not there. A reader who believes
it stops dispatching.
The shape, and what it must not become
The check has to distinguish the worker's writes from anyone else's. Candidates, unranked and none
verified: attribute by file ownership or process, snapshot only the paths the deny covers, or scope
the comparison to paths the slice's contract names.
It must not be deleted. A worktree-bound worker writing to main is a real failure mode and this is
the only check for it.
It must not simply ignore
docs/. The peer writes elsewhere too, and a path exclusion would blindthe check to a genuine leak in the same directory.
Not measured
How many earlier dispatches this has failed. Per #731 there is no refusal log, and a dispatch failure
of this kind writes no ledger row beyond
completed— this one showscompleted 48with noproofsOk, so the failure is not distinguishable from a normal completion in the ledger.Whether the deny itself held. The worker did not write to main as far as I can tell, but I verified
that by reading the file's provenance, not by watching the deny fire.
factory_step: instrument
unblocks: staging