Worktree without .venv silently tests the primary checkout, so branch-local regressions read green

[valorengels]

Problem

A git worktree under .worktrees/ that has no .venv of its own silently resolves imports from the primary checkout. Tests run there exercise main's code, not the branch's, and a branch-local regression reads green.

Found while verifying PR #3028. Reproduced:

$ ls -d .worktrees/wave1-hotfix-sweep/.venv
NO .venv in worktree

$ cd .worktrees/wave1-hotfix-sweep
$ python -c "import tools.push_ancestry_guard as g; print(g.__file__)"
/Users/valorengels/src/ai/tools/push_ancestry_guard.py     # <-- PRIMARY checkout

With PYTHONPATH pinned to the worktree it resolves correctly, and a test that had been passing fails:

$ PYTHONPATH=$PWD python -m pytest tests/unit/test_push_ancestry_guard.py -q
FAILED tests/unit/test_push_ancestry_guard.py::TestPushTargetParsing::test_empty_stdin_falls_back_to_head
1 failed, 16 passed

Without the pin the same file reported 17 passed.

Why this matters more than one PR

This is a verification-integrity bug, the same family as Wave 0 in docs/bug-backlog-waves.md. A lane that runs its suite in a worktree and reports "N tests pass" may be reporting on main. In PR #3028's case it produced a confidently false claim ("1545 unit tests pass") in a PR body, and the failing test was only caught by an independent reviewer who happened to force PYTHONPATH.

Any lane, on any branch, is exposed. The failure is silent and biased toward green, which is the worst direction: it hides exactly the regressions the run exists to catch.

Why the existing guard does not catch it

docs/features/worktree-venv-isolation.md and scripts/pytest-clean.sh guard the off-pin venv case — a venv on the wrong interpreter aborts the run. There is no guard for the absent venv case, which degrades silently to the primary checkout's environment instead of failing closed.

The editable install is what makes it silent: the primary venv carries an editable path entry pointing at /Users/valorengels/src/ai, so import tools... always finds a real module and never raises.

Suggested direction

Fail closed rather than fall back. scripts/pytest-clean.sh already aborts on an off-pin venv; extend it to abort when invoked from a git worktree whose root has no .venv, naming the remedy (uv sync in the worktree). A green run from a worktree should be impossible unless the code under test is that worktree's.

Worth checking whether agent/worktree_manager.py should provision a venv at worktree creation, so lanes are correct by construction rather than by a check.

Acceptance criteria

• A pytest run started from a worktree with no .venv aborts with a named remedy instead of running against the primary checkout.
• The abort names the worktree path and the missing .venv.
• A red test demonstrates the abort fires (per Gates that cannot fire: require demonstrated-red for verification rows, guards, and skill self-checks #2658 — a guard nobody proved could fail is not a guard).
• docs/features/worktree-venv-isolation.md documents the absent-venv case alongside the off-pin case.

Found during: PR #3028 review (#3028 (comment))

[valorengels]

Adjacent evidence from #2334's build (2026-09-02, PR #3082): in a .venv-less worktree, a failed uv sync (unparseable lock) still creates .venv before failing — so on retry, scripts/pytest-clean.sh's off-pin/.venv guard no longer fires and pytest resolves from whatever venv is ambient. The nightly classifier is unaffected (provisioning failure buckets inconclusive first), and test_provision_steps_own_a_process_group etc. cover the classifier side — but the wrapper-guard bypass is generic to any worktree consumer. Surfaced by the lane's test engineer; recording here rather than filing a duplicate.

[valorengels]

Reopening on the comment above: if a failed uv sync creates .venv as a side effect, the wrapper guard this issue shipped is bypassable on retry. The claim is from #2334's lane and not yet independently reproduced — first task for whoever picks this up is to verify it (attempt uv sync in a scratch worktree with a corrupted lock, check whether .venv exists afterward). If it doesn't reproduce, close again with the falsification recorded.

[valorengels]

Second sighting, different mechanism (2026-09-04, PR #3093 review): in a worktree OUTSIDE .worktrees/, tools.* resolves through the primary checkout's editable-install path entry, so tests import the main checkout's code instead of the branch's (test_promise_gate_measurement.py failed to collect until the reviewer pinned PYTHONPATH). Same hazard class as the .venv-less case above — worktree tests silently exercising the primary checkout — via the editable path rather than the venv guard.

[valorengels]

Third sighting, third mechanism (2026-09-04, PR #3123 review): uv sync without --extra dev provisions a worktree whose .venv EXISTS but has no bin/pytest — pytest-clean.sh's guard checks for .venv presence, not for pytest inside it, falls through to PATH, and the branch's tests silently exercise the primary checkout. Cost the reviewer three phantom FAILs. The guard should assert .venv/bin/pytest specifically (or invoke via .venv/bin/python -m pytest and fail hard when absent).