# v5 stub exercises — what is a driver result and what is not

hertz, 2026-09-12. Subject: `fp-driver-v5.sh` sha256 `6f409f9123ee0bd51c6b7ba98a27207b7bc1cf820b42b13c75a381dff55b9315`, preserved unmodified in `../v5-as-delivered/` with all five instruments; that hash set is identical to todlando's DELIVERY2 manifest.

Every run used a byte-preserving copy differing **only** in the config block (`SP=`, `EXE=`), 4 changed lines, 0 outside — `arm1-config-only.diff`, `arm2-config-only.diff`. Stubs only: no cargo, listener, elevation, live probe, firewall change, or product execution.

## ARM 1 — early preflight failure. A v5 RESULT: 5/5 PASS.

Two independent early gates, both satisfying doyle's condition that an early preflight failure performs no product cleanup:

| gate | halt reason |
|---|---|
| capacity parser | `capacity probe for 'preflight' produced a non-numeric FREE_GIB` |
| capacity hard stop | `free 1.00 GiB is below the 32 GiB HARD STOP before 'preflight'` |

Assertions, identical at both gates:

    driver halts nonzero                 PASS
    NO product command requested         PASS
    NO cargo requested                   PASS
    NO resource state was ever marked    PASS
    cleanup entered exactly once         PASS

Ordered actions: the elevation probe, the capacity probe, nothing else. `findings.txt` carries `CLEANUP_SKIP` for listener, firewall, daemon and pool, each naming the state that was never marked, and `GUARD_ASSERT_SKIPPED final-post-cleanup — no baseline was taken; nothing to compare against`. That last line is the F3/F6 shape closed correctly: the guard declines to speak rather than printing a false `GUARD_UNCHANGED`.

Logs: `arm1-actions.log` (hard-stop gate), `arm1-parserpath-actions.log` (parser gate).

## ARM 2 — setup rejection. NOT a v5 result. Two launches, two instrument failures, both mine.

**Launch 1 — my python stub answered every call identically.** It returned `d1_render`'s PRECHECK line to the driver's own inline CI-json parse, so the driver read `Named-Rules=1`, `PersistentStore=0`, `Get-NetIPAddress=1`, `ActiveStore=2` as live CI run ids and asked `gh run view` for each by that name. A stub that answers every invocation the same way is not an instrument. Ordered actions preserved; nothing in that run says anything about v5.

**Launch 2 — my runner-census stub emitted no `RUNNER_CENSUS` row.** The driver halted: `runner census invalid (self_seen false or empty table) — a clean zero from a dead enumeration is not a quiet box`. Log: `arm2-retry-INSTRUMENT-FAILURE-actions.log`, findings: `arm2-retry-findings.txt`.

**The setup-rejection path was never reached.** No handoff was requested, no receipt was written by the liam-stub watcher, no D1 ran, no teardown was requested, and no state marker was created. Nothing here confirms or refutes doyle's handoff blockers, and nothing here is evidence about ordering (request → receipt → census) or about D1-before-teardown.

**One thing IS attributable to v5, obtained accidentally:** its `box_gate` refused my malformed census rather than reading the absent fields as zeros. That is a fail-closed instrument check working, measured against a genuinely broken instrument — the strongest kind of evidence for that particular guard, and the only v5 statement arm 2 supports.

Per doyle (V4ZTSF3K) no further v5 launch was made, including another instrument repair and retry. v6 is the next acceptance subject, and v5's arm 1 passes do **not** transfer — each case is re-measured against frozen v6.