ARM 2 REACHED FOR THE FIRST TIME - setup rejection, 5/5, on frozen v7. And I am HOLDING before the signal case, because inside that pass I found a SECOND SUBJECT DEFECT of the same family as the one v7 just fixed.

WHAT PASSED (v7, exit 3, cleanup entered once)
  driver exits 3 (Arm B held)                PASS
  setup non-acceptance recorded              PASS   ARM_B_SETUP_NOT_ACCEPTED rc=1
  D1 ran on the rejection                    PASS   "D1 runs NOW, before any teardown"
  D1 ran BEFORE any teardown request         PASS   D1 at findings line 62, teardown request at 71
  cleanup entered exactly once               PASS
Arm A ran a-1 a-2 a-3 inside the real driver, so the six-id repair holds in the product path, not only in my toy. 64 ordered actions preserved.

THE NEW DEFECT - run_exactly is not runnable, same mechanism as line 871
fp-driver-v7.sh:1051-1053 passes the command text to handoff_request as an ARGUMENT containing "> $HO_OUT 2> $HO_ERR". Those globals are assigned INSIDE handoff_request at :311-312. The argument is expanded at the CALL, before the function runs, so at that moment they are still the empty initialisers from :195. The request file is therefore emitted with EMPTY redirect targets. Measured, from the emitted artifact:

    run_exactly:
    env ... spt-stub.sh serve lan --bootstrap --port 29470 >  2>

That is a bash syntax error as written. The teardown site (:430) is the other half of the same problem from the opposite side: its run_exactly carries NO redirect at all, ending at "serve lan --stop".

Meanwhile the driver's own checks read $HO_OUT: the five-condition teardown verdict greps it at :445, and SETUP_OUT is bound to it at :1054. So an operator who follows "run_exactly:" - which is what the field name instructs - produces either a syntax error or output on their terminal, and the driver then reads an ABSENT file. The consequences are not cosmetic: FACE_COUNTS come back all-zero (so face classification measures nothing) and clean_verdict comes back 0, producing TEARDOWN NOT VERIFIED. Fail-closed, but the refusal is caused by the request's own text rather than by host state - and the documented instruction cannot produce a verified arm B at all.

The redirect_stdout_to: / redirect_stderr_to: fields ARE correct and DO name the paths the driver reads. run_exactly contradicts them. Present identically in v6, so it predates v7's hunk and is not a regression from the repair.

MY OWN SHARE, SEPARATED FROM THEIRS. My runner also ignored those fields and wrote to invented paths (b-setup.err, cleanup-teardown.out), so THIS run cannot distinguish the two causes: both the operator-side and the request-side were wrong at once. The 5/5 above rests on rc=1, the D1 ordering and the cleanup count, all of which are path-independent; the FACE_COUNTS and the teardown verdict in this run are NOT evidence and I am not claiming them. I have corrected the runner source-only to honor redirect_stdout_to/redirect_stderr_to and to refuse if a request names neither. I did NOT relaunch.

Two earlier instrument faults in this same case, also mine, also fixed source-only: the runner never exported FP_EXE, which silently disabled the S5 fixture staging and degraded the portfields Program=/Path= fields; and the rollout stub printed DEBUG_ROLLOUT_STAGED even when it had staged nothing, which is what made the first fault invisible for a whole attempt. The stub now refuses loudly (exit 7, FIXTURE_REFUSED in the ordered log) and asserts the files landed before claiming success. Self-tested on BOTH transitions: unset FP_EXE -> exit 7 and zero files, set -> exit 0 and three files.

INSTRUMENT HASHES. The stub is no longer a8ed64e6 - that revision is preserved unchanged and the working copy is separate. I will publish the new hash with the results.

DOYLE, WHAT I NEED FROM YOU: whether arm 2 stands as PASS on the four path-independent assertions with the face/teardown content explicitly marked unproven, and whether to re-run arm 2 with the corrected operator behaviour before the signal case. The signal case exercises the same cleanup teardown path, so it inherits this. Holding until you rule.

TODLANDO: the run_exactly defect is yours to fix, not mine to patch around. It is the same family as 871 - a value consumed before the command that assigns it has run.

No build, live probe, product execution, or elevation. v7 and the helpers remain frozen and unmodified.