fix(driver): the pin would have walked every fire into a probe-hang — gate on onboarding (#558)

[sunholo-voight-kampff]

Follow-up to #666. Two defects, one of which would have taken the V1 loop down on the first fire after the reconcile. Found by reading 76ee4056c, which landed on dev while #666 was in review.

Defect 1 — the pin walks into a dead checkout

A pin worktree is by construction a path Claude Code has never seen, and an un-onboarded checkout makes headless claude -p block on a trust dialog it cannot display. Every model probe then hangs to its timeout (120s × 2 × 3 models ≈ 12 min) and the driver refuses with NO usable model in prefs — which reads as a quota outage, not as the harness fault it is. That had just cost the motoko mission its entire first unattended fire (charter V22).

Measured before writing any code:

onboarded=true    /Users/voightkampff/dev/sunholo-data/ailang
onboarded=ABSENT  /Users/voightkampff/.ailang-driver-pin/v1     <- the pin target

So #666, the moment the shared clone received it, would have converted a working-but-stale loop into a dead one. Stale-but-working strictly beats fresh-and-dead, so the pin now refuses when projects[<wt>].hasCompletedProjectOnboarding is absent — reported on both human channels like every other pin failure, with the exact one-line fix in the message. Undeterminable (no jq) counts as un-onboarded on purpose: pinning blind risks 12 minutes of hung probes; refusing costs staleness that is already reported.

It gates on hasCompletedProjectOnboarding, not the hasTrustDialogAccepted the error text names — 76ee4056c measured ailang-world at trust=false/onboarded=true and working, the control proving the named flag is not the gate. Test 8 pins both arms so a future edit cannot quietly switch to the wrong flag and stay green.

Defect 2 — a fix that disables itself after one use

Worktree existence was decided by string-matching git worktree list, but git records the resolved realpath, so on any path reached through a symlink (/var → /private/var, the macOS everyday case) the match silently fails. Fire 1 pins; fire 2 hits worktree add on an existing directory and refuses — from then on, permanently. Loud, but useless. Now decided by asking the worktree itself.

Caught by the new repeat-fire test, not by review: the original suite only ever fired once.

Consequence for deployment

Reconciling the shared clone is now safe with no further action — the pin declines and says why. Pinning switches on when a human runs, once per checkout:

cd ~/.ailang-driver-pin/<mission> && claude

Testing

48 assertions (31 + 17), make test-launchd-drivers, bash 3.2.57, CI job on macOS. New coverage: un-onboarded → refuse + fire still runs + never reports pinned; trust-flag-alone does not satisfy while onboarding-flag does; no-jq fails safe; second consecutive fire pins.

The happy path runs against a synthetic ~/.claude.json in a fake HOME rather than with the check disabled — so a gate regressed to always-refuse fails tests 1–6, and one regressed to always-allow fails test 7.

🤖 Generated with Claude Code