#297 -- EXACT HANDOFF PARAMETERS against plan 687ddd69 and executable 72d30901. Nothing dispatched, no host query, no plan expansion -- this is a parameter sheet, deliberately NOT committed as a plan revision. TWO PARAMETERS ARE UNRESOLVED AND ONE OF THEM BLOCKS THE RUN. == VERIFIED, not assumed == EXECUTABLE. .worktrees/304-w2-repr/target/release/spt.exe is STILL 72d309011415b419aabfdb0b4065df1183bfd0069a9f95b5779da62e43349b10, mtime Sep 12 16:17. I re-hashed it rather than trusting the r10 receipt. Per plan section 1 the sha256 IS the pin: if it differs at run time the run does not start and the subject is re-selected. CAPTURE PARAMETER SURFACE, read from d2_capture.ps1 (not invented): -CapturePoint t1|t2|t3 MANDATORY -RuleName string[] MANDATORY -- both owned names -Port int MANDATORY -IsolatedHome string MANDATORY -RunId string MANDATORY -OutPath string MANDATORY -ControlRuleName string MANDATORY -- "a rule known present" -AbsentControlName defaults to spt-core-bootstrap-inbound-tcp-d2-absent-control -PreSetupAbsence defaults UNRECORDED -SetupIntervalStart/End default UNRECORDED FIXED VALUES, reused from r10 rather than re-derived: RuleName spt-core-bootstrap-inbound-tcp , spt-core-bootstrap-inbound-tcp-lan Port 29470 (never 5470) Executable C:/Users/decid/Documents/projects/spt-core/.worktrees/304-w2-repr/target/release/spt.exe Setup verb env -u SPT_INSTALL_NO_FIREWALL SPT_HOME="" "" serve lan --bootstrap --port 29470 Teardown verb env -u SPT_INSTALL_NO_FIREWALL SPT_HOME="" "" serve lan --stop Nonce shape -001- / -002-, one nonce one execution Receipt rules receipt_must_contain a line EXACTLY: nonce: <...> receipt_must_also_contain a line 'exit=' with the ACTUAL exit status A zero exit is NECESSARY, never SUFFICIENT. == THE SEQ-001 SETUP REQUEST MUST NAME THE ELEVATED CAPTURE == r10's request ran ONE command. This one runs the setup AND THEN t1, inside the same elevated leg and the same nonce, because an elevated read cannot be added afterwards without a second handoff. run_exactly, two commands, in order, WITH THEIR EXIT STATUSES CAPTURED SEPARATELY: 1. the setup verb above, stdout -> handoff/001-setup-command.out, stderr -> .../001-setup-command.err 2. powershell -NoProfile -File "/d2_capture.ps1" -CapturePoint t1 -RuleName spt-core-bootstrap-inbound-tcp,spt-core-bootstrap-inbound-tcp-lan -Port 29470 -IsolatedHome "" -RunId "" -OutPath "/handoff/001-d2-t1.json" -ControlRuleName "" -PreSetupAbsence "" -SetupIntervalStart "" stdout -> handoff/001-d2-t1.out , stderr -> handoff/001-d2-t1.err THE RECEIPT MUST CARRY BOTH EXITS AS SEPARATE LINES -- per doyle, neither may overwrite or stand in for the other: exit= the SETUP's native exit d2_t1_exit= the CAPTURE's native exit A capture that fails inside a setup that succeeded must not read as a failed setup, and a failed setup must not be masked by a capture that ran. t2 and t3 are UNELEVATED and need no handoff: t2 beside D1 at the refusal before any teardown, t3 immediately before the teardown request is written. == SEQ-002 TEARDOWN REQUEST == Unchanged from r10's shape except run id, nonce and paths. One command, receipt carrying the exact nonce line and the real exit. Teardown remains followed by a MEASURED absence census, as r10 did. == UNRESOLVED PARAMETERS == 1. ControlRuleName -- NEEDED, PARTIALLY RECOVERED, NOT CONFIRMABLE BY ME. The positive control is the standing 5470 guard rule. From r10's PRESERVED portfields evidence (no host query), its identity at 2026-09-12T23:38Z was: Name {FF36EE51-2837-46D8-9AB8-2441D9070633} Enabled True, Inbound, Allow, Profile Private, SourceType Local, TCP, LocalPort 5470, RemoteAddress 192.168.1.0/255.255.255.0, Program Any THE NAME IS A GUID, and I can attest only that this rule WAS PRESENT THEN. Whether it is present NOW is exactly the thing a positive control must guarantee, and confirming it is a host query I am not authorized to make. Either hertz confirms it inside the run's own pre-flight (it is his rig and the check belongs there), or the control name is supplied at admission. DO NOT let the run discover at t1 that its positive control is absent -- a positive control that is itself missing turns every ABSENT into an unreadable result, which is the failure mode the control exists to prevent. 2. IsolatedHome -- THIS ONE BLOCKS THE RUN AS WRITTEN. The r10 isolated home STILL EXISTS on disk: .../scratchpad/bundle-r5/fp-home PRESENT Plan section 2 is explicit: the isolated home MUST NOT EXIST beforehand; if it does, the run does not start and the existing directory is LEFT UNTOUCHED. So the new run needs EITHER a fresh isolated-home path, OR r10's home MOVED -- and moved, never deleted, because it is retained evidence of the run this whole diagnosis rests on. My recommendation is a NEW path for the new run and r10's left exactly where it is; that costs nothing and touches no evidence. The choice is yours, not mine to make, but it must be made BEFORE the request is written, because the path appears verbatim in the setup command, the teardown command and every capture invocation. 3. SetupIntervalEnd at t1 -- STRUCTURALLY UNAVAILABLE, and I would rather name it than let it be filled with something false. t1 runs INSIDE the elevated leg, BEFORE the setup command has returned, so the setup's END instant does not exist yet at t1. t1 must therefore carry SetupIntervalStart and leave SetupIntervalEnd as UNRECORDED, with the interval closed at t2/t3 from the receipt's exited_utc. A t1 document showing an end instant would be reporting a time that had not happened. 4. RunId -- a new 2026MMDDTHHMMSSZ stamp, fixed when the run starts; every path above derives from it. Not unresolved so much as not-yet-instantiated, listed so it is not mistaken for reusable. NOT FLAGGED BECAUSE ALREADY SETTLED: port 29470, both rule names, the two verbs, the executable and its pin, nonce shape, receipt requirements, and the bounds in plan section 4. Still ungranted and unchanged: fresh elevation, fresh residual-process authorization, admission of the complete setup/capture/teardown request plus the residual-cleanup path. Nothing dispatched. Holding.