Repository navigation
Worktree isolation covered the files a worker writes, not the host tool environment it can reach.
The incident
Dogfooding a live Herdr dispatch, a worker installed from inside .tenx/worktrees/SPC-037-T1, leaving an editable pointer at that worktree's src. tenx reconcile removed the worktree, and the operator's global tenx died with:
ModuleNotFoundError: No module named 'tenx'
The tool that should have reported the damage could not run to report it.
What ships
- The brief forbids it. Every dispatched worker is now told the worktree
is deleted at teardown, that any install pointing at it keeps pointing at a
vanished path, and to verify withpython3 -m tenxand
python3 tests/smoke_test.py --moduleinstead. An install requirement gets
reported, not performed. - Dispatch records a snapshot. Every receipt carries the host install's
resolved source path, captured before the worker runs. - Teardown checks.
tenx reconcileandtenx abortverify the installed
tenxcommand after removing the worktree and report the breakage with the
recovery command. The merge still completes — repairing a host-level tool
stays an explicit operator decision. tenx doctorreports it when the running tenx resolves inside
.tenx/worktrees/.
Why two signals
The snapshot comparison alone was not enough, and the first implementation
missed the real incident because of it: the snapshot only sees the interpreter
reconcile runs in, while the damage lands on whichever interpreter backs
the globally installed CLI. Teardown therefore also asks that command directly
whether the operator can still run tenx.
Verified
Against a faithful reproduction — an isolated venv whose install pointed at a
dispatch worktree, with the worktree then removed — tenx --version failed with
ModuleNotFoundError before the fix and the teardown reported it after, with
the merge still landing. 15 new smoke checks pass in both module and
install-path modes.
Upgrade with tenx update.