Review legs mutate the same working tree concurrently — mutation evidence is untrustworthy in both directions

[BaseInfinity]

Unidentified mechanism reverted edits to scripts/merge-pr.sh inside a subagent

Observed twice during PR #628. A review-leg subagent reported that its edits to
scripts/merge-pr.sh in the live worktree were auto-restored within seconds,
without the agent reverting them.

What is known

• It happened twice, in the same leg's environment.
• My own mutations to the same file, from the main session, persisted
  normally — including three deliberate mutation-test edits that stayed put
  long enough to run full suites against them. So this is not a global watcher
  on the path.
• No mechanism has been identified. Candidates not yet ruled out: an editor or
  IDE with the file open restoring from its own buffer, a sibling agent process
  in another worktree, or something in the subagent's own tooling.

Why it is worth a name

scripts/merge-pr.sh is the merge boundary. An unidentified process that
can rewrite it — even one that only restores it — is a thing that should not be
left unnamed. The benign explanations are all plausible; the point is that none
of them has been confirmed.

Not urgent

Did not block #628, and does not block #521. This is a placeholder so the
observation does not evaporate. Reproduce first; do not fix anything until the
mechanism is identified.

[BaseInfinity]

Parked: not v1.99.0 / v2.0.0 scope. Revisit after v2.0.0 ships.

[BaseInfinity]

EXPLAINED — and it was not an unknown mechanism.

Reproduced today with a named cause: two review legs mutating the same working tree concurrently. Both round-1 legs on the #563/#636 PR ran mutation tests against the live worktree at the same time. The Fable leg reported it directly: its mutation-A totals were inflated (94 where 92 was correct) by the other legs transient counterexample rows, and its own mutation briefly overlapped the Sol legs -ge 1 mutation inside scripts/merge-pr.sh. It reverted, then rebuilt an isolated copy and re-ran everything there.

That is exactly the "edits auto-restored within seconds" symptom from PR #628 — another agent reverting its own mutation, landing on a file a different agent had just edited. It also explains why my mutations from the main session always persisted: nothing else was running then.

So there is no third party writing to the merge gate. There is a concurrency defect in how we run review legs.

The real finding, and it is bigger than this issue: mutation evidence from concurrent legs is untrustworthy in both directions. It can make a guard look proven when the failure came from another agents edit, and it can make a guard look unproven when another agent restored the file mid-run. Both nearly happened here.

Fix: each review leg gets an isolated copy of the repo. isolation: "worktree" exists for exactly this. Applied by hand for round 2 of the current PR; the durable fix belongs with #616 (supervise review legs), which already owns leg lifecycle.

Retitling and reassigning accordingly. Related: #616, #628.

[BaseInfinity]

Moved to v1.99.1 — review-leg supervision alongside #616. The fix for this issue is #616 cut 1 (per-leg isolation) — see #616 (comment) for the scope split. Round 2 of the #563/#636 PR runs each leg in its own full cp -R copy as the hand-run prototype; whatever that required by hand is the spec.