# doyle ruling M5XKQ2DN — #297 fifth-window field result: PRODUCT RED on b8482445 (reconcile pre-write snapshot exceeds the 3 s child cap on a rule-heavy host); host clean; handoff squeeze reproduced (2026-09-14T06:50Z)

Run 20260914T063552Z (fifth window, epoch 1789367522, deadline 1789368122). Evidence: field-rig-r5-S6ESSJ3N/support/fp-run/20260914T063552Z/{handoff/003-*, setup-start.utc, setup-return.utc, setup.exit, d2-t1.*, timeline.txt, exits.txt, cleanup-failures.txt, findings.txt ledger}, liam KPVLV6CV + DTAK6RTC, hertz D6EMV5HZ, candidate source crates/spt-daemon/src/bootstrap_firewall.rs:142 and bootstrap_firewall/windows.rs:739-895, main f4e7635c (no bootstrap_firewall module), my own host measurements 06:46-06:48Z.

## What the candidate did (first field execution of `serve lan --bootstrap` on b8482445, elevated, scrubbed env, leg 003, one nonce)
- setup exit 0 in 6 s (06:43:18 → 06:43:24). stdout: `LAN_BOOTSTRAP_UP: http://192.168.1.81:29470/install`, sha 68d9f931…, LAN-EXPOSED. Listener came up on 0.0.0.0:29470 as the rig daemon (liam: pid 36988 = rig daemon.pid).
- stderr, verbatim shape: `bootstrap-firewall leg=verify-query program=powershell.exe wall_ms=2650 outcome=completed`; `bootstrap-firewall leg=verify-query program=powershell.exe wall_ms=3027 outcome=killed`; `LAN_FIREWALL_UNVERIFIED: powershell.exe: firewall command timed out; this does not prove the listener unreachable. Rerun … to retry admission.`
- NO `reconcile-write` leg ever ran. The owned pair (spt-core-bootstrap-inbound-tcp, -lan) is ABSENT afterwards: hertz's pre-teardown probe (both names absent in both stores, controls 2/2) and my census at 06:46Z (0 of 1017 rule blocks name the rig binary or port 29470).

## Mechanism (source, candidate b8482445)
`verify()` (windows.rs:764) takes `snapshot()` = one `verify-query` powershell child (line 749). Pair absent ⇒ `reconcile()`; FOLD-3 added a SECOND `snapshot()` at windows.rs:846 BEFORE the writes are rendered ("one extra invocation on the reconcile path; it cannot lengthen any single child past its own budget, which is where the 3000 ms is enforced" — lines 841-845). Every child is killed at a hard 3000 ms (bootstrap_firewall.rs:142, REQ-HAZARD-SUBPROCESS-TIMEOUT). The second snapshot was killed at 3027 ms ⇒ `?` returned Err ⇒ `reconcile-write` (line 876) never rendered ⇒ nothing written ⇒ clause (c)'s "the writes have landed by here" (884-889) never applied. The UNVERIFIED message then tells the operator to rerun, which on this host is a coin flip (below).
- Measured cost of the query on this host (1014 rules): the product's own first leg completed in 2650 ms; my equivalent under powershell.exe (`Import-Module NetSecurity` + named `Get-NetFirewallRule` + full ActiveStore enumeration + `Get-NetIPAddress`) = 1991 ms and 2080 ms wall, twice. The product's QUERY does more (per-rule filter walks, JSON) and the box carries the live fleet plus the driver's own captures. Margin to the 3 s cap is 10-30 %; two consecutive legs, one passed, one died.
- Not a regression: main f4e7635c has no `bootstrap_firewall` module (its `firewall.rs` PROBE_TIMEOUT 3 s guards the older UDP probe only). This arm is v0.70.0-new. F-A1-1 already measured a verify expiring mid-walk and clause (c) was the answer for the POST-write verify; the PRE-write snapshot has no clause and fails closed with no write.

## Verdict on #297 acceptance for b8482445 on this host class: NOT MET.
#297 acceptance: "remote tainet IPv4 client can GET /install with HOST RULE and tailnet policy admitting it". The host rule is never created here; the listener is up but unadmitted. The "actionable diagnostics" clause IS met (LAN_FIREWALL_UNVERIFIED names the leg, the program, the timeout, and the retry). Repeated start/stop, port override, second-machine GET: NOT REACHED. A rerun that happens to finish under 3 s would be an intermittent green and carries no acceptance weight (memory: intermittent-green-is-zero-information).
- Fix shape, MEASURED not directed (todlando's lane if the operator sends it there): (i) reconcile consumes the snapshot verify already took instead of taking a second one — the FOLD-3 "extra invocation" is the arm that died, and both snapshots are the same QUERY over the same store within one second; (ii) and/or the query leg's budget is sized to the store it walks rather than the flat 3 s meant to bound a hung child. Either removes this failure mode; (i) is one fewer child on every reconcile.

## Instrument / process findings from the same window (hertz's lane; do not block the product decision)
- IR-124/125 handoff squeeze is now RIPE, reproduced: setup request 06:41:26 → run_exactly 06:43:18 = 112 s, of which (liam DTAK6RTC, timestamps only) 39 s notification latency before liam could see the request, ~40 s reading it, ~30 s agent tool round-trips, ≤1 s compute. The driver's 120 s handoff cap and the t1 capture deadline (request+120 s) both died under that; the leg's own 8 steps took 9 s. The t1 launcher refused `-Seconds -4` (deadline − now − 5 < 1) — correct refusal, t1 UNAVAILABLE = labelled gap, not a launch-shape error. The elevated leg needs its own clock starting at run_exactly, and the capture budget must derive from the leg's clock, not the request's.
- Receipt landed 06:43:27, 1.3 s after the cap; the driver had already expired and does not re-read, so it froze `timestamp_order=UNMEASURED` and withheld stop and D3 (correct R6 behaviour). The late receipt is now verified by hertz (nonce once, exit 0). Post-hoc, the host carries NOTHING to remove: hertz's probe (2/2 controls) and my census agree, and the driver's owned daemon job (the listener's process) is CONFIRMED_GONE. Ruling: the frozen "PENDING" cleanup disposition is closed ON RECORD as NOTHING_TO_REMOVE with those two measurements cited; no D3, no elevated action, no ad-hoc cleanup. Ledger line `setup_elevated_exit=255` is the driver's timeout sentinel, not the command's exit (setup.exit = 0, receipt exit=0) — record both under their own names.

## Milestone consequence — STOP AND REFER (operator decision, not mine)
#304 cannot ride golden with #297 fulfilled on b8482445. Two shapes, facts only:
A. Fix rides v0.70.0: product change (windows.rs reconcile path) ⇒ NEW candidate sha ⇒ both consumer legs (Windows ~3457 cells, Linux ~3417 cells, ~1 h each last time) and a fresh field window (driver clock fix first, else the squeeze recurs) ⇒ then golden.
B. RELOCATE #297 to #307 (the operator's own precedent for #49/#267/#302: diagnostics ship, remedy moves): v0.70.0 ships `serve lan --bootstrap` with the LAN_FIREWALL_UNVERIFIED diagnostic and no reliable host admission on rule-heavy Windows hosts; golden proceeds on b8482445 with 7 fulfilled members; #297 must be relocated-or-back-to-eval, never dangling (PR #135 stipulation).
Golden stays HELD until the operator rules. deployah verifies the greenlit form either way.