e2e: the tmux suite never touches the developer's own background timer

[AbirAbbas]

Closes #1631

The tmux suite's firing subtest approves a standing reminder in the real binary. The approval writes the timer definition under HOME and then runs systemctl --user enable --now codeaf-tick.timer, and the suite launched the binary with the developer's own HOME and PATH. So a run replaced the developer's codeaf-tick unit with one pointing at the test's temporary state root and the checkout's bin/codeaf, and every five-minute pass failed once that checkout was gone.

Every codeaf process the e2e package starts now goes through one of two doors: the tmux rig (startWithEnv, and so start and startFresh) or guardedCommand (tick, chat --once, engine --stop, do, manual). Both put systemctl, launchctl and crontab stubs first on PATH, which record their arguments and exit 0, and point HOME at a throwaway login folder beside the state root, unless the scenario named a HOME of its own. Stubs alone would not be enough: the product writes the unit files itself, in Go, before it calls the scheduler, so HOME has to move too. The state root, the provider key the rig hands the child, and the engine socket path are unchanged. The engine daemon the window spawns inherits the same HOME and PATH.

Validation contract

• Every codeaf launch in the package goes through a guarded door, and a new launch that doesn't fails the untagged package test, naming the file and line. Proved by TestEveryLaunchOfCodeafStandsBehindTheHostGuard. It failed on the dev sources before the fix, naming all seven launchers, and it failed again when tick was temporarily put back to a bare exec.Command.
• The gate catches each unguarded shape: a dynamic exec program, a literal codeaf, a tmux respawn built outside the rig, and an Env reassigned after the door. Proved by TestTheHostGuardGateCatchesAnUnguardedLauncher, against a synthetic source.
• Under the guard, systemctl, launchctl and crontab resolve to the stubs, succeed, and log one line per call. A scenario's own HOME is kept, the developer's HOME is replaced, and a scenario's own PATH gets the stubs prepended. Proved by TestTheHostGuardStandsInForTheMachinesScheduler.
• The product's own standing install, run under exactly the environment the doors hand a child, writes its definition into the throwaway login folder and leaves the machine's timer files byte-identical. Proved by TestAnInstallUnderTheGuardNeverReachesTheMachinesTimer, which refuses to call Install until both the stub and the throwaway HOME are confirmed.
• End to end: TestTUIE2E/the_firing_reaches_the_person still passes. The machine's timer files hash the same before and after, as the subtest asserts itself. The stub log shows systemctl --user enable --now codeaf-tick.timer after the approval, and the rig's own service definition names the rig's CODEAF_HOME.

How it was verified

• The tagged firing subtest was run once against a real model: it passed in 403s and did not skip. The stub log read systemctl --user daemon-reload and then systemctl --user enable --now codeaf-tick.timer. The definition sat under the rig's login folder with the rig's CODEAF_HOME and the checkout's binary. The SHA-256 of the developer's codeaf-tick.service and codeaf-tick.timer was identical before and after.
• The engine daemon left running after the subtest carried the guarded HOME and PATH.
• make pr-ready BASE=origin/dev passed, and go vet passed under the e2e, docker_e2e and ssh_bench tags.

What it deliberately does not do

• It does not change the product. How a first approval treats a timer another installation owns is First standing approval can take another profile’s shared background timer #1618 / fix(standing): preserve shared timer ownership on first approval #1622.
• It does not cover remotebench_test.go (ssh_bench), which runs the product on another machine over ssh where a local stub cannot reach, or remote_test.go (docker_e2e), whose containers have their own scheduler.
• It does not stop the engine daemon the firing subtest leaves running after it ends. That is older behaviour; the daemon now holds only the guarded environment.

🤖 Generated with Claude Code