What happened
Running ce-code-review with the full local roster, the testing reviewer did mutation testing — editing the production file, running the suite, reverting — while correctness and adversarial were concurrently reading that same working tree.
correctness reported what it called a "tooling anomaly": a grep -n returned a source line that was not in the file. The phantom text was verbatim one of the mutations testing was writing and reverting at that moment.
It was not a tool bug. Two reviewers were operating on one checkout, and a read-only reviewer observed a sibling's transient write.
Why it's worth fixing rather than tolerating
In this run it caused no harm, because correctness handled it well: it re-read via a second tool, hashed both the working tree and the git blob, confirmed they matched, and reported the finding grounded in verified content — while flagging that the spurious variant would have inverted one of its findings' analysis.
That is the risk. A reviewer that trusted the first read would have produced a confidently-wrong finding citing a line that never existed, with a file:line quote satisfying the quote-the-line gate. The gate is designed to kill "symbol doesn't exist" false positives; a transient sibling write defeats it, because the line genuinely was there when read.
The failure mode is also silent and non-deterministic — it depends on scheduling, so it will not reproduce and will read as flakiness.
Suggested fix
references/dispatch-reviewers.md dispatches the local roster as one concurrent batch on the shared checkout. The testing persona is the one whose method involves mutating the tree (mutation testing is the strongest evidence it can offer that a test actually guards a property — worth keeping, not discouraging).
Dispatch any tree-mutating reviewer with isolation: "worktree" so it gets its own copy, leaving the shared checkout read-stable for the rest of the batch. The Agent tool already supports this.
Alternatively, if isolation is too costly per-run, the persona spec could require mutation work to happen in a scratch copy rather than in place — but that pushes a correctness requirement into prose, where the current setup pushes it into the harness.
Context
Observed on a five-reviewer local roster (correctness, adversarial, testing, project-standards, learnings) run against a small diff in a private repo. The cross-model peer was suppressed for that run, so all five were in-process on one machine — which is the configuration where this collides.
What happened
Running
ce-code-reviewwith the full local roster, thetestingreviewer did mutation testing — editing the production file, running the suite, reverting — whilecorrectnessandadversarialwere concurrently reading that same working tree.correctnessreported what it called a "tooling anomaly": agrep -nreturned a source line that was not in the file. The phantom text was verbatim one of the mutationstestingwas writing and reverting at that moment.It was not a tool bug. Two reviewers were operating on one checkout, and a read-only reviewer observed a sibling's transient write.
Why it's worth fixing rather than tolerating
In this run it caused no harm, because
correctnesshandled it well: it re-read via a second tool, hashed both the working tree and the git blob, confirmed they matched, and reported the finding grounded in verified content — while flagging that the spurious variant would have inverted one of its findings' analysis.That is the risk. A reviewer that trusted the first read would have produced a confidently-wrong finding citing a line that never existed, with a
file:linequote satisfying the quote-the-line gate. The gate is designed to kill "symbol doesn't exist" false positives; a transient sibling write defeats it, because the line genuinely was there when read.The failure mode is also silent and non-deterministic — it depends on scheduling, so it will not reproduce and will read as flakiness.
Suggested fix
references/dispatch-reviewers.mddispatches the local roster as one concurrent batch on the shared checkout. Thetestingpersona is the one whose method involves mutating the tree (mutation testing is the strongest evidence it can offer that a test actually guards a property — worth keeping, not discouraging).Dispatch any tree-mutating reviewer with
isolation: "worktree"so it gets its own copy, leaving the shared checkout read-stable for the rest of the batch. The Agent tool already supports this.Alternatively, if isolation is too costly per-run, the persona spec could require mutation work to happen in a scratch copy rather than in place — but that pushes a correctness requirement into prose, where the current setup pushes it into the harness.
Context
Observed on a five-reviewer local roster (correctness, adversarial, testing, project-standards, learnings) run against a small diff in a private repo. The cross-model peer was suppressed for that run, so all five were in-process on one machine — which is the configuration where this collides.