Loop daemon: harden runtime-env resolution — bake resolved PATH into installed units, don't depend on nvm sourcing at runtime

[robercano-ghbot]

Incident (2026-07-10, first live daemon run)

The freshly armed pr-loop-<slug>.service polled fine but silently never merged an approved, CI-green PR (#105) and never wrote tick records: the systemd user PATH has gh but neither node nor claude, and merge-ready.sh (4 node calls), loop-census.sh (2), and write_tick_record all need node. Deadlock: unmerged PR ⇒ advance never fires ⇒ run_driver's nvm fallback (the only nvm-sourcing path) never runs. Hotfixed on main (4bf7dbb) by calling ensure_claude_on_path once in main().

Remaining hardening

1. Bake the resolved PATH into the unit at install time: arm-loop.sh runs in a real terminal with the user's full environment — it should substitute Environment=PATH=<dirname of resolved node/claude>:... into the installed unit (new __PATH__ placeholder in the templates). Runtime nvm-sourcing then becomes the fallback, not the mechanism; installs that use fnm/volta/system node work too.
2. Fail loudly, not silently: if node is unresolvable at daemon startup, the current warning only reaches the journal. Consider also emitting a tick record with result=env-error (or a main_dirty-style census line) so the cockpit loop-health panel (Cockpit: loop-health panel — last tick, cadence, verdict history, stall detection #85) can surface a daemon running in a degraded env.
3. Cosmetic: the daemon-driven tick record was written with an empty cadence field (manual full-env tick recorded WATCH correctly) — trace how cadence is threaded into write_tick_record when invoked via loop-event under the daemon and fix.
4. Tests: extend loop-daemon.test.sh with an env -i-style case asserting node-dependent steps work after startup resolution (guard the regression the hotfix fixed).

Labels: backlog (owner approves via planned).

[robercano-ghbot]

Additional hardening surfaced while walking the owner through phone-spawned planning sessions: claude-rc-<slug>.service is Type=oneshot + RemainAfterExit supervising a detached tmux — systemd cannot observe the claude remote-control process INSIDE the tmux session (the unit's own header documents this blind spot). Add a lightweight health check (e.g. ExecStartPost/timer that verifies the pane's process is alive, restarting the unit if not) so a crashed RC server doesn't silently take phone access away until someone attaches to tmux.

[robercano-ghbot]

Casualty #2 confirmed live and hotfixed on main: claude-rc-<slug>.service launched bare claude in tmux under systemd's PATH — pane died instantly, oneshot reported success (active (exited), Tasks: 0). Fix: __CLAUDE_BIN__ placeholder substituted from the arming terminal, and re-arms now restart claude-rc (a RemainAfterExit oneshot never re-runs on enable --now) while never restarting pr-loop mid-driver. Markers bumped to v2. Remaining scope here: same PATH-baking for pr-loop.service, degraded-env surfacing, RC health check, regression tests.

[robercano-ghbot]

Casualty #3, observed live: with the RC server itself fixed via absolute path (v2/v3), the SESSIONS it forks still inherited the systemd-started tmux server's minimal PATH and died at spawn (Session failed: Process exited with error, capacity 0/8, server otherwise Ready). v4 wraps the pane command in bash -c 'export PATH=<claude bin dir>:<system dirs>; exec ...' so all descendants resolve node/claude. Pattern for the remaining work here: fixing the immediate binary is not enough — every process TREE the units create needs the resolved PATH (this is the strongest argument for the unit-level Environment=PATH= approach in proposal 1, applied to BOTH units).