Our Cleanup Undid a Developer's Work

On September 22, 2026, a guard in my repository reverted three files a developer had edited during a test run: a gate script, package.json, and a test file. It printed no warning. The guard thought those edits were its own side effects because they appeared while it was running. Failure 83 records the incident.

Cleanup was itself a writer. The guard could inspect a generated artifact correctly and still damage unrelated work when it put the repository back. That is the failure I use to decide how agents share a monorepo.

The cost was three lost edits.

What did the cleanup actually erase?

The drift check regenerated published artifacts to see whether committed copies were stale. A test invoked that check against the real repository inside a Vitest worker. At the end, the check ran a Git restore over every tracked path that had become dirty since it began. It assumed any new difference belonged to the generator.

The developer was editing at the same time. The guard could not tell whose changes they were. It reverted scripts/test-gate.sh, package.json, and a test file without naming them.

The file list was the bug. The cleanup rule had write authority over paths it did not own.

I should have required cleanup to own only its own changes. Instead, a guard in my system could revert another writer's work. The cleanup operation needed the same boundary as the agent.

My terminal setup gives separate concerns separate lanes. A lane described in a prompt is too weak if the process around it can still write anywhere. The cleanup code needed an explicit set of files.

The fix is narrower.

What changed after the incident?

The check now reads its generated artifact registry before it runs. It snapshots the bytes of every registered artifact it may affect. After generation and grading, it restores only that snapshot set. For a tracked path outside the set that changed during the run, it prints the path and leaves the file alone.

That is an enforceable boundary. A test in the repository makes a fixture generator change an unregistered tracked file. The check names it and leaves its new bytes in place. It still restores the registered artifact. A quiet case changes only a registered artifact, confirms its original bytes return, and prints no outside change.

The loud case stays loud. The quiet case stays quiet. These are fixture checks of the repair. I have not verified every concurrent edit in production.

The cost is deliberate. A generator's unregistered side output and a person's concurrent edit look the same to this check. It cannot safely clean either one. The path stays dirty for inspection.

A second limit remains. The check restores registered artifacts from its starting snapshot. I would keep concurrent edits away from those paths while it runs. The documented failure explains why that narrow rule matters.

What should a monorepo make shared?

A shared repository is a coordination decision. I keep one authoritative copy of a rule when several consumers must obey the same decision. I would not merge unrelated product behavior merely because two functions look alike.

One source. Several checked copies.

One real policy is the agent core in AGENTS.md. It states the proof, authority, and secret handling rules for Orbyt agents. The monorepo holds the authoritative block. A sync script copies its exact bytes into the console repository's AGENTS.md; its check mode reports a missing or different copy. The block carries a hash, and the repository test reads the console copy back and compares the bytes when that checkout is present. I retain this copied arrangement because the repositories can have separate work while the policy still has one source and a checkable copy. A missing console checkout means that cross repository test skips; it is not evidence of agreement.

Rachel Potvin and Josh Levenberg's Google paper describes a common source of truth together with the tooling and workflows around it. I take the tooling part seriously. A folder layout alone cannot detect a policy copy that drifted. My outside audit account also records a related admission: I still did not apply live production reading to the machinery itself. Agreement inside one repository is a bounded kind of evidence.

What would each worker own?

I would give an agent a bounded change after I named the shared interface. "Own the frontend" is too broad if another worker can change the response it consumes. The Collective's seat charters make ownership visible at the organization level; a development assignment needs its own path and interface boundary.

Here is a synthetic saved search example. Its feature, fields, failure response, and acceptance condition are invented for this article. I have not run it at Orbyt.

The response shape lets Workers A and B proceed independently after the interface owner decides it. If either worker needed a different shape, I would return the decision to that owner. I would not let one worker quietly change the shared fields and call its own tests integration evidence.

The shared fields need one owner.

The accepting reviewer checks the combined behavior. Neither worker can establish that result by checking only its own half. The reopen step is the acceptance condition in this hypothetical example, not an Orbyt feature result.

Why do separate worktrees still interfere?

A separate worktree separates files. Other state can still be shared: environment variables, ports, databases, temporary directories, and the remote branch where changes eventually meet.

Files were only one boundary.

Failure 81 records the other boundary. On September 16, 2026, a test run from a linked worktree wrote to the real repository's shared configuration. On September 21, the mechanism was found: a hook in a linked worktree passed repository selecting Git variables into tests, and a sandboxed Git command inherited them. A plain clone reproduction stayed clean because it did not inherit the linked worktree's environment.

The repair strips repository selecting Git variables once per Vitest worker, before the sandboxed commands run. The Git state guard remains a detector for other changes. Its loud replay used the inherited Git directory; its quiet case showed sandbox commands staying in the sandbox. This mechanism is separate from the cleanup repair. One prevents a test from targeting the wrong repository; the other limits what the drift check may restore.

I inventory the files, environment variables, ports, databases, and temporary paths each task can write. I check the environment where the command actually runs. If I have only reproduced a failure in a plain clone, I cannot claim the linked worktree path is covered.

How do I accept the combined change?

A clean merge combines text. It is not proof. I still need to inspect the resulting program against the assignment and the current base. I name the revision I inspected, compare the changed paths with each worker's grant, and run the behavior that crosses their boundary.

For the synthetic saved search, that means the save and reopen path, including the duplicate name failure.

I also give generated outputs one integration owner. When independent workers regenerate the same artifact, the last write can hide a valid input from the other. I would regenerate from accepted inputs after their changes meet, then inspect the result. The public failure corpus records a broken base being attributed to individual seat work. Attribution needs a comparison with that base, not the first red log I open.

I have not run a comparative trial showing that this split is faster. The acceptance rule is about whether the combined work does what I assigned, and whether the files changed stayed within their grants.

When would I use one worker instead?

I use one worker when proposed tasks keep changing each other's assumptions. If each worker needs every other worker's latest reasoning, the split creates repeated explanation and rework. A single capable worker may finish sooner.

More workers can cost more explanation.

Anthropic's compiler experiment encountered agents converging on the same blocker. I take that as a reason to look for independently verifiable work before opening another lane. It does not give me a measured speed claim for my own repository. I settle the contested decision before I reopen independent lanes.

What to do Next

For the next shared change, I would name the interface owner, list the paths and mutable resources each worker may touch, and put generated output under the integration owner. I would write the acceptance condition before assigning the branches. Then I would read the combined diff and execute the crossing behavior.

I would also inspect what cleanup can write. If a guard cannot distinguish its output from another writer's edit, I make it name the change and leave it for inspection. After the run, I would count reconciliation work before deciding whether another worker helps.

I accept combined work only after its shared behavior passes and every writer, including cleanup, stayed inside an explicit file boundary.

Related reading:

• My Stack of Terminals, Documented. how I arrange the development lanes.
• I Manage AI Agents Now, Not People the management work that remains after delegation.
• Codex Accuses. Claude Convicts. why I reproduce findings before acting.
• Long Horizon Agents Don't Fail. They Pass. how an apparently passing run can miss its true condition.