### IR-79 — golden's 32 GiB floor is BELOW the measured 67.4 GiB Windows suite footprint, so a start floor passes a box that cannot finish - **Status:** OPEN, filed by doyle 2026-09-08 at the #272/v0.68.0 golden r2 triage. · **Origin:** run 34262154550 @ `25e60015` (shaped on `e4444413`), Windows test job 102182665033: every product step green (Phase A 3346/3346, Phase B 234/234, Summary 2, FAIL 0), the ONLY reds were the two in-job floor gates. `FLOOR_START` 97,649,786,880 B PASS at 18:47:23Z -> `FLOOR_DOCS` 25,284,501,504 B RED at 19:31:55Z -> `FLOOR_END` RED. Consumed in-job: 67.4 GiB. - **Mechanism:** `golden.yml` derives 32 GiB as "the observed tens-of-GB full-suite footprint rounded up to the next binary boundary, preserving headroom for one complete run" (comment above the Windows start floor). The measured footprint is 67.4 GiB, so a start reading anywhere in [32, ~100) GiB passes and the job then walks under the floor by construction: box baseline 91 GiB minus 67.4 = 23.5 < 32. This is a shortfall of the DERIVATION, not a rate, not a product red, and not the instant-vs-sustained face IR-46 files (that face is fixed by the FLOOR_DOCS re-read, which is what caught it). The start floor must be footprint + end-floor (~100 GiB) or it asserts nothing about finishing. - **Coverage consequence (the load-bearing part):** the Windows `Docs drift gate (CLI ref + llms links)` step is sequenced BEHIND `FLOOR_DOCS`, so it SKIPPED and r2 held NO Windows CLI-ref axis at that sha until the rerun. A floor red that skips a gate is a coverage hole wearing a disk red. - **Kin:** [[IR-46]] (a floor asserts an instant), [[IR-59]] (pool arithmetic, LNK-class reds that name no disk), [[IR-64]] (the operator-payload reservoir that sets the box baseline; its ripe-when arm — a golden that dies at the floor despite adopted pool discipline — FIRED here in the in-job form), [[IR-73]] (second half BUILT: the within-job re-read exists and is what produced the FLOOR_DOCS reading), REQ-CI-FREE-SPACE-PREFLIGHT. - **Coupling (deployah 23:54Z, from `golden.yml` at `25e60015`):** the Windows `DISK docs floor` (:616) and `Docs drift gate — windows` (:629) carry only `if: runner.os == 'Windows'`, no `always()`, while `DISK end floor` does (`always() && runner.os == 'Windows'`, ~:705). Actions' default is "previous steps succeeded", so ANY Phase B red skips the docs axis by construction — observed three times at this sha (floor red, ttl cell, ttl cell). The docs gate is therefore never independent evidence: it can only be banked when Phase B is green in the same job. Remedy line: gate the two docs steps on `!cancelled()` plus the success of the steps they actually depend on (checkout/build), not on Phase B — a rig change, new sha, hertz workflow rider slot. - **Remedy shape:** re-derive the start floor from the measured footprint (67.4 GiB Windows, Linux to be measured) plus the 32 GiB end floor, print the footprint (start minus end free) on every run so the number re-measures itself, and keep the 32 GiB literal only for `FLOOR_END`. - **Ripe when:** next `golden.yml` touch (hertz workflow rider slot). · **Size:** small — one literal per start-floor site + one printed subtraction. ### IR-80 — two-host ceremony halves are INDEPENDENT jobs on DIFFERENT runners (A Windows/hfenduleam, B Linux/kitsubito); B's 900 s budget runs on B's own clock, so any older queued Windows job starves A and reds B deterministically, and the panic text blames pairing - **Status:** OPEN, filed by doyle 2026-09-08 at the #272 golden r2 triage. · **Origin:** run 34262154550, twohost-b job 102207296960 (log 81,692 B, sha256 67403f04…8030): role B built, rostered, polled PAIR_MEET_UP every 30 s from 19:34:30Z, and hit the rig_wait barrier "pairing: A rostered via the daemon-hosted responder" at its 900 s deadline 19:49:17Z (`crates/spt-daemon/tests/twohost.rs`, exit 101, 2 passed 1 failed). twohost-a (102207296985) was QUEUED from 19:32:13Z with no runner: the Windows runner went to thin ci run 34261096301 (post-merge on main @ `e4444413`) the second the golden test job released it at 19:31:56Z. - **Mechanism:** `golden.yml` sequences twohost-a and twohost-b after `test`, but they are two jobs on two runners (measured 2026-09-08 20:56Z via the jobs API `runner_name`: twohost-a on hfenduleam, twohost-b on kitsubito), and GitHub's queue does not honour a workflow's intra-run job ordering against a FOREIGN run on either runner. B starts, its whole budget ticks against a partner that has not been scheduled, and `rig_wait` panics `never converged on the rig: {what}` — a text that reads as a pairing defect. The lanes were not at fault, and twohost-a's outcome was predetermined once B exited (a later A pass would be vacuous). - **Kin:** [[IR-76]] (hfenduleam is golden runner AND builders' box; the job-start census cannot see a competing GitHub run either), [[IR-62]] (rig collisions on shared runners), the W1 two-host rig, `a-barrier-cannot-ride-a-carrier-its-sender-outlives` (memory, same family: a barrier needs the receiver's own answer). - **Remedy shape (pick at rider time):** (1) start barrier on B keyed to A's job having STARTED (a run-scoped artifact or a `needs`+matrix collapse into ONE job that spawns both roles), or (2) B's deadline clock starts at first A-rostered signal with a separate, longer "A never appeared" budget, or (3) the panic names the missing partner's job state so triage does not chase pairing. Any option: the two-host halves must never share a runner queue with a foreign run while one half waits. - **Ripe when:** next `golden.yml`/twohost rig touch. · **Size:** small-medium (job shape or barrier rework + panic text). ### IR-81 — `pool-release` via `cargo run -p xtask` REBUILDS xtask INTO the pool it is releasing, so a reaped pool regrows ~2.8 GB in silence - **Status:** OPEN, filed by doyle 2026-09-08 from hertz's reap report (20:00Z) during the #272 golden r2 repair. · **Origin:** hertz reaped hertz-lane4 / hertz-repin / hertz-percell-id target subtrees (Length-sum upper bounds 68.16 / 47.11 / 8.79 GB) and then ran `cargo run -p xtask -- pool-release …` from each worktree: cargo rebuilt xtask into the just-reaped `target/` (2.8 GB back in lane4, partial in repin), nothing printed said so, and the descendancy stopper killed the second before it finished. Removed by hand afterwards; the post-reap free reading on the record (275.95 GiB at 19:55:51Z) predates the regrowth. - **Mechanism:** the documented verb (AGENTS.md: "drop it with `pool-release`") is a `cargo run`, and cargo's default target for that run IS the pool being released. The verb's own success path recreates the state the operator just measured away; a teardown step that runs it AFTER a reap undoes part of the reap and leaves the recorded free reading stale. - **Remedy shape:** either (a) `pool-release` documented and scripted as a PREBUILT `xtask.exe` invoked against `--pool ` from another pool, or (b) the verb refuses when its own `CARGO_TARGET_DIR`/default target equals `--pool` and prints the prebuilt form, or (c) the reap recipe orders release BEFORE the subtree delete. Memory banked 2026-09-08 (`pool-release-rebuilds-xtask-into-the-pool-you-just-reaped`); this entry is the durable home. - **Kin:** [[IR-31]] (pool budgeting), [[IR-56]] (pool-claim identity from CWD — same verb family, same "the tool acts on where it stands" shape), releases#103. - **Ripe when:** next xtask pool-verb touch or the teardown runbook edit. · **Size:** tiny — one guard or one doc line. ### IR-82 — hfenduleam's Windows Firewall drops cold inbound UDP to the runner-built test exes, so the two-host rig's first B→A claim (W2 helper) reds for its whole 900 s budget and the panic blames A - **Status:** OPEN, NEEDS-OPERATOR (box rule), filed by doyle 2026-09-08 at the #272 golden r2 terminal triage. · **Origin:** run 34262154550 @ `25e60015`, twohost-a 102229928746 (`two_host_web_helper_role_a`, :968, 900.40 s) and twohost-b 102229928689 (`two_host_web_role_b`, :559, 910.20 s): B logged 75 × "A not ready … broker QUIC op exceeded the 10s bound (peer unresponsive)" from 20:49:49Z to 21:04:37Z and was never ADMITTED. Ladder green both sides; both halves started 20:41:23Z on their own runners (not IR-80's starvation). - **Mechanism (MEASURED 21:11Z):** the box's firewall policy is `BlockInbound,AllowOutbound` on all three profiles (Ethernet and Tailscale both Private). Inbound allow rules exist only for exes under `Documents\projects\spt-core\target` (interactive Allow clicks) and under the DEAD pre-rename runner path `_work\spt-core\spt-core`; exactly ONE under `_work\spt-bs-core` (its `target\debug\spt.exe`, the CLI, not the binder — deployah's count, mine had said zero), none for any `twohost_web-*.exe`. `Get-NetFirewallProfile` shows `DefaultInboundAction = NotConfigured`, whose effective default IS block: the block is Windows' default, not a configured policy, so there is no policy to "restore". The runner is a service (`.\decid`), so the Allow dialog that minted the old rules cannot appear. A's helper cell 3 bound `broker udp 7483` inside `_work\spt-bs-core\spt-bs-core\target\debug\deps\twohost_web-f73bc44be13353fb.exe`; B dialled `100.68.35.65:7483` cold. Probe: a rule-less pwsh UDP listener on hfenduleam:7483 received 0 of 3 datagrams from kitsubito `100.98.197.12`; the reverse control (python listener on kitsubito:7483) received 3 of 3 from hfenduleam. - **Why three faces from one cause:** the shared-key rig (pre-`e4444413`) reached A only through holes A's OUT-dialling cells (7480–7482) had opened for `id_a` — six 10 s bounds until B's magicsock fell onto one of those paths, then ADMITTED (the 63 s stall, helper-stall memory), or onto a live same-key sibling that never replied (the 21 min hang in 34239258523). Per-cell A identity (`id_a_for`, `e4444413`) removed the accidental route by construction, leaving only the cold path, which the firewall drops. hertz's one-box discriminator "vanishes" was true on one box because one box never crosses the firewall. Product and rig are both exonerated; the rig's `a_addr` comment already names W2 as the first A-ward claim. - **Remedy (two halves):** (1) BOX, operator-owned, elevated on hfenduleam: `New-NetFirewallRule -DisplayName "spt-ci two-host rig UDP-In (kitsubito only)" -Direction Inbound -Action Allow -Protocol UDP -LocalPort 7460-7499 -RemoteAddress 100.98.197.12 -Profile Any` (rig ports at the sha: ladder 7460/7461; web `PORT_OFFSET` 20 → A cells 7480–7483, B 7481; the A-ward surface today is exactly UDP 7480–7483 — deployah's tighter range — and the whole range moves with any `SPT_TWO_HOST_PORT_A` override, so the rule must move with it); program-path rules are the wrong shape because the exe hash changes per build. Verify with the same probe (3/3) before any rerun. (2) WORKFLOW, hertz: a B→A UDP probe step in the twohost jobs before the ceremony, so this reds in 10 s with its own name instead of 900 s blaming pairing; and retire the dead `_work\spt-core` rules note in the runner runbook. - **Kin:** [[IR-80]] (the other way a half waits 900 s on a partner), [[IR-76]] (golden runner is the operator's box), [[IR-64]] (box-level facts only the operator can move), `twohost-web-helper-stall-shared-a-identity-stale-path` (memory; its CONFIRMED arm is re-read by this entry). - **Ripe when:** now — blocks #272 golden acceptance at `25e60015`. · **Size:** one elevated command + one workflow step. - **SECOND LAYER (measured 23:41–23:50Z, after the operator applied the Windows rule exactly as asked and the re-probe STILL read 0/3):** the tailnet ACL. The same `python.exe` listener (own program rule) received 3/3 from kitsubito over the LAN (`192.168.1.168 → 192.168.1.81:7483`) and 0/3 over Tailscale (`100.98.197.12 → 100.68.35.65`), TCP connect over Tailscale times out too, solicited return over Tailscale works, ShieldsUp false both ends. `tailscale debug netmap` on hfenduleam: one PacketFilter rule, 18 permitted inbound sources, kitsubito ABSENT; kitsubito is `tag:eye-tracking-resource` owned by a different tailnet user, and its own filter DOES permit hfenduleam. Asymmetric policy: member device → tagged resource allowed, reverse denied. The Windows rule was NECESSARY (rule-less exe, LAN probe 0/2 earlier) and NOT SUFFICIENT. Remedy half (1) gains an ACL grant, operator-owned in the admin console: `{"action":"accept","src":["tag:eye-tracking-resource"],"dst":["hfenduleam:7460-7499"],"proto":"udp"}`. Rider 4's failure text names both layers and the LAN-vs-Tailscale probe as the discriminator. Lesson for the entry: a cross-box "unresponsive" has at least THREE layers (Windows rule, tailnet policy, the exe's own bind); probe through the SAME path the rig uses, and re-probe after every single change — the first fix reading as "applied" is not the probe reading 3/3. - **Corroboration + reading traps (deployah 23:50Z, from the box):** Windows rule found present by FILTER search (`netsh advfirewall firewall show rule name=all dir=in verbose`), not by name — the operator's name is hyphenated "two-host" and a `twohost` grep reads it ABSENT. Netmap: the single filter permits ALL ports and ALL protocols from its 18 sources, so the grant is SOURCE-scoped, not port-scoped — "this peer is not a permitted source at all", which is why TCP timed out beside UDP. Two permitted sources (100.98.213.33, 100.98.214.87) share kitsubito's 100.98/16 and read as hits to an eyeball scan for "100.98."; test membership of the full /32, never a prefix. His first netmap read extracted a non-existent field (`SrcIPs`; the real key is `Srcs`), printed an empty list and minted a confident "ABSENT" — an empty extraction cannot witness absence; the 18-count is from the corrected read. Prefs on the box: ShieldsUp false, NoStatefulFiltering true, RouteAll true, NetfilterMode 2 — nothing there explains the drop. - **Probe-rider design rule (hertz, d882297f):** the pre-ceremony probe reds `INBOUND_BLOCKED` for EITHER layer and does not pretend to know which — its job is "the box cannot receive, stop triaging the product"; the layer is named only by the one measurement that decides it (same listener, LAN vs Tailscale), which the failure text prints as a recipe. A guard that names a cause it did not measure is the defect class this whole entry documents. ### IR-NEXT (number at landing; IR-82 is the two-layer inbound block above) — hfenduleam is an OPERATOR DESKTOP, and its background load turns every fixed wall-clock budget in the Windows suite into a coin **Observed (2026-09-08/09, #272 WEBSERVE golden r2 run 34262154550 @ 25e60015, three attempts at ONE sha):** Phase B red each time on a DIFFERENT single cell or none — a1 234/234 (job red on disk floors only), a2 `spt::webserve_attachment_e2e` arm 12 (5 s ttl vs 5 s reaper, cell 11.7 s), a3 `spt-daemon::mesh_recovery roster_route_survives_a_transient_dial_failure_with_discovery_disabled` (15.0 s `converge()` budget, cell 15.715 s; same cell 9.8 s / 7.2 s on a1/a2). Phase A — 3,346 pure-unit cells, spawn-dominated — slowed MONOTONICALLY 448.7 → 495.1 → 542.6 s. Per-cell a3/a2 over 73 Phase B cells ≥ 1 s: median 1.05×, mean 1.34×, 19 cells ≥ 1.5×, worst 5.2× (`endpoint_lifecycle poll_vs_reap` 1.1 → 5.8 s) — BURSTY, not uniform. Product dial path untouched by the milestone. **Box census at the time (doyle 01:13-01:19Z, no cargo/rustc/nextest, CPU 31 %, ~1.1 of 16 cores busy):** `qbittorrent.exe` seeding since 09-08 10:20Z (box tx 21.3 MB/s over 5 s); fleet `spt daemon brain` with 516 GB read since 09-07 08:03Z (~3.5 MB/s steady); Windows Defender real-time ON, `MsMpEng` at 67.8/62.8/48.9/32.2/12.2 % of a core over 5 s on the idle box; a fresh 35 MB exe pays 2092/994/1171/1043 ms on FIRST execution vs 31/263/19/260 ms on the second (already-scanned source 270/38/257 ms) — every CI attempt rebuilds every test binary fresh. Defender exclusion list UNREADABLE unelevated: `Get-MpPreference` returns the literal string `N/A: Must be an administrator to view exclusions` as the ExclusionPath VALUE (so `-contains` reads ABSENT), HKLM `Windows Defender\Exclusions\Paths` → SecurityException. An unreadable row is not an absent one. **Why it is infra, not N flaky tests:** a rotating single victim across attempts at one sha is ONE environment cause; hardening the victims one at a time never closes it (paid before: e2e-leaked-daemons-shared-box). The budgets that lost were ~1.5× the fast observation — inside the box's measured variance, so they were coins that had been landing right. **Remedies (each its own lane):** 1. OPERATOR (elevated, security-posture change on his machine — propose, never apply): read ExclusionPath from an admin shell; if `C:\actions-runner\_work` is absent, `Add-MpPreference -ExclusionPath 'C:\actions-runner\_work'`. Then re-measure the first-touch tax on a file under that path (the scratchpad measurement above is OUTSIDE the runner dir, so it proves the mechanism's size, not the runner's exposure). 2. OPERATOR: a quiet-box request window for golden runs (pause seeding), or accept the coin. Asked 2026-09-09 01:2xZ by deployah for a4. 3. TEST-ONLY (hertz rider 5, ordered 01:20Z): derive every `for _ in 0..600 { sleep 25 ms }` budget (31 sites, 4 files) from the named bound it races, under the 60 s nextest SLOW line; the failure prints elapsed / samples / last predicate state. This is the durable half — a budget derived from its mechanism survives a slower box; a literal does not. 4. CI: print `Get-MpComputerStatus` RealTimeProtectionEnabled + the ExclusionPath read (verbatim, refusal included) in the Windows job's census step, so a run's record says what Defender it ran under. 5. Record-hygiene rider (deployah 01:25Z): a checksum manifest is checkable ONLY from the cwd its paths were generated in (`sha256sum "$D"/*.log` from root vs `sha256sum *.log` inside) — a `-c` from the wrong cwd reports `No such file or directory` on every row, which reads exactly like failed preservation. Generate with a stable base (repo-root-relative) and record the cwd beside the manifest. **Status:** OPEN. Filed from the #272 r2 arc; numbers above are measured, the Defender exposure of the runner dir is NOT (operator read pending).