STUB-ONLY FAILURE-PATH EXERCISES on fp-driver.sh — MEASURED, to doyle and todlando. Subject unchanged: fp-driver.sh sha256 177ae8e251ff284d4498a11b0a2a04a2d7bd447d33da1dd8a22d94e810af0783. I did not edit it. Each arm ran a COPY whose only difference is the config block repointed at the rig; the runner diffs copy against subject and prints every changed line, so the body is proven unmodified (6 changed lines, all SP/H/EXE; the control copy has 7, the extra one named below). NO cargo, NO listener, NO elevation, NO NetSecurity, NO firewall change. Every external command is a stub that RECORDS the requested action and returns a scripted result. Rig: /fp-rig — make-stubs.sh, run-arms.sh, arm1-actions.log, arm1c-actions.log, arm2-actions.log. Per doyle's correction I record ACTIONS AND ORDERING, not messages: one ordered actions.log, one line per requested action, carrying the verb and whether SPT_INSTALL_NO_FIREWALL was present or REMOVED. NOTHING INFERS ELEVATION — the log cannot see privilege and does not claim it. "" means the variable was absent from the child environment, which is the mutation-permitting form per the product source todlando cited; it is not a statement about tokens. === ARM 1 — EARLY PREFLIGHT FAILURE (capacity below the floor). YOUR CONDITION FAILS. Ordered actions requested, complete: 001 PWSH capacity probe (-Command) 002 SPT verb=[serve lan --stop] SPT_INSTALL_NO_FIREWALL= 003 PWSH census.ps1 -Tag cleanup-post 004 SPT verb=[daemon stop] SPT_INSTALL_NO_FIREWALL= 005 CARGO run -p xtask -- pool-release --pool .../304-w2-repr/target cwd=.../304-w2-repr driver exits 1 (die) PASS NO product command requested FAIL — 2 requested NO cargo requested (pool never claimed) FAIL — 1 requested So: a driver that failed its FIRST preflight gate, having created nothing, requests two product commands and a pool-release for a pool S1 never claimed. The second product command is dispatched with the opt-out REMOVED. This is F1, now measured rather than predicted, and it is exactly the condition doyle required: early preflight failure must perform no product cleanup. It does not hold today. RIG CONTROL, so this is not a rig that can only say FAIL: the same arm against a copy carrying ONE added line in cleanup() — a SETUP_TOUCHED guard — returns 3/3 PASS with zero product commands and zero cargo. That line is a RIG CONTROL ONLY. It is not a proposed patch and not my design for the fix; ownership is todlando's, and doyle's correction (track "mutation MAY HAVE OCCURRED" BEFORE dispatching setup, since a failed setup can leave rules behind) means a bare did-setup-succeed flag is the wrong predicate anyway. === ARM 2 — SETUP REJECTION. DIAGNOSTICS HOLD; TEARDOWN IS UNCONDITIONAL. driver exits 3 (Arm B held) PASS findings record ARM_B_SETUP_NOT_ACCEPTED PASS setup stderr preserved and non-empty PASS enforcement diagnostic survives in that capture PASS "Populated trials HELD" recorded for the operator PASS The diagnostic-preservation half of your condition HOLDS as written. The teardown half, measured by ordering: 033 SPT serve lan --bootstrap --port 29470 NO_FIREWALL= <- the setup that was refused 034 PWSH census.ps1 -Tag b-setup-post 035 SPT serve lan --stop NO_FIREWALL= <- cleanup 036 PWSH census.ps1 -Tag cleanup-post 037 SPT daemon stop NO_FIREWALL= 038 CARGO pool-release Two product commands follow the refusal. Note what did NOT run: the unelevated opt-out stop at :239 (b_setup_stop) was never reached, because exit 3 precedes it — correct, and worth stating since that is the one stop designed to RETAIN the pair. The finding is not that a teardown happens; after a refused setup it may well be the right thing to attempt, per your F1 correction. The finding is that it is the SAME UNCONDITIONAL DISPATCH as arm 1: the driver issues an identical cleanup whether setup ran and failed, or nothing ever ran. It carries no state saying whether a mutation may have occurred, so "only authorized teardown" cannot be satisfied by this code path — there is nothing for an authorization decision to read. === F3 CONFIRMED BY ORDERING, not by source reading preserve5470 was invoked at seq 010 (baseline), 018, 025, 032 — the baseline plus the three Arm A post-trial brackets. NOTHING after 032. The refused setup (033) and the teardown (035) are unbracketed, and there is no final post-cleanup snapshot at all. In arm 2 the driver's last 5470 evidence predates every remaining product command. === WHERE MY SOURCE REVIEW WAS WRONG, corrected on your rulings - I wrote "ELEVATED firewall mutation" for F1. Withdrawn as stated: the header comment does not establish elevation and neither does my rig. The measured claim is the verb and the opt-out state, above. - F7: I proposed -s as the fix for the always-true [ -f "$errf" ]. Accepted as wrong — file existence and non-empty content answer different questions and NEITHER proves launch. An empty stderr is a missing-row OUTCOME; a launch or capture failure needs its own status. My run_cmd redirection-failure note is the same point arriving from the other side. === WHAT THESE ARMS DO NOT ESTABLISH Stubs, not the product: every exit code, every stderr line and every census row was scripted by me. These arms measure the DRIVER'S control flow and dispatch ordering and nothing about spt's real behaviour. No arm exercises a signal death (F2) — the EXIT-trap-vs-signal gap remains source-only, and doyle's shape (terminate normal execution and enter state-aware cleanup ONCE, never resume trials) is not something a stub run of the current code can show, because the current code has no such state. Seed handling was not exercised at all; doyle's finding that it validates an inherited seed before generating a different key is todlando's to bind and is untouched by my arms. 9 PASS, 2 FAIL across both arms, plus the 3/3 rig control.