What happened
tests/orchestrate-review-pass.bats test "the commit that added this file touched no other BATS file" fails on a clean main checkout (verified 2026-08-14, commit 276c921):
not ok 25 the commit that added this file touched no other BATS file
Why
The test anchors on git log --diff-filter=A — the commit that ADDED the file — to avoid the working-tree false positive its own comment describes. But PR #94 was squash-merged: on main, the commit that added orchestrate-review-pass.bats is the squash commit 276c921, which also added/touched several other .bats files (session-prompt-rework.bats, orchestrate-insight-emission.bats, …). The anchor is only stable on the branch where the original single-purpose commit existed; a squash merge rewrites it into a multi-file commit, so the check goes permanently red on main.
The test already skips on shallow clones (fetch-depth 1) for an analogous reason — the anchor commit cannot be honestly resolved there either.
Related
tests/orchestrate-insight-emission.bats "changes vs branch HEAD are exactly the files this task owns" has the sibling problem in the other direction: it anchors on git status --porcelain with a hardcoded allowlist of the i83 task's files, so it fails in ANY worktree that has uncommitted changes from a different task (observed during the #87–#90 orchestration run). It passes on clean main, but it is a landmine for every future dirty-tree run.
Suggested fix
These were per-task scope-purity guards for the #81–#85 orchestration wave; after that wave merged, their anchors (that task's commit / that task's file list) no longer describe anything on main. Either delete both as one-shot artifacts of a completed wave, or rewrite them to assert a durable invariant (e.g. skip when the adding commit is a squash/merge commit, as the shallow-clone guard already does).
What happened
tests/orchestrate-review-pass.batstest "the commit that added this file touched no other BATS file" fails on a cleanmaincheckout (verified 2026-08-14, commit 276c921):Why
The test anchors on
git log --diff-filter=A— the commit that ADDED the file — to avoid the working-tree false positive its own comment describes. But PR #94 was squash-merged: on main, the commit that addedorchestrate-review-pass.batsis the squash commit276c921, which also added/touched several other.batsfiles (session-prompt-rework.bats,orchestrate-insight-emission.bats, …). The anchor is only stable on the branch where the original single-purpose commit existed; a squash merge rewrites it into a multi-file commit, so the check goes permanently red on main.The test already skips on shallow clones (fetch-depth 1) for an analogous reason — the anchor commit cannot be honestly resolved there either.
Related
tests/orchestrate-insight-emission.bats"changes vs branch HEAD are exactly the files this task owns" has the sibling problem in the other direction: it anchors ongit status --porcelainwith a hardcoded allowlist of the i83 task's files, so it fails in ANY worktree that has uncommitted changes from a different task (observed during the #87–#90 orchestration run). It passes on clean main, but it is a landmine for every future dirty-tree run.Suggested fix
These were per-task scope-purity guards for the #81–#85 orchestration wave; after that wave merged, their anchors (that task's commit / that task's file list) no longer describe anything on main. Either delete both as one-shot artifacts of a completed wave, or rewrite them to assert a durable invariant (e.g. skip when the adding commit is a squash/merge commit, as the shallow-clone guard already does).