### IR-45 — twohost rig home premise, SETTLED: pump paths resolve under the per-run TEMP root (rig is disk-hermetic; the "live fleet roster" reading is retired) - **Status:** RETIRED 2026-08-19 — ask answered by the one code read at main @`78a9a16`; residue … - **Residue disposition:** (1) #189's third-node evidence was corrected on the board (comment … ### IR-46 — the Windows disk-floor preflight asserts an INSTANT; workspace free space moves tens of GB inside the hour, so a green floor is not a claim about run headroom - **Status:** open — mechanism CONFIRMED by a measurement series on hfenduleam; doyle ruled it register-shaped 2026-08-18 · **Origin:** deployah, NAMEPLATE #181 golden-head intake, on the run that the floor red-floored · **Filed as IR-46 after an id collision:** this row was authored as IR-42 and held unpushed under the v0.56.0 tag freeze, during which the release-close sweep (`78a9a16`) issued IR-42..45 to other findings. Parallel issuance, not authored disagreement — and noted here so a later reader chasing "IR-42" in this row's history does not hunt for a lost version of it. - **What/why:** `golden.yml`'s Windows preflight computes `$freeBytes` once at job start and hard-fails under a `32GB` floor. As a fast-fail that is correct and it did its job — it refused before compiling rather than dying deep in a link step. The defect is what a PASS is then read to mean. The reading is a point sample of a quantity that moves by tens of GB unattended, so a green preflight licenses a run whose headroom was never measured. Nothing downstream re-checks. - **Evidence — five readings of `C:` free on one box inside roughly one hour, 2026-08-18:** - `03:01:54Z` — `free_bytes=2666205184` (2.48 GiB) against `floor_bytes=34359738368`, the preflight's OWN reading; run `32093894524`, both `n1-gate` and `test` on Windows/hfenduleam failed at this same step, before any compilation. - `~03:2xZ` — ~2.50 GB, independent `Get-PSDrive` read, corroborating the preflight. - pre-reap — **33.70 GB**, immediately before deployah deleted anything. - post-reap-1 — 76.42 GB (42.72 GB reclaimed: `claude_skill_owl/target`, `golden-w1/target`). - pre-reap-2 — **73.81 GB**, i.e. 2.61 GB consumed unattended between the two reaps; then post-reap-2 129.70 GB (55.89 GB reclaimed: `.worktrees/nameplate-w1/target`). - **LABELLED HOLE — do not let this harden:** roughly **31 GB was released between the preflight failure and the pre-reap reading by something OTHER than the reclaim**. Released-by-unknown. The runner cleaning its workspace after the job died is *plausible* and is NOT the recorded cause — it was never measured, and no one looked while it was happening. Recorded as a hole on purpose (doyle's explicit ask at filing): a plausible cause written down as the cause would make this row read as explained when the actual mechanism of the 31 GB is unknown. - **The hazard this leaves:** a run can clear the floor at preflight and starve mid-build, and mid-build disk starvation does not present as disk — it surfaces as a link failure, a truncated artifact, or a rustc ICE, i.e. as a defect in the tree under test. The failure mode inverts the gate's purpose: the preflight's whole point is to keep box conditions from being read as lane reds, and a passing preflight actively argues the opposite. Note the polarity — this row is about the PASS, not the FAIL. The observed red was honest. - **#242/v0.66.0 GOLDEN ADDITIONS (deployah measured 2026-08-29, banked at the 08-30 close sweep):** (i) per-job floor figures are SEPARATE INSTANTS — quote per job, never one figure for both (attempt 1: `test` 26521477120 vs `n1-gate` 26535051264 free bytes, 8s apart, one run); (ii) **CORRECTED TRAP** (retracting deployah's earlier "attempt-2 hides jobs" version): the default `/runs//jobs` endpoint stamps `run_attempt=` on EVERY job including ones that never re-ran (4 of 8 mis-assigned on this run) — it is the RUN's attempt, not the JOB's, so a stale green can read as re-earned; `started_at` is the discriminator and `/runs//attempts/N/jobs` the authority. Also `rerun --failed` re-runs DEPENDENT jobs (twohost re-ran despite a green attempt 1); (iii) a rerun preflight reads RAW free BYTES with the CI step's own predicate, not display GB; (iv) a rerun green counts as floor-RCA-closing evidence only after a step-level NON-VACUOUS check (checkout SUCCESS + workload steps ran) — the v0.64.0 checkout-SKIPPED shape means a green job can carry zero code signal. - **Ripe when:** next `golden.yml` touch. Remedies to weigh THEN, not as a drive-by: re-assert the floor at job END (turns a starvation into a labelled disk verdict instead of a fake lane red); or raise the floor to cover a full build's peak rather than its entry condition; or sample free space across the run and emit the minimum as a token. All three cost run time; none is obvious. - **Size:** small in `golden.yml`, load-bearing in what a green run is taken to prove. - **Kin:** [[IR-41]] and [[IR-40]] (a state that reads as a clean verdict unless it is labelled — here a PASS that is read as headroom it never measured), [[measure-the-box-before-the-instrument]], [[cancelled-measurement-leaves-labelled-hole]]. - **2026-09-06 addendum (doyle, v0.67.1 close sweep): trigger FIRED at `04e32c8c` — `golden.yml` touched (2-line HEAVY reclass of `brain_resume_conn_deadlock` on the respin) with no remedy weighed. Not a drive-by by choice: the touch rode a respin under a pre-registered hard stop, which is no remedy window. COMPOSED with IR-59 (log-the-floor) + IR-73 (literal-first sites) as one hertz workflow rider on WEBSERVE #272; the remedy weighing happens on THAT lane, before the WEBSERVE golden head.** - **2026-09-06 remedy ruling (doyle, WEBSERVE rider):** retain 32 GiB; record raw-byte `FLOOR_START` and `FLOOR_END` PASS/RED tokens per job/runner, each labelled `sample=INSTANT`. End DISK assertions run `if: always()` before teardown, including after failed workloads. A fresh `FLOOR_DOCS` assertion immediately before docs-drift composes with IR-73's second half. Raising the floor is refused without a measured peak; continuous sampling adds lifecycle machinery while remaining blind between samples. Start/end are a dataset, not a minimum or headroom guarantee. Golden execution evidence waits for the WEBSERVE golden head; the thin PR must first show actual START/END output on its own green CI run. ### IR-47 — ci-notify treats a missing co-author trailer as a quiet info line; silent attribution loss reads as "there was none" - **Status:** open — patch AUTHORED and stashed unlanded since 2026-07-29 (`.worktrees/_patches/ci-notify-missing-trailer.patch` + its `test-ci-notify.sh` harness in the sibling `.untracked` dir); surfaced by doyle's 2026-08-19 idle-queue verification of that stash · **Origin:** the AGENTS.md trailer mandate's own hazard family (the space-spelling trailer is structurally invisible to git's tokenizer, so confident zeros already read as attribution loss once); this row is the NOTIFY-side twin. - **What/why:** `.github/ci/ci-notify.sh` parses the head commit for the line-anchored `Co-authored by: ` trailer to add a second notification recipient. When the trailer is absent or unparseable, the current script emits one stdout info line ("doyle only") and moves on — correct as a non-fatal outcome, wrong as a SILENT one: a lane that lost its attribution (typo'd trailer, squash that dropped the body, hyphenated spelling) notifies doyle alone on every run and nothing anywhere says an agent stopped being told about their own lane's verdicts. The stashed patch keeps absence non-fatal but promotes it to a `::warning` workflow annotation (visible on the run summary), and splits the legitimate quiet case (co-author IS doyle) from the loss case so the two stop sharing one message. - **Evidence:** patch verified 2026-08-19 to still NOT be on main — the warning string is absent from `.github/ci/ci-notify.sh` at the current tree. Patch content re-read at verification; it applies against the script's post-`SEND_BOUND_SECS` shape. - **Ripe when:** next `golden.yml`/ci-notify touch — natural co-rider with [[IR-46]]'s remedy window (same file family, same "weigh then, not drive-by" rule). The stashed test harness rides with it. - **Size:** ~10 lines in one shell script plus its test. - **Kin:** [[IR-40]] (an unlabelled state read as a clean verdict — here a quiet info line read as "no co-author existed"), the AGENTS.md `%(trailers:)` tokenizer mandate (the sibling silent-zero on the AUDIT side). ### IR-48 — the nextest.toml parity cell tolerates CRLF only by parser accident; a newline-sensitive arm added later reds fresh Windows checkouts alone - **Status:** open — filed 2026-08-19 (doyle route, hertz verdict: REGISTER as preventive hardening, not current defect) · **Origin:** sibling sweep after the W3 gate CRLF finding — parent mechanism: `include_str!` embeds working-tree bytes verbatim, `core.autocrlf=true` smudges fresh checkouts CRLF, and the author's never-re-smudged tree stays LF — builder green, every fresh rig/golden checkout red. - **What/why:** `crates/xtask/src/main.rs` `the_checked_in_config_is_in_parity` include_str!s `.config/nextest.toml` and feeds `phase_a_overrides_missing_from_ci_windows`. TODAY this is causally CRLF-tolerant — the parser is `str::lines()`+trim (`override_filters`, main.rs:434-440), and the 52/52 fresh-rig green at the hygiene gate (2026-08-19, this box) is therefore causal, not luck. The hazard is the MISSING CONTROL: nothing pins the tolerance, so a future newline-sensitive arm in the parity predicate reds only on fresh Windows checkouts — the builder-green/rig-red inversion, deterministic but reading as flake. - **Remedy (hertz's, platform-independent):** feed the parity predicate an LF fixture AND the same fixture converted to CRLF, assert identical missing-sets (including one unmirrored negative), so a newline-sensitive arm reds on EVERY host rather than only fresh Windows checkouts. - **Ripe when:** next xtask parity-cell touch; explicitly OUTSIDE the family-B lane (hertz scoping). **Size:** one fixture-pair cell. - **Kin:** the W3 gate finding this swept out of (skeleton cells, fixed at the fixture edge in lane commit e99633f); [[IR-40]] (an untested tolerance read as a guarantee). ### IR-49 — poolguard's landed-lane predicate is ancestry-only, so a cherry-picked member lane can never read Settled and its pool can never be taken over - **Status:** open — filed 2026-08-19 (todlando measurement at the keystone-w1/fix-197 reap, doyle ruling; doyle re-verified the predicate at source before filing) · **Origin:** todlando's post-landing landed-check used the guard's own predicate and it contradicted the (correct) landed fact — the checker was wrong with the guard, which is exactly how the guard will be wrong alone. - **What/why:** `git_lane_state`'s final arm answers Settled/InFlight purely by `merge-base --is-ancestor ` (`crates/spt-poolguard/src/lib.rs:424-436`, probe at `:474-479`). Under ADR-0050 golden CI (thin member lanes cherry-picked onto a stage branch, ff-only main) a MEMBER lane's own branch tip never becomes an ancestor of main. Measured at origin/main `9ea595c`: `build/keystone-182-w2-sealed-multi` @`ba2d998` and `fix/197-absent-code-uncounted` @`5eb6a3b` both read NOT-ancestor while `git cherry -v` reports every lane commit `-` (already upstream). So `LaneState::Settled` is unreachable for any cherry-pick-assembled member lane whose branch still exists, the takeover arm can never fire, and the pool refuses forever — including with a dead holder. That contradicts the AGENTS.md mandate ("a merged branch is taken over") because the guard's notion of merged is ancestry-only and the golden model structurally never produces ancestry for member branches. The branch-vanished (`:391`) and re-pointed (`:399`) arms still fire, and the STAGE lane works (its tip IS an ancestor) — the hole is landed-member-branch- still-exists only. It did not bite at the 2026-08-19 reaps solely because deleting a pool deletes its claim; it bites the first time someone wants to TAKE OVER a landed lane's pool rather than reap it. - **Remedy (todlando's candidate, doyle-endorsed direction):** when ancestry answers false, fall back to patch-id containment (`git cherry` / `rev-list --cherry-mark` against the claimed base) before concluding InFlight. **Known residual to state in the fix's docs/tests:** a conflict-adjusted pick changes the patch-id, so such a lane still reads InFlight; its release path is branch deletion (the vanished arm), which is at least reachable. Tests want a cherry-picked-landed fixture plus a conflict-adjusted negative. - **Ripe when:** next poolguard touch, or the first landed-lane pool takeover request. - **Size:** one fallback arm in `git_lane_state` + two fixtures. - **Kin:** [[IR-26]] (dead-holder takeover AUTHORIZED when it shouldn't be — this is the mirror: takeover UNREACHABLE when it should fire), [[IR-42]] (claim writes, build enforces), the AGENTS.md pool mandate this contradicts. ### IR-50 — e2e failure panels read the PRE-REDIRECT stderr capture; every daemon-side diagnostic lands in a sink the rig deletes unread - **Status:** CLOSED — BUILT 2026-08-19; adoption-completion lane `docs/ir50-register-close` @`e02f565f` (hertz, doyle-gated 2026-08-20) LANDED in v0.59.0 as a PORTER rider (pick `e702d4b7` tip, main @`c62904e7`; register sweep 2026-08-21) — lane `fix/ir50-stderr-sink-census` @`1a2f6a2`+`2ac9543` (hertz; base `0c86b2d`; rides the CONCIERGE #183 chain; these shas are the 2026-08-19 message-only reword of `cb4cd9d`+`7336e03` — trees proved identical by tree-id, so every measurement below carries): exported `spt_daemon::stderrlog::sink_path(home)` with `stderr_log_path` routed through it + equality unit; `daemon_stderr_panel` in tests/common renders BOTH channels and labels a read failure with channel + exact looked-at path + OS error (absent-sink regression pins it — the IR-40 unlabelled-absence class was caught at gate and fixed in `2ac9543`); censused every daemon-run captured-stderr panel outside `engine_room_bringup_e2e` (rides #199 lane) and `er_briefing_*` (rides #164 lane); engineroom.rs:145 misnomer rider landed in the same lane. Gate figure 781/781 at `2ac9543` (measured at the pre-reword tree, which is byte-identical; first-report 765 was transcription, corrected with raw line + JSON provenance). CLASS FOLD (doyle ruling, no fresh row): `er_briefing_presented_e2e` hit this exact class during its own authoring (blank panels on a real loud line) and was fixed locally in `72efb6a` reading both channels. **REGISTER CLOSED 2026-08-19:** branch `docs/ir50-register-close` links the golden-tested implementation at `4661bc9d` and completes helper adoption in the five measured residual files: `er_brief_once_per_session_e2e.rs`, `er_briefing_presented_e2e.rs`, `er_sequestered_cwd_e2e.rs`, `endpoint_autostart_e2e.rs`, and `n1_pairing.rs`. `engine_room_bringup_e2e` remains the explicit exclusion, recorded as todlando's direct sink-path read from the #199 lane. · **Originally filed:** 2026-08-19 (todlando RCA inside the #199 investigation; the immediate four-panel fix in `engine_room_bringup_e2e.rs` is his and rides the #199 lane — THIS entry is the class census, hertz-class) · **Origin:** the #199 evidence void — 40 rca-v2 runs held zero daemon-side evidence for either erhost face; `ENGINE_ROOM_SPAWN_FAIL` (broker.rs:5658) was written to a log the rig destroyed at teardown. Absence discipline honoured: the SUCCESS-path line (`ENGINE_ROOM_BROUGHT_UP`) was also absent from all 40, proving the channel dead rather than the event absent. - **What/why:** product `stderrlog::install` (broker at cli.rs:7633, brain at brainproc.rs:200) repoints the process STD_ERROR_HANDLE within its first statements (`redirect_stderr_to`, stderrlog.rs:101 — Windows `SetStdHandle` + `mem::forget`), so a rig's `.stderr(File)` capture holds only the pre-redirect window; from that line on every diagnostic lands in `SPT_HOME/logs/daemon.stderr.log` (stderrlog.rs:34/42) inside the rig's temp home, destroyed unread at teardown. Panels are also mislabelled ("brain stderr" holding the broker's first lines). REQ-DAEMON-STDERR-PERSIST fixed this blindness PRODUCT-side ("the incident-night RCA-blind gap", cli.rs:7626-7631); no rig was ever taught to read the sink, so the fix does not reach any harness. Class: every e2e rig that spawns `spt daemon run` and prints a captured-stderr panel has the same void. - **Remedy:** census all such rigs; failure panels additionally dump `SPT_HOME/logs/daemon.stderr.log` with the path read FROM `spt_daemon::stderrlog` (never re-spelled), and the labels corrected ("broker stderr (pre-redirect)" / "daemon stderr sink"). `engine_room_bringup_e2e.rs`'s panel sites land in the #199 lane (todlando, scoped there — measured shape: FIVE producers incl. the :167 precondition panic, SEVEN print sites, seven relabels; the early "four" was an estimate the file refuted). ⚠ Rigs can only import `STDERR_LOG_BASENAME`; the `"logs"` dir segment has no exported const, so every rig re-spells it — the census lane should add an exported path helper (e.g. `stderrlog::sink_path(home)`) to spt-daemon FIRST, then consume it everywhere. The census and remainder are hertz-class. - **Ripe when:** hertz's queue after current items, or the next e2e red printing an empty stderr panel. - **Size:** census + mechanical panel edits per rig. - **Kin:** [[IR-40]] (an absent signal read as a clean verdict), REQ-DAEMON-STDERR-PERSIST (the product half of the same incident), [[IR-8]] (a censused zero that cannot see its blind spot). ### IR-51 — engine-room e2e daemon runs NET-ENABLED on real interfaces; rig hermeticity is disk-deep only - **Status:** open — filed 2026-08-19 (todlando's x40 run-4 sink read, the first live read any rig has had of the daemon sink; doyle ruled own-id rather than riding #199, at the finder's own request) · **Origin:** unasked-for find inside the #199 instrument's first catch. - **What/why:** the rig's temp `SPT_HOME` buys DISK hermeticity ([[IR-45]]'s settlement — which explicitly covered paths, not network) but nothing turns the net off: the run-4 sink shows the rig's own daemon with `BRAIN_NET_CONSUMERS_UP` (dispatcher + peer pump started), three `NET_FAMILY_GATE: binding IPv4-only`, and three `PAIR_MEET_UP:erhome` carrying the box's REAL Tailscale (100.68.35.65) and LAN (192.168.1.81) addresses — live peer work during an e2e — plus an `INBOUND_REACHABILITY` warning whose firewall rule admits the CI-runner's binary path (`C:\actions-runner\_work\spt-bs-core\spt-bs-core\target\debug\spt.exe`) while this daemon ran from a dev tree. Consequences: test behavior conditioned on shared-box network state; rate-shaped flakes; e2e runs radiating real traffic. SAME SINK, RECORDED NOT DIAGNOSED: conn churn at ~150 ms cadence (327 write-start / 324 transport-close, conn ids past 300 in 58 s) — unattributed. ⚠ CANDIDATE INTERACTION, explicitly NOT established (finder's own framing honoured): the run-4 face (30 s bound blown, zero session events in the window, launch Ok, no error anywhere) matches the SHAPE of the filed offline-but-resolvable-peer pump-stall mechanism (dial does not fast-fail). Discrimination open; nothing here is a #199 attribution. - **Remedy:** a rig-honoured net-off switch (peer pump + discovery disabled under test unless the test is ABOUT them) or loopback-only binding; census which e2e rigs start net consumers. Sequencing rule: do NOT fix hermeticity into #199's face before the face is attributed — a green bought by turning the net off would bury the mechanism unread. - **Ripe when:** #199 attribution answers whether net state is causal; else the next hermeticity pass. - **Size:** product switch + rig adoption + census. - **Kin:** [[IR-45]] (the disk half), the subnet-pump dial-does-not-fast-fail mechanism (filed, pump-stall RCA), [[IR-38]] (a live daemon's side effects outliving the test's intent), releases#125 gc-spin (a conn-churn shape candidate). ### IR-53 — failed-address expiry unit panics during the first 10m01s after Windows boot - **Status:** BUILT 2026-08-21 on `fix/ir53-cold-boot-instant` — LANDED in v0.59.0 (PORTER rider, pick `7b26f28d` on `assembly/porter-205`, main @`c62904e7`; register sweep 2026-08-21 at release close) · **Origin:** todlando, found and falsifiably measured mid-releases#204; this rider fixes the latent CI-pipeline flake before PORTER golden. - **Measured:** `failedaddr::tests::an_expired_record_stops_matching_and_is_swept` ages an `Instant` with `Instant::now().checked_sub(FAILED_ADDR_TTL + 1s).expect(...)`, where `FAILED_ADDR_TTL = 600s`. Windows `Instant` counts from boot, so a host younger than 601s cannot represent the requested stamp and panics `monotonic clock older than the TTL`. Todlando predicted and observed the red before the threshold, then observed the identical tree green after it; two subsequent daemon sweeps held 860/860. - **Remedy:** when the monotonic clock cannot represent the age, return through the loud `SKIP_FAILED_ADDR_EXPIRED_SWEEP` arm naming the exact unproved property. On every warm host the original direct aging and both expiry assertions still run unchanged; there is no ten-minute sleep and no silent pass on the cold arm. - **Class census (untruncated):** four test-side `Instant::now().checked_sub(...TTL/deadline...).expect(...)` patterns total. This cell is the sole 601s member. Three siblings remain recorded, not changed in this rider: `broker.rs:8432-8434` and `broker.rs:9198-9200` age `CONTROLLER_WRITE_DEADLINE + 1s` (6s), while `broker.rs:10385-10388` ages `BRAIN_WRITE_DEADLINE + 1s` (16s). Their much narrower cold-boot windows are the same mechanism class and should use a controlled clock seam when next touched. - **Kin:** releases#204 (finder lane), [[IR-25]] (daemon-lib flake population), and [[IR-40]] (a confident verdict without the evidence needed to make it). ### IR-52 — docs-site CLI reference renders SHALLOW; help text below the rendered depth is outside the drift gate, unit-held per-REQ or held by nothing - **THIRD INSTANCE, observed 2026-08-24 (todlando, WAX-SEAL #21 W4; not acted on):** the new `spt api seal verify|describe` FLAGS sit below the generator's rendered depth — the entry's exact class. The W4 user page hand-documents them, which is per-page self-defense, not a gate. Conditional-rider condition did NOT fire at W4 (no generator touch); the entry's own trigger stands for whichever lane next touches the generator. - **Status:** BUILT 2026-08-24 on SIGNET #218 W1 T6 (todlando; doyle's intake made it the wave's rider when the new `seal enroll-authenticator` verb forced the generator touch that armed the trigger): `xtask` reference-gen now DESCENDS THE FULL COMMAND TREE recursively (the durable remedy), regen published the 22 previously-unrendered leaves + the new section, and a depth regression is a drift RED by construction. Self-holding units censused per the remedy: the SURFACE-SECTION-SITED walk and both MONIC-TRIGGER-SECTION sited-help units are now DOUBLE-held (published surface under the drift gate + content pins kept) — kept, not retired. · **Origin:** todlando's #160 build report, fact flagged for the gate rather than folded silently. (Pre-build status: open, filed 2026-08-19 — doyle, W3 #160 gate prep; second measured instance of a class REQ-CLI-SURFACE-SECTION-SITED's own title already named for its sites.) - **What/why:** the generated `docs-site/src/cli/reference.md` renders `spt endpoint monic` but does not descend to `monic add` / `monic update`, so the #160 strike of the maintained kind enumeration at those two flag docs never appeared in the published reference and the docs-drift gate CANNOT see the strike — the REQ-CLI-MONIC-TRIGGER-SECTION rendered-help unit is the only hold. General mechanism: any help text below the generator's descent depth is invisible to the drift gate; a deep help edit (or regression) ships unpublished and ungated unless some REQ's unit happens to pin it. First measured instance: REQ-CLI-SURFACE-SECTION-SITED names "the three-deep sites the docs-site drift gate cannot reach" and closes them with its own pinned walk — per-REQ self-defense, not a gate. Consequence beyond drift: adapter builders build BLIND from the public docs (DRI protocol), so a deep-help divergence hands every adapter a thinner contract than the operator's terminal shows. - **Remedy:** either xtask reference-gen descends the full command tree (deep help becomes published surface the drift gate already covers), or a generic rendered-help walk over all sites at all depths joins the drift gate; census which REQ units currently self-hold deep sites (known: SURFACE-SECTION-SITED walk, MONIC-TRIGGER-SECTION sited-help unit). - **Ripe when:** next xtask docs-gen touch, or the first adapter filing traceable to a deep-help divergence. - **Size:** xtask render change + regen + census of self-holding units. - **Kin:** the REQ-CLI-SURFACE-SECTION-SITED pinned walk (the per-REQ closure shape this entry generalizes), [[IR-47]] only if its golden.yml/ci-notify surface rides the same docs-gate window. ### CI-RIDER LANE STATE — LANDED 2026-08-04 (post-v0.53.0 merge queue); history below kept for its mechanisms - **RESOLVED:** the lane rebased clean onto the post-tag queue and landed ff-only as `2b33a47`/`2a7b016`/`d63f4ce`/`19d7f79` (content byte-identical to `1275e47..bf8c4a2` by lane-diff blob hash). IR-1 and IR-4 are BUILT AND LANDED; IR-9's measurement half is landed with its trigger now armed — the toolchain print reports runner-account versions on the NEXT GOLDEN RUN, which is when doyle's 2026-08-03 ruling (decide from runner-account versions, never the interactive prior) becomes executable. The two golden-only steps (link probe both boxes, toolchain print both legs) remain unexercised until that run — the landing does not change that caveat. - **As recorded pre-landing (2026-08-04, doyle):** `ci/locksmith-riders` was at `bf8c4a2` with FOUR commits not contained in `origin/main` and not present in LOCKSMITH's golden head `b7b00c3`. The worktree `.worktrees/hertz-ci-riders` was clean, so the work existed and was simply unlanded: `1275e47` (xtask: assert a load-bearing patch pin is still in force, both ways it lapses) · `49d4805` (docs/ci: a lock-touching lane reads edges, not just the package set) · `8ed006b` (ci/golden: print the toolchain that judged the run, both legs) · `bf8c4a2` (ci/golden: measure the link before rendezvous, read the floor after the checkout that clears it — the floor read AFTER its own reclaim is [[ci-runner-has-no-warm-target]]'s shape). - **Why it is recorded rather than quietly re-dispatched:** [[IR-1]]/[[IR-4]]/[[IR-9]] were carried as DISPATCHED, which is now false in BOTH directions — the work is further along than dispatched, and it also did not ship. The cause was the same agent outage that cost `#123` its build, and the operator's standing rule from that drop applies here too: an outage must not be able to remove work from a batch silently. Board requests got a drop comment; register entries get this. - **MAPPING CONFIRMED BY ITS BUILDER 2026-08-04, by REQ id rather than by recollection** — hertz noted first that its own context had been cleared between building the lane and answering, and declined to testify from memory about the original instrument. Everything here is either measured that day or read off the commits: `1275e47` → `REQ-CI-LOAD-BEARING-PATCH-PIN` ([[IR-4]] part 1, the mechanical pin guard in xtask) · `49d4805` → `REQ-LOCK-TOUCHING-LANE-PROCEDURE` ([[IR-4]] part 2, procedure in docs/GOLDEN-CI.md) · `8ed006b` → `REQ-CI-TOOLCHAIN-VERSION-PRINT` ([[IR-4]] part 3, carrying [[IR-9]]) · `bf8c4a2` → `REQ-CI-LINK-HEALTH-PROBE` ([[IR-1]], the network axis). - **CORRECTION TO THE GATER'S EARLIER WORDING, from the builder:** `8ed006b` does NOT discharge [[IR-9]] — it discharges IR-9's MEASUREMENT half only. IR-9's other half (align the two boxes, or declare one authoritative clippy leg) is held by doyle's own 2026-08-03 ruling: decide once the step reports RUNNER-ACCOUNT versions, never on the interactive-account prior. IR-9 therefore stays OPEN with its trigger now REACHABLE, which is a different state from "waiting". - **Gate evidence, instrument NAMED:** `cargo nextest run -p xtask` in `.worktrees/hertz-ci-riders` on hfenduleam, box quiet with no runs in flight — 34 run, 34 passed, 0 skipped. Nextest rather than bare `cargo test`, per [[IR-25]]. ⚠ **What that does NOT cover, stated by the builder rather than discovered later:** the two golden steps the lane ADDS (link probe on both boxes, toolchain print on both legs) cannot be exercised outside a golden run. The probe's three arms (five-sample success, no-reply, absent-CLI) were exercised on the real boxes at commit time, and that is reported as a CLAIM RECORDED AT COMMIT TIME, not as a re-verification — the kitsubito arm could not be re-checked from here. This is why the lane wants a golden rather than a quiet ff. - **[[IR-5]]/[[IR-6]] CONDITIONAL RIDERS: CONDITION NOT MET — the answer is NO and it closes the question for this lane.** Measured file set `6d291e0..bf8c4a2`: `.gitattributes`, `.github/bench/link-probe.ps1`, `.github/bench/link-probe.sh`, `.github/workflows/golden.yml`, `crates/xtask/src/main.rs`, `crates/xtask/tests/bench_row_parity.rs`, `docs/GOLDEN-CI.md`, `traceable-reqs.toml`. Nothing under `.github/ci/`, where the nextest-summary readers and count-reporting scripts live. IR-5: no consumer of nextest output touched. IR-6: no EXISTING gate output changed — though the NEW output was voluntarily written to IR-6's rule (the LINK line prints `samples=N/M` and the individual rtts, membership beside the count, in both shells). That SHRINKS IR-6's future scope by two lines; it does not discharge it. - **Three mechanisms lifted from this lane's REQ titles, worth more than the lane:** (a) **An instrument must not be able to RED the run, and each shell breaks that differently** — bash: `| head` under `pipefail` SIGPIPEs the producer to 141, so a print step reds (trim with parameter expansion instead); pwsh under GitHub's wrapper: a MISSING COMMAND is a terminating error, so rustup's absence must be TESTED with `Get-Command`, never caught. One requirement, two constructions, and neither is portable reasoning about the other. (b) **A negative-control mutation must be COUNTED before it is trusted** — the absent-CLI arm was first "measured" against a tree where the mutation had not taken, silently re-measuring the unmutated arm and reading as a pass. (c) **Jitter, not the median, is the signal on a link that mostly works** — the motivating red's link ran 10..83ms and 3..75ms while IDLE, so a median-only probe reads healthy straight through the failure. Both med and max rows ride the ledger. - **Disposition:** composes onto the next golden batch as a thin lane, NOT slipped onto main. It changes the golden pipeline itself, so it wants a golden rather than a quiet ff — and while v0.53.0 is untagged, any push to `main` moves the runbook's bare `git tag` off the tested sha. ### IR-55 — the `spt --bins` suite wedges partway through on leaked `findstr .` PTY children; the tests at the frontier are casualties, not culprits - **Status:** OPEN, **ARMED-FOR-CAPTURE**, owned by **hertz**. Test/rig defect by the dispatch split (test/CI rework is never the product builder's). Filed by doyle 2026-08-22 from the TURNKEY #212 W3 gate on releases#213. - **CORRECTED BY REPLACEMENT the same day.** This entry first named `cli::tests::adapter_profile_verbs_local_only` as the wedging test, because that is where the streamed frontier stopped. **That was wrong, and the correction is the useful part of the entry:** run in isolation, on the same pool and binary and with the same env, that test passes in **0.02s**. So do the other two the suite later stalled on — `cli::tests::shell_channels_relay_sensory_and_text_file` (0.20s) and `cli::tests::resolve_proof_target_override_reads_on_disk` (0.00s), each 1 passed / 652 filtered. **A frontier names where progress STOPPED, not what CAUSED it.** Naming the last test printed is the same error shape as reading a stack frame as a root cause, and it would have sent hertz to rewrite three innocent tests. - **What is actually measured:** - `cargo test -p spt --bins` unfiltered sat **24 minutes** at 13.5s CPU — blocked, not spinning. - Re-run with `--test-threads=1` and streaming output: stalled after **183** completed. - Re-run again with that frontier test skipped: progressed to **335** completed, then stalled with **two** tests simultaneously past libtest's 60-second notice. Skipping one casualty simply moves the frontier, which is itself evidence the fault is not in any one test. - Every wedged harness carried `findstr.exe .` children under `conhost.exe --headless`. **`findstr` with no file argument reads STDIN and blocks forever.** - The frontier tests are **byte-identical at `c62904e7` and at the #213 tip `3d69f77c`** (function bodies hashed at both blobs), so nothing in that lane introduced this. - **Reading, stated as a reading rather than a conclusion:** an EARLIER test spawns the `findstr` stand-in as a PTY child and does not reap it; the children accumulate across the run and a later test blocks behind them. Which test leaks is NOT yet identified and this entry does not guess — the next step is to bisect for the leaker rather than to touch any test at the frontier. Five orphaned `findstr` processes with creation times spread across the day were observed on this box independently of any single run, which is consistent with accumulation across many suite runs. - **Hypothesis RAISED AND NOT SUPPORTED, recorded so nobody re-runs it:** the gate scrubs `OWL_SESSION_ID` / `SPT_AGENT_ID` / `SPT_ENDPOINT_ID`, and a scrubbed identity was suspected of routing a normally-REFUSED test down a live PTY path. The isolation runs above were performed **with the scrub applied** and passed, so the scrub alone does not produce the hang. It remains unexplained why the same unfiltered command completed at 652 passed / 1 failed for another agent on the same tree; do not treat the scrub as the differentiator without a fresh one-variable run. - **Why it is register-grade:** golden CI runs the `spt` package. A test that never returns cannot red — it consumes the single self-hosted runner slot until the job timeout, which `golden.yml`'s 50-minute cap bounds rather than fixes. A wedge that fires only sometimes is worse than a red, because the suite's green record stays intact and nobody audits it — the same self-concealing shape as `exit-code-after-a-pipe-is-the-tails`. - **Trigger condition (ripe):** any milestone whose gate wants an unfiltered `spt --bins` sweep, which is every one of them. Ripe now. - **REMEDY, MEASURED 2026-08-22 and it changes this entry's urgency:** the same 653 tests under `cargo nextest run -p spt --bins --no-fail-fast` complete in **22.2 seconds, 653 passed, 0 skipped, exit 0** — no slow markers, no timeouts — on the very tree and pool where `cargo test -p spt --bins` wedged indefinitely twice. **nextest runs each test in its OWN process**, so a leaked `findstr` child can block only itself. This is the discriminating measurement rather than a workaround reached for to get a green: **the suite is not broken; the SINGLE-PROCESS harness is what lets one test's leaked child wedge every test after it.** Golden CI already runs nextest, which is the likely reason this has never surfaced there — the exposure is to anyone running bare `cargo test` on the `spt` package, which is every local gate. - **Count reconciliation, recorded so the figures are not read as a discrepancy:** runs of this suite report 652 passed / 1 failed where the one failure is `cli::tests::adapter_translate_proof_gates_on_commit` — the `--bins`-only artifact, which refuses because `translate_proof_fixture.exe` is not built under a bins-only invocation and says so in its own message. Prebuilding it (`cargo build -p spt --bin translate_proof_fixture`) makes it pass: 652 + 1 = 653. Prebuild the fixture rather than carrying a known-red through every gate. - **⚠ AMENDED 2026-08-22 — DO NOT PREBUILD FROM THIS BULLET'S EXAMPLE.** The line above names ONE fixture because one fixture is what *this* wedge needed; read as the prebuild recipe it covers a fraction of the population, and it was read that way twice on one day. **The census already exists in IR-21 above** (`adapters/mock`: mock-session, mock-shell, capture-player, console-mode-probe · `crates/spt-daemon`: dispatch_fixture, service_fixture, summarizer_fixture · `crates/spt`: translate_proof_fixture, post_step_fixture, gh_fixture, git_fixture), together with the split that matters: **cross-package sites are the hazard members; same-package builds are guaranteed by construction.** Field instances, both 2026-08-22 TURNKEY #212 W4: todlando's lane red on three `spt-daemon::attach_resize_capture` cells wanting `adapters/mock`'s **capture-player** (a cross-package member), and doyle's head gate prebuilding the remembered pair while never running a `spt-daemon` or `spt-term` suite at all. **Prebuild `--workspace --bins`, or read the `build_hint` the helper already composes** (`crates/spt-term/tests/support/fixture_bin.rs:42`) — five test files gate on that panic. Neither of us lacked the census; we prebuilt from memory while our own register held the list. - **FIXTURE PREBUILD, RECURRENCE 2026-08-29 (todlando, emission lane):** the rule was already banked AND I am one of its authors, and I still ate three fixture reds in a row — mock-session, then capture-player, then mock-shell — each tripping in about 0.01s with a panic that reads exactly like a test failure. Having the rule is not the same as applying it completely: I prebuilt from RECALL (`-p spt --bins`) rather than from the rule's stronger banked form, and the tell is that my fix arrived in three instalments instead of once. **TWO FACES, both structural rather than careless.** (1) THE FIXTURE MAY LIVE IN ANOTHER PACKAGE — mock-session, capture-player, mock-shell and console-mode-probe are all `adapters/mock` (`-p mock-adapter`), so no amount of `-p spt --bins` ever produces them. (2) ENUMERATING FIXTURES BY GREPPING THEIR PRE-BUILD STRINGS IS STRUCTURALLY INCOMPLETE — it finds the call sites that embed a literal `pre-build: cargo build ...` string and CANNOT find mock-shell, whose helper composes the command at runtime (`sibling_bin(name)` → `fixture_package(name)`), so there is no literal to match. A predicate over source text cannot see a string the program builds at runtime; same blindness class as the emission census's TOKEN-colon-vs-TOKEN-space predicate, met twice in one session. **CLASS FIX:** never hand-list fixtures — build the whole fixture package (`cargo build -p mock-adapter --bins`) or `--workspace --bins` before any `--test`/`--bins`/filtered leg. Chasing named fixtures one red at a time only ever finds them one at a time, and each one costs a full battery run. - **Named negative + settle-class result (hertz, 2026-08-23):** current main at `4dd699cb7867979ca0497e7c74d8d0aaf881e9e9` did not reproduce the wedge on HFENDULEAM from isolated checkout `.worktrees/ir55-findstr-bisect`. Test binaries were freshly built before the diagnostic population and reused for the settle sweep; the gate environment scrub was **not** applied; the installed daemon was live. The fleet snapshot taken immediately **after**, not during, the sweep showed BIGNET 7 nodes / 20 endpoints, SPT_MANTLE 3 / 19, SPT_DEV 2 / 19, 3-of-7 peers connected, `degraded-partial`. Four startup cells that spawn `findstr` passed alone and reaped their observed ConPTY children; a full single-threaded run passed 663/663 with a before/after census delta of `IR55_NEW=0`. The ratified settle-class sweep then ran five consecutive bare `cargo test -p spt --bins` invocations: all 663/663 green in 420.35s total, with zero `findstr.exe` residents before and after. This is a named negative data point, not a discharge of the intermittent filing-day measurements. - **Next-wedge capture protocol — do not improvise or clean first:** preserve the exact bare invocation and snapshot the environment (box, checkout SHA/worktree, fresh-versus-reused test binary provenance, gate-scrub state, live-daemon state, and fleet roster); stream test output to durable storage so the last started and completed test names identify the frontier; census `Win32_Process` immediately before the run and again while wedged, recording each `findstr.exe` PID, parent PID, creation time, executable path, and command line. **Do not kill any child before the second census is banked.** The 22 residents found during the 2026-08-23 investigation were path-verified as `C:\Windows\System32\findstr.exe`, shown to predate its live runs, banked, then reaped; the pre-sweep and post-sweep resident counts were both zero. - **Size guess:** small if one test is missing a reap or an EOF for its stand-in child; medium if the shared PTY test scaffolding needs the reap, in which case every sibling spawning the same stand-in wants it. The RUN-LEVEL exposure has an answer today (nextest); the LEAK itself is still worth fixing, because a leaked child per run accumulates on any box that runs the suite. - **Gater's craft, worth more than the entry itself:** (a) The first wedge was undiagnosable because the gate script wrote every leg as `cargo test … | tail -N > file` — nothing reaches disk until the command completes, so a wedged leg produces an **empty file** and the process table is the only witness. **Stream to a file and tail the FILE.** (b) To NAME a frontier, run `--test-threads=1`: libtest prints each test's name BEFORE running it, so the last incomplete line is where progress stopped. (c) **Then prove the frontier test is actually at fault by running it alone** — which is the step this entry originally skipped, and the one that turned a wrong entry into a right one. ### IR-56 — `pool-claim` harvests lane identity from CWD, not from `--pool`; a claim run from the wrong tree writes a WRONG RECORD with a success message - **Status:** BUILT 2026-08-24 for the SIGNET #218 golden batch on `fix/ir56-pool-claim-cwd`, owned by **hertz**. Tooling/rig defect by the dispatch split. Filed by doyle 2026-08-22 from todlando's TURNKEY #212 W4 Lane 1 field instance — the first confirmation of the IR-42 mechanism from a LANE rather than from a source read. - **What happens:** `cargo run -p xtask -- pool-claim --pool --label ` records the lane identity it harvests from the **current working directory** — `owner_tree`, `lane_branch`, and the base sha — not from the tree `--pool` names. Run it from the project root with `--pool` aimed at a worktree and the record reads `owner_tree = , lane_branch = ` while every artifact in that pool belongs to the worktree. The verb prints its ordinary success line naming the wrong owner, and returns 0. - **Why it is silent, which is the whole entry:** the claim verb WRITES and never adjudicates (IR-42) — every enforcement arm lives in `crates/spt-store/build.rs` and speaks only at the next BUILD. So a wrong record has no symptom at the moment it is created; the first signal is a build refusal minutes later, on a lane whose `--pool` argument was correct all along. **`--pool` being correct is not evidence the record is.** Nothing on the command line shows you cwd, which is the one input that decided the outcome. - **Recovery is the documented hatch, and the bootstrap is why:** the claim tool builds THROUGH the pool it is claiming, so a pool already refusing cannot be re-claimed by the ordinary route. The refusal text says so itself — meaning the bootstrap case is known, and a wrong-cwd claim is the ordinary way a lane lands in it. - **The rule, as a must-do:** claim from the lane's own worktree so the identity the verb harvests is the lane's — `( cd && cargo run -p xtask -- pool-claim --pool "$PWD/target" … )`, or any form that makes cwd explicit. Then READ THE PRINTED RECORD BACK and confirm `owner_tree` and `branch` name the lane: the success line carries the record, so the check costs nothing. - **Trigger condition:** ripe now — it is a doc/UX fix on a verb we run every lane. Ripest alongside any other `xtask` pool-verb touch. - **Size guess:** small. Either make the verb REFUSE when cwd is not inside the tree containing `--pool` (loud, and it cannot be wrong), or print the harvested identity as a distinct confirmed line. The refusing form is preferred: it removes the reading step rather than adding one. - **Built evidence, corrected at review:** `pool-claim` resolves the git worktree containing `--pool` from the pool's nearest existing ancestor and compares it with the cwd worktree before writing. An accidental cross-worktree call returns 2, names both worktrees and the remedy, and leaves the not-yet-existing pool absent. The sanctioned sequential takeover carries an explicit `--foreign-pool`, says that it is harvesting the arriving cwd identity, writes that identity, and returns 0. Both poolguard refusal remedies now print that flag. An executable xtask test drives both arms against two real temporary git repositories, pinning VERB-ADMITS-REMEDY rather than merely testing path equality. This remains identity-harvest validation only: the claim still writes without adjudicating admission, so IR-42's enforcement boundary remains in the build. - **Second instance 2026-09-11 (todlando, #304 product lane):** an allocation packet carried the claim as `pool-claim --pool .worktrees/304-product/target` — correct from the repo root, WRONG from inside the worktree, where it resolves to a nested `.worktrees/...` path. Caught within seconds of launch, nothing written at the nested path, re-run with the absolute lane path. Rule: an allocation names the pool by ABSOLUTE path, because the claim verb acts on where it stands. ### IR-57 — an assembly pick's conflict resolution can silently DROP lines, and every gate run at assembly time is blind to it - **Status:** OPEN, owned by **doyle** (gater craft, not a code defect — no lane to dispatch). Filed 2026-08-22 from doyle's own defect on the TURNKEY #212 assembly head. - **What happened:** assembly head `5cce533d` **did not compile**, and was carried across a session boundary as a ready head with "treqs exit 0" attached to it. `crates/spt-store/src/access.rs` had an unclosed `mod tests`: the cherry-pick of the #206 lane commit `b2194aa9` conflicted against the #209 test block — both add functions to the same region, and the two sides share the trailing `);` / `}` / `}` — and the resolution deleted the markers without restoring the FIRST side's function closer. Exactly two lines lost: ` );` and ` }`. - **Every instrument in the assembly path reported success:** `git cherry-pick` completed with no conflict remaining; `traceable-reqs check` returned 797/797, 0 findings, exit 0 — **it parses tags and never invokes the compiler**; and the lanes themselves were green and stayed provably clean (the #206 lane's brace balance is correct at all five of its commits). **Lane-green plus conflict-free is not a claim about the assembled head.** Same lesson as the #182 v2 assembly (`E0425`×4) by a different mechanism: that one was a semantic composition break between two correct hunks, this one is a fidelity LOSS during resolution. - **Two must-dos, both cheap:** 1. **Compile the assembled head before it is handed anywhere — including forward to your own next session.** A head is not ready on a treqs exit; it is ready on a build. Any sentence carrying a head sha to another agent must name the instrument that proved it. 2. **Audit pick fidelity on CHANGED LINES for every pick on the chain**, not just the one that tripped you: hash `git show --format= | grep -E '^[+-]' | grep -vE '^(\+\+\+|---)'` for the lane source and for the pick, and compare. Whole-diff comparison is useless here — hunk headers and context legitimately drift once the head's copy of the file has moved. - **Read COUNT and HASH together, because they fail in opposite directions.** Of 24 picks on this chain two did not match. `b2194aa9 → 4d6deed1` differed in COUNT (302 lane / 300 pick by the header-excluding pipeline above; **this entry originally cited 310/308, which is the RAW `^[+-]` count INCLUDING the 8 `+++`/`---` header lines of its 4 files** — the figures were taken without the second grep the entry itself prescribes. The DELTA is 2 under either meter, which is why the wrong figures never surfaced: they supported a correct conclusion, so nothing pressed them. Corrected todlando 2026-08-29, measured both ways in-tree) — the real defect. `f27f15c6 → 5865cc98` had the SAME count and a different HASH — benign: a `CONTEXT.md` paragraph the head had already amended for #209, whose merged result correctly carries both lanes' sentences. A count check MISSES the first class entirely; a hash check FLAGS the second as if it were a defect. Neither alone classifies a pick. - **Repair shape used, recorded because it is the cheap one:** reset to the commit before the bad pick, re-pick the lane source, resolve the same conflict correctly, then replay the remaining picks in chain order with the fidelity check on each. Verify the repair changed nothing else with a WHOLE-TREE diff against the old head — it must show exactly the restored lines and no other file. Where a later pick re-conflicts, check its pre-pick blobs against the old chain (`git rev-parse ~1:`); if they match, the old chain's post-pick blob is a transferable, already-reviewed resolution. - **AND GATE THE REPAIR'S OWN SUBJECT.** The rebuilt head passed six legs — clippy `-D warnings`, sweep 660/660, treqs 803/803, xtask OK — while the restored lines live in `spt-store`, whose LIB tests `-p spt --bins` never runs. Six greens, and not one executed the function the repair restored; it was proven to COMPILE and assumed to PASS. Proven afterwards by name (4/4) and by the full `spt-store --lib` suite (519/519). **A repair's gate must include the suite that owns the repaired file**, which is not necessarily the suite the head gate runs. - **FIRST LIVE CATCH, and it was the author's own resolution (2026-08-29, one hour after the verb landed):** rebasing the IR-59 rider over the IR-57 rider produced four conflicts — three additive keep-both, one usage line both sides had edited. `xtask pick-audit` read the rebase as **LOSS, 282 lane / 280 pick**. The two missing lines were a `[[requirements]]` header and its blank line in `traceable-reqs.toml`, so `id = REQ-DISK-FLOOR-PREFLIGHT` landed INSIDE the previous table as a duplicate key: **`traceable-reqs check` exit 2, the registry unparseable, every reading after that edit checking nothing**. Restored, the same audit reads **DRIFT 282/282** whose one differing line is the usage string whose base copy legitimately gained the other verb — both verdi… - **FIRST REAL-ASSEMBLY USE (2026-08-29, #241 emission head, ASM-241-GATE-VERDICT.md):** `xtask pick-audit --range 57a0d27c..HEAD --lane 4d6007ac..d0fdd58d` over 6 picks — **5 MATCH (digest-identical), 1 LOSS, 0 drift, 0 unclassified**, exit 1 forcing the accounting. The LOSS was exactly the one human-resolved conflict (`cfb9d9f8 <- 10f12e4c`, count 432/402), and the delta RECONCILED to the resolution rather than assumed: lane stat 15 files/235+/197- vs pick 14 files/205+/197-, difference byte-for-byte the deliberately-dropped 30-line interim IR-69 register block superseded by main's consolidated entry. No false positives, no silent pass. Entry stays OPEN as living procedure; both live uses (the rebase catch above, this assembly) produced the verdict classes in the order the entry predicts. - **Trigger condition:** ripe at the next assembly — this is procedure, and its cost is one command per pick. - **Size guess:** small as a scripted check in `xtask` (fidelity audit over a pick range); zero as discipline, which is how it is being applied now. ### IR-58 — a `[[bin]]` grep is not a census: cargo AUTODISCOVERS `src/bin/*.rs` targets, and a hand-built bin list produced a confident false "this bin does not exist" - **Status:** OPEN, unowned. Filed by doyle 2026-08-22; **its original filing was WRONG and is retracted in full below.** The entry is kept because the way it was wrong is the finding. - **RETRACTED CLAIM, stated plainly so no reader acts on it:** this entry first said that `crates/spt/Cargo.toml:18-21` and `crates/spt/src/cli.rs:30355` forbid a bin-name collision with `xlate_choreo_fixture`, "a bin that does not exist", and that spt-daemon's third helper had been renamed to `summarizer_fixture`. **`xlate_choreo_fixture` EXISTS** — at `crates/spt-daemon/src/bin/xlate_choreo_fixture.rs`, verified at the assembly head. The collision rule's counterpart is real, both prose sites are CORRECT, and IR-21's original table row was correct too; it merely predated `summarizer_fixture`. Nothing in that prose needs fixing. - **How the false claim was produced, which is the entry:** the census was built by grepping `^\[\[bin\]\]` across `Cargo.toml`s. **Cargo AUTODISCOVERS `src/bin/*.rs` as bin targets with no stanza at all**, so a stanza grep cannot see them, and it fails SILENTLY — it returns a clean, well-formed list that is simply short. From that list it read as established fact that a named bin had been renamed away, and that "fact" was then written into a register table, an IR entry, and a message to the builder. **A pattern-built population encodes the pattern's assumption; the count looks like a census and is a property of the pattern.** (Found by todlando, resolving one of doyle's figures against his own tree under the pointer rule.) - **A CENSUS IS ALSO A PROPERTY OF A TREE.** Stanza counts differed legitimately across trees the same hour — 13 at the assembly head, 11 at `dc1c7532` — because `summarizer_fixture` exists at one and not the other. Two correct censuses of the same workspace disagree unless each names its sha. - **The must-do, and it removes the list rather than lengthening it:** never hand-maintain a bin roster. Run `cargo build --workspace --bins` and let cargo enumerate its own targets — the same enumeration the test harness resolves against, so it cannot drift from what a fixture lookup expects. Stanza-derived lists, remembered pairs, and register tables are all the roster problem at different depths; only cargo's own enumeration is the population. - **Kin:** IR-55's amended prebuild bullet (prebuild the census, not a remembered pair) and IR-42 (a verb that writes without adjudicating). The shared shape is an instrument returning an orderly answer about a set it never fully saw. - **Trigger condition:** ripe on any `xtask` check work — a duplicate-bin-name check over cargo's target enumeration (NOT over manifest stanzas) is a handful of lines and cannot go stale. - **Size guess:** small. The prose fix originally proposed here is WITHDRAWN — there was nothing wrong with the prose. ### IR-59 — pool arithmetic: this box holds TWO cold pools, not four; and a build that exhausts the volume reds as a LINKER defect that names no disk - **Status:** OPEN, unowned — it is arithmetic and discipline, not a code lane. Filed by doyle 2026-08-22 from a live disk-floor abort during the TURNKEY #212 W4 gate; footprint figures measured by todlando the same hour. - **v0.69.0 release close, 2026-09-11 (deployah, source record releases#294 comment 5628538587):** the first broad version/manifest battery failed to LINK (`LNK1180`, `LNK1108`, cargo exit 101), with **15,777,792 bytes free** measured at recovery. It produced no test verdict. The run selected the workspace's test binaries on the Cargo side even though the nextest filter did not need the e2e population; the replacement selected `--lib` for `spt-daemon`, `spt-runtime`, `spt`, and `xtask`, and passed **121/121** in 8.445 s. Root-target reclamation restored **66,926,968,832 bytes free**; the subsequent CI Windows unit step passed **3167 tests**, then its END floor refused at **15,360,114,688 bytes** against **34,359,738,368**. That is an observed resource-red AFTER passing tests, not an explanation of the earlier PR unit-step red whose log was unavailable. A second, classified CI `target/debug` reap, with runner intake stopped by the operator, increased free bytes **14,892,281,856 -> 78,994,501,632**. Runner service restored afterward. Publication used a preserved signer, not a Cargo rebuild into the cleared pool. These are two measured recoveries, not a durable capacity fix; IR-46/59/86 remain the next gate-driver capacity rider. - **SECOND FACE, measured 2026-08-23/24 (WAX-SEAL #21 W2 gate, doyle — the violator this time):** both predicted mechanisms fired at once, WITHOUT the floor guard because the gate legs ran as a plain script. (1) doyle minted a THIRD cold pool (gate rig) while todlando's lane pool was LIVE — the two-pool arithmetic, violated by the gater. (2) The lane pool had silently accumulated **104.8 GB** over repeated full-workspace sweeps (nothing bounds or even measures a pool's accumulation until the volume dies). The volume hit **3 MB free**; the reds wore exactly the entry's predicted costume — `LNK1318: Unexpected PDB error; LIMIT (12)` naming no disk — plus a second face worth keeping: `traceable-reqs check` died as a PANIC printing to stdout (`os error 112`), so a REGISTRY gate red can also be the disk's. Both gate verdicts VOIDED (clippy's full compile had exited 0 before space died — the code was never the question). Recovery measured: gate pool reap 9.6 GB, lane pool clean 100.2 GB, drive back to 109.6 GB free. **Remedies adopted at the incident:** the gate never mints its own pool while a builder lane is live on the box — it takes the lane pool over SEQUENTIALLY at pool-release (warm, loud, the releases#103 pattern); and gate/lane scripts get the disk-floor preflight the golden runner already carries (this entry's part 2, still unbuilt). - **THIRD FACE, measured 2026-08-24 (WAX-SEAL #21 golden window, doyle):** two new mechanisms, both about the REMEDY rather than the red. (1) The wax-seal-w1 lane pool **re-accumulated to 152–169 GB (two meters, IR-46 caveat) within ONE DAY of the 08-23 clean** and rode the volume back down to 4.92 GB free — a reap is an instant, not a state; nothing yet bounds a pool between reaps. (2) **The remedy itself arrived garbled through relay:** the golden push was held "waiting on the IR-59 reboot" when this entry prescribes no reboot anywhere — tens of releases have shipped without one; the operator refused the premise and the register's own recorded remedy (reap finished-lane pools) cleared it in ten minutes. A remedy relayed as a DIFFERENT remedy is the relay trap wearing infra clothes: the entry is the author — read it before adopting a hold. Recovery measured: five finished-lane pools reaped after ancestry classification (`git cherry` catches rebased lands that a plain `merge-base --is-ancestor` calls unlanded — gate-w4l1's 90.9 GB pool was reapable only by that meter), 4.92 → 260.88 GB free (~256 GB free-delta vs ~270–287 GB sum-of-lengths). Two main runs red inside the low-disk window (09:17Z/09:41Z) were re-run, not re-read, per this entry's must-do. - **FOURTH FACE, measured 2026-08-24 same day (SIGNET #218 W2 gate, doyle — the gater's own pool this time):** the MAIN pool went **13.7 GB → 158.3 GB in ONE DAY** absorbing four full gate batteries across two lane tips, and dragged the volume to **18 GB free mid-gate** — so the entry's mechanism is not a lane-pool problem, it is EVERY pool under repeated full sweeps, the gate rig included. Two riders worth the ink: (1) the golden runner's **free-space floor step produced its first live catch** — a thin CI leg refused at 14:14 local over exactly this window with zero test signal, and the register's re-run-not-re-read rule resolved it in one command; (2) the reap-and-rebuild trade ("cleaning a live pool buys one window at rebuild price") was taken deliberately mid-gate and cost ~35 minutes cold — cheaper than one uninterpretable red. A red measured at 18 GB free in this gate got NO read at all, and the next sweep's red was a DIFFERENT test: low disk manufactures random victims before it manufactures link errors. - **The event:** a gate's preflight refused with `GATE_ABORTED_DISK_FLOOR` at **4.75 GB free on a 1863 GB volume**. Four cold pools plus the milestone head's pool were standing at once. The floor guard did its job — without it a full workspace build would have started with under 5 GB of headroom and produced a red belonging to nothing. - **THE ARITHMETIC, and it corrects the intuition that worktrees are the cost.** Measured across the whole `.worktrees` tree: **45 worktrees = 0.79 GB total** (~18 MB each). **3 pools = 130.45 GB.** Worktrees are **0.6%** of the footprint; pools are **99.4%**. **One cold pool is worth roughly 2,500 worktrees.** A rule keyed on worktree count would cost a day of `git worktree remove` work for under a gigabyte, risk removing a lane someone still wants, and leave the lever untouched. - **THE CEILING, as arithmetic rather than hygiene:** at **45–75 GB per cold pool** on this workspace against a **40 GB floor**, this box supports **TWO live pools comfortably, THREE only if one is small**. The two rules that already exist need no replacement, only this number attached: - **Reap a pool when its lane is finished** → 45–75 GB back immediately. - **Do not run two builds at once** → not only the contention argument, but **75–150 GB of simultaneous allocation** against that floor. - **A FULL VOLUME REDS AS A LINKER DEFECT.** `LINK: fatal error LNK1318: Unexpected PDB error` (variously `OK (0)` or `LIMIT (12)`), often beside `LNK4209: debugging information corrupt`. It reads as a corrupt artifact or a broken toolchain and is neither — it is the linker unable to grow a large `.pdb`. **Nothing in the failure text says "disk".** Do not key recognition on the parenthesised code; it varies. - **THE DANGER WINDOW IS THE TAIL OF A COLD BUILD, not a steady state you can check once.** The 2026-08-22 instance died at the link of `spt` — the last and largest artifact of a **74 GB** cold pool — while that same build was draining the volume out from under itself. A free-space reading taken before the build would have looked fine. - **Positive tell, with its own refutation attached:** `traceable-reqs check` alone surviving a leg table is suggestive, because it is the only leg that never links. It is a POSITIVE tell ONLY — a full disk can red before any link step, so the signature's ABSENCE clears nothing. - **THE FALSIFIER IS FREE SPACE AT THE TIME OF THE RUN**, not the shape of the leg table. - **Must-do, both cheap:** 1. **A free-space reading goes in the FIRST LINE of any build-failure report** — not in the controls, not as a follow-up. Two agents spent hours on a mechanism for this failure and neither ran `df`; the falsifier was one command away throughout. 2. **Rig and gate logs should record free space at run start.** Today they do not, which makes "was the disk full" **unanswerable after the fact for every red already in hand**. Any red produced under ~1 GB free is UNINTERPRETABLE and must be **re-run, not re-read**. - **Measurement caveat, observed twice in one hour:** sum-of-file-lengths and free-space delta disagree by several percent when anything else on the box is writing (98.07 GB of subtrees → 92.25 GB reclaimed; 47.28 GB → 40.81 GB). Report BOTH, derive neither from the other, and treat any single free-space number as an instant rather than headroom — see IR-46. - **FIFTH FACE, measured 2026-08-29 at the CONDUIT #236/v0.65.0 cut (deployah):** the finished milestone's sequential lane-sharing accumulated **140.51 GB**, while a freshly rebuilt pool measured **7.78 GB** — about **18× one build's working set** retained across lane hand-offs with no reap between them. This is the budgetable rate behind that cut's disk-floor red: sequential execution prevents concurrent ownership corruption, but it does not bound historical artifacts inside the shared pool. Treat takeover and reclamation as separate operations; a pool may be safe to reuse and still be too large to keep. - **SEVENTH FACE, measured 2026-08-30 (v0.67.0 milestone close — the PARALLEL-LANE fill rate):** the #23 wave arc drove C: from ~240 GB free to **0.01 GB in ~3.5 hours**: four concurrent/serial lane+gate pools totalled **236.6 GB** (ns23-w1 87.7 + ns23-113 72.3 + gate rig 57.3 + ns23-w3 19.1) — effectively the entire ir57 reclaim re-consumed inside one milestone's build window. The head gate and two thin-CI runs redded with the entry's exact costume ("could not compile" + treqs panic, zero disk words) at 0.01 GB and all re-earned green after reclaim (+186.6 GB, finished-lane targets only, single-actor rule held under racing consent). Budget rule this face adds: a MULTI-WAVE milestone on one box books ~60-90 GB PER LANE-PLUS-GATE cycle, so the pool budget is per-wave, not per-milestone — reap each wave's pool at its LAND, not at the milestone party (the party inherited only ~58 GB because the emergency had already forced the other ~179). - **SIXTH FACE, measured 2026-08-30 (#242 golden r4, Windows test job, LNK1318 at the PDB write):** the floor is asserted ONCE at job START, but the job's internal LOW-WATER sits at its LAST heavy step — the docs-drift build, ~28 minutes in. r4's floor read 65.1 GiB honest at 23:07; the box was at ~37–39 GB by the 23:35 link failure. LNK1318 on PDB write = this entry's documented low-disk costume; the incremental-corruption candidate was retired by preservation snapshot (no xtask state existed at failure). **Durable fix = a floor RE-READ (or reclaim) immediately before the docs-drift build** — the WITHIN-job sibling of the across-job read-after-checkout fix, rides the next workflow commit. Riders: incremental hygiene as disk-pressure maintenance (the dir measured 4.56 GB), and the box's **~51 GB non-recovering post-run consumption** is this entry's pool-weight face — classify at the IR-14/26/27/49 audit slot (composed this sweep). - **Composed for next intake (doyle, v0.65.0 close):** the still-open log-the-floor build half rides with [[IR-57]]'s scripted pick-fidelity audit as the next milestone's two tooling riders. - **Trigger condition:** ripe now for the log-the-floor half (it rides any gate-script or CI touch); the arithmetic is discipline and applies immediately. - **Size guess:** small — one line in each rig/gate preflight to record free space alongside the existing floor check. ### IR-60 — a wrapper that CAPTURES a leg's exit status ends with the capture, so the wrapper's own status is the capture's, not the leg's - **Status:** OPEN, unowned — script-shape discipline, not a code lane. Filed by doyle 2026-08-22 during the TURNKEY #212 W5 lane; mechanism measured by todlando, who reported it first as a possible harness misreport and then RETRACTED that reading himself on a minimal probe. - **v0.69.0 recurrence, 2026-09-11 (deployah, own withdrawal):** `NEXTEST_EXIT=0` and the task completion's exit 0 both described the wrapper/truncation path, not Cargo's **101**. `PIPESTATUS` was read outside the executing subshell, so the named verdict measured `tail`. Both green-looking receipts were withdrawn; the raw failed-link output was retained. **An exit FILE alone is insufficient if its writer captures the wrong process.** Capture immediately inside the shell executing the producer, before any other command replaces the status, write that value to the leg's file, and propagate it when wrapper status is reported. The replacement battery's own file read 0, with 121 tests actually run. Keep this entry OPEN: corrected execution of one driver does not make the faulty wrapper shape unreachable. - **The reading that started it:** a background leg was summarised as `exit code 0` while the leg's own exit file read `100`. Reported as-is, that is a task runner lying about a red — the worst possible direction for a purposeful-red claim, since it would turn two reds that DID fire into two reds reported as not having fired. - **The measurement, minimal and on this box:** ( exit 100 ); echo $? > probe.exit; FINAL=$? leg status captured to file : 100 wrapper's own final status : 0 The wrapper's shape is `( cd && cargo nextest ... > leg.raw 2>&1 ); echo $? > leg.exit`. **The last command is the `echo`, which succeeds**, so the wrapper genuinely exits 0 while the leg genuinely exited 100. THE RUNNER TOLD THE TRUTH ABOUT THE WRAPPER. There is nothing to file against the task runner, and it would have been filed. - **The class, and this is why it is worth an entry rather than a fix:** it is the truncation-pipe family — the meter measured something real, it just was not the thing about to be quoted. **Three shapes now share ONE trigger, and the trigger is not "is this a pipe":** 1. a truncation pipe (`cmd | tail`, `cmd | head`) — `$?` measures the truncator, and `head` closing the pipe can MANUFACTURE a status (SIGPIPE → 101), so `PIPESTATUS` is not protection either; 2. a flattened `$?` read after any intervening command; 3. **a wrapper whose last command is the capture itself.** **The trigger in all three is the REPORTING** — every instance happened while trimming or capturing output in order to QUOTE it as evidence. - **The practice that held, and the one to keep:** the leg's own file is the leg's verdict. Both reds were real, and the only reason that was knowable is that every leg wrote its exit to its own file rather than to the wrapper's status. - **Remedy, in preference order:** (1) never read a wrapper's status as a leg's — read the leg's exit FILE, which the per-leg rule already requires; (2) if a wrapper's own status must be meaningful, end it by re-raising the captured status (`exit "$(cat leg.exit)"`) or set the status before the capture is the last word; (3) for anything that becomes evidence, redirect to a file and read the file. - **Trigger condition:** ripe now — it rides the next gate-script touch, and the gate scripts in this milestone already write per-leg exit files, which is what makes this discipline rather than debt. - **Size guess:** small — a convention line in the gate-script preamble; no product code. ### IR-61 — spacerun's test-module skip carries a SECOND literal tracker; the two answers can drift, and today only a cell stands between them - **Status:** OPEN, unowned, accepted-with-mitigation. Filed by doyle 2026-08-22 at the TURNKEY #212 head gate, as the named residual of the latch repair (the repair itself rides the milestone). - **What the debt is.** `crates/xtask/src/spacerun.rs` now skips a column-0 `#[cfg(test)]` module by BRACE DEPTH and resumes after its close, rather than latching the scan to end-of-file. Counting braces safely means knowing when a brace is inside a string, a raw string or a char literal — and the scanner ALREADY tracks literals for its rendering pass. It does not reuse that tracking. There are now TWO answers in one file to "am I inside a literal", and **two answers to one question is a disagreement waiting for a reader who fixes one of them.** - **Why it was accepted rather than refactored on the spot, stated so the trade is auditable:** the two trackers answer genuinely different questions — the rendering walk is PER LINE and forward from an opening quote ("where does this literal start and end"), while the skip needs "am I inside a literal right now" carried CONTINUOUSLY across lines. Unifying them is a real refactor of a check that is already gated, already carries five fixed defects, and sits on the tree being handed to golden. The narrow change with an OBSERVABLE failure mode beat the correct-shaped change with a wide blast radius, on that tree, on that day. - **The mitigation, and its exact limit.** Three brace cells fail the moment the two trackers disagree about a raw string, a normal string or a char literal, plus a cell that reds when the skip stops consulting a literal tracker at all (`match lit` -> `match Lit::None`). **That is a cell standing in for a refactor.** It catches drift in the three forms it names and nothing else — a fourth literal form, or a change to only one tracker in a form neither cell covers, passes. - **The general shape, which is why this is a register entry rather than a comment:** a check whose own correctness depends on a second implementation of a thing it already implements is one refactor away from the defect class it exists to prevent. This same file has already produced three instrument defects (an indented-marker latch, a column-0 latch, and a suppression that decided what got PARSED rather than what got REPORTED). The pattern is not carelessness; it is a scanner accumulating special cases. - **Trigger condition:** the next SUBSTANTIVE change to spacerun's scanning — any new skip, any new literal form, any change to either tracker. At that point unify, rather than adding a third answer. - **Size guess:** small to medium — one continuous literal-state walk serving both the render pass and the skip, with the existing corpus and brace cells as the regression net. ### IR-62 — an e2e daemon binds well-known ports and collides with the resident fleet on shared runners Filed 2026-08-23 (doyle), from the #212 r2 golden's Windows Phase A red — one witnessed instance, mechanism verified from the run's own capture, filed on the mechanism per the register's standard. **Mechanism.** `endpoint_autostart_e2e::saved_endpoint_replays_on_daemon_restart` failed its own PRECONDITION ("daemon B must come up with a fresh brain") because daemon B's broker came up degraded: `NODE_KEY_FAIL: identity unavailable` (net-less broker, no retry) and `DOCS_SERVER_BIND_FAIL` port 5474 `os error 10048` — the docs port was held by a CO-RESIDENT daemon. HFENDULEAM is live infra: the resident fleet's daemon legitimately holds well-known ports, and any e2e that brings up a daemon with default port bindings is in a race with it BY CONSTRUCTION. An isolated SPT_HOME isolates the store and broker socket, NOT globally-numbered TCP ports. **Classification history.** r2: red (35.4s, precondition panic). Run 1 and r3 on the same box: green. Folded into r3 under a pre-registered predicate (reds twice → dedicated triage); it greened, so this stays an environment-shaped intermittent, NOT a product defect and NOT closed — the collision window is real and will re-fire under the right co-residence timing. **Remedy direction (not built).** Test daemons should bind ephemeral/rig-scoped ports for every advisory surface (the docs server is advisory — a bind failure should degrade the rig loudly, not poison an unrelated cell's precondition), or the precondition should name the port-collision cause distinctly so the red self-classifies. Either lane is test/CI work (hertz's), triggered the next time this class fires anywhere. **Kin.** IR-51 (e2e daemon net-enabled on real interfaces — hermeticity is disk-deep only); the known not-ours red classes list in the #212 hand-off. **BUILT 2026-08-24 (hertz, SIGNET #218 batch; PR #158).** The class fired its second witnessed instance the same day — doyle's W2 gate rig, `engine_room_bringup_e2e` precondition panic with the IR-50 panel naming `DOCS_SERVER_BIND_FAIL` port 5474 `os error 10048` — which armed this entry's own trigger. Hertz repro'd deterministically (held the port; brain still reached BRAIN_UP), pre-ranked three mechanisms before probing, and built the ephemeral-advisory form: rig-only `SPT_TEST_EPHEMERAL_ADVISORY_PORTS=1` makes the daemon's docs listener bind port 0 (production config/`SPT_DOCS_PORT`/docs-url untouched; the flag matches the literal "1" only). The golden workflow's test job sets it globally on both self-hosted legs, the standalone ER rig sets it too. Scope note kept honest per his own ranking: the docs collision is retired; if a co-diagnostic bind elsewhere still poisons a precondition, that is a residual face of THIS entry, not a closed question. ### IR-63 — suite-mix sweeps leak job-escaped autostart daemons that LOCK the pool's spt.exe; and the same box conditions manufacture one random victim per sweep - **Status:** OPEN, mitigated-by-rig-step — the reap is adopted discipline, not yet construction. Filed by doyle 2026-08-24 at the SIGNET #218 gates; first measured by todlando the same day (his W1 build: four reap rounds of 2, 8, 1, 1 processes, count-by-path stated each round). - **Mechanism, two faces of one condition:** (1) e2e sweeps that exercise autostart leave job-escaped daemons running `target/debug/spt.exe`; the NEXT build or `xtask check` then dies on `os error 5` removing the exe — a rig red wearing a build defect's clothes. nextest's own `leaky` flags corroborate (4–8 per sweep measured). (2) The same co-residence (leaked daemons + resident fleet + runner traffic) manufactures ONE red per full sweep with a DIFFERENT victim each time: doyle's W2 gate measured FOUR distinct one-off victims in four same-sha sweeps (ER bringup, composite+bootstrap pair under CI load, resident_service, brain_resume), every one green alone and/or in a sibling sweep. The e2e-leaked-daemons rule holds: a different test dying each run on one sha is ONE environment cause, and hardening members never closes it. - **Mitigation adopted (rig step, both todlando's lanes and doyle's gate runner):** reap `spt.exe` BY PATH (`*spt-core\target*`) before EVERY cargo invocation and after every sweep; report the count each time so a zero is a claim, not silence. - **Remedy direction (unbuilt):** the durable form is construction, not discipline — either nextest wrap/xtask verb that performs the by-path reap as a pre-step on this box's rigs, or autostart e2es gain teardown that provably outlives job escape (kin IR-38's built wedge-namer, IR-62's ephemeral ports which retire one collision axis, IR-35's victim-rate ledger). - **THIRD FACE, measured 2026-08-30 (doyle, ir57/asm-241 reaps):** the leaked population is not only daemons — battery legs leave ORPHANED HEADLESS `conhost.exe` processes whose CWD sits in the worktree's `crates/spt-daemon` (where the leg ran), and a CWD pin blocks `Remove-Item`/ `git worktree remove` on the whole tree with "being used by another process" naming the DIR. This is the mechanism behind every recent "handle-pinned, retry later" worktree removal: 31 such conhosts found at once (Aug 26–29 vintages) pinning FIVE dead worktrees. cargo/rustc absence does NOT clear the suspect list — the conhost outlives its client. Holder census tool: a ~30-line NtQueryInformationProcess CWD probe (PEB→ProcessParameters→CurrentDirectory) over all pids, filtered on the path — names every holder in one pass where no handle.exe exists. 13 killed scoped to the two consented reaps; 18 remain pinning gate-w1-a8f04aff (12), io-parser-w1 (5), gate-w1-786d2381 (1 after kills) — sweep them at the IR-14/26/27/49 audit slot before those removals. - **LANE-LINKED 2026-08-30 (#242 close sweep):** hertz's queued daemon-leak fixup lane carries this entry (brief cites IR-7/17/20/34/35/63); leaves the register when that lane lands. - **Trigger condition:** next rig/gate-script construction touch, or the first golden red that classifies to face (1). - **Size guess:** small-medium — one wrapper seam plus adopting it in the gate/lane scripts. ### IR-64 — HFENDULEAM's disk floor is set by non-CI bulk: ~845 GB of operator payload leaves the golden box ~2 GB of slack against its own 32 GB preflight - **Status:** OPEN · **Origin:** doyle, v0.63.0 close sweep 2026-08-26; mechanism first measured at the FIELD-SEAL golden window (deployah's IR-31 fifth addendum carries the POOL side of the same event by agreed division — this entry is the OTHER reservoir, deliberately not his). - **Mechanism:** the 1.86 TB C: carries ~614 GB Steam + ~230 GB Downloads (operator payload, not CI state). With that floor fixed, normal lane traffic alone walks the box under the 32 GB golden preflight — a full-sweep pool WEIGHS ~90–112 GB steady state (IR-59's measurement) and five FIELD-SEAL lanes cost 148.48 GB (IR-31 fifth addendum), so ONE milestone's pools exceed the entire free margin. Reaping buys windows, not headroom: deployah measured free fall 167 → 108 GB within hours of his reap, ~59 GB re-consumed by lane builds. The recurring shape: every milestone pays a reap-and-measure tax to rent space the box does not structurally have. - **Why register-worthy rather than "clean up more":** agent-side discipline (IR-31's budgeting, pool reaps, teardown steps) is already adopted and still only rents windows — the reservoir that would durably move the floor is operator-owned bulk no agent may touch. Naming it here is the boundary: agents keep budgeting IN POOLS (not GB); moving Steam/Downloads (or adding a disk, or pinning golden to a box without operator payload) is an OPERATOR decision this entry exists to put in front of them once, with numbers, instead of re-deriving the floor each cut. - **Ripe when:** operator rules on the bulk (move/expand/accept-the-tax), OR the first golden that dies at the 32 GB preflight despite adopted pool discipline (IR-59's LNK1180-class red). - **Size:** zero code; one operator decision + at most a runbook line naming the chosen floor. ### IR-65 — kitsubito kernel-audit backpressure: a tailscale-snap AppArmor denial storm + no auditd turned the default audit backlog into a CI-wide stall amplifier (REMEDIATED AT BOX; re-check triggers named) - **Status:** REMEDIATED-AT-BOX 2026-08-25 (doyle, operator-authorized root — ruling pinned releases#225 comment 5418800776); entry stays OPEN as the re-check record because the storm SOURCE persists and two named events can silently revert the fix. - **Mechanism:** `snap.tailscale.tailscaled` (1.92.5) polls /proc and takes an AppArmor ptrace-read DENIED per poll — a continuous kernel-audit record storm scaling with process count (spawn-heavy serialized CI legs amplify their own storm). With NO auditd installed the records rode printk (kauditd throttling) and the 8192 kernel backlog overran (lost=1,537,743); the default `backlog_wait_time` 60000ms turns a full backlog into A 60s SLEEP INSIDE ANY AUDITED SYSCALL — the broker dispatch stall that stretched IR-30's Linux-face race window (see IR-30's Linux-face addendum; deaths clustered 59–63s ↔ this knob's value). - **Remediation (verified at the EFFECTIVE layer, not the fragment):** auditd installed + active (storm consumed, backlog drains to 0, lost flat), backlog_limit 32768, backlog_wait_time 0 (full backlog may DROP, never STALL). ⚠ THE TRAP PAID FOR ONCE: the first knob write (`50-backlog.rules`) silently LOST the augenrules merge — apt's own `/etc/audit/rules.d/audit.rules` sorts LAST (digits before letters) and its `-b 8192` / `--backlog_wait_time 60000` won; a whole proof run executed under the defaults while the fragment grepped perfect. Values now live in the merge-WINNING file; verified `auditctl -s`. - **Re-check triggers (the reason this entry stays):** (1) tailscale snap update — the plug landscape may change, the storm may stop or grow; (2) auditd package update/reinstall — may rewrite `rules.d/audit.rules` and re-lose the merge; (3) box reimage. On any of these: one `auditctl -s` (expect 32768/0) + one `journalctl -k | grep 'backlog limit'` (expect silence). - **Ripe when:** a re-check trigger fires. **Size:** two read-only commands per check. ### IR-66 — first-chunk-needle test class: two latent members remain after the v0.63.0 fix (attach.rs:561, :672) - **Status:** CLOSED / BUILT — release-close reconciliation 2026-09-11. The WEBSERVE JIT already ruled this satisfied; source at `e5a2fed9` retains both delayed needles. Closure uses the recorded gates below, not v0.69.0's unrelated green receipts. Hertz rider PR #161, landed ff at `d04b922d` (2026-08-27, IO-PARSER #22 intake rider). Both members got the later-needle treatment (TICK39 delayed past burst on both OS arms; alt-screen entered before delayed ALT_VIEWPORT_MARKER). Gate: doyle — diff-scope review; Windows isolated worktree 3× TICK39 PASS + clippy + treqs; Linux CLEAN worktree at the PR sha on kitsubito 3× both cells PASS (independent of the builder's dirty-shared-tree proof, disclosure on record). · **Origin:** doyle tree-wide census at `dbe3daad` (releases#225 comment 5418844404 — the census that corrected my own resume.rs-scoped overclaim), after the class's first member was RCA'd and fixed in v0.63.0's head. - **Mechanism (cite, not restate):** KNOWN-HAZARDS 6.9 same-session face, amended at `dbe3daad` — `spawn_session_pid`'s Spawned-wait consumes-and-discards a first output chunk that races the reply (~2ms window on a healthy Linux box; load-stretched under backpressure, see IR-30 Linux-face + IR-65). A test whose needle exists ONLY in the child's first chunk asserts winning a race the contract does not promise. - **The two members:** `crates/spt-daemon/tests/attach.rs:561` (TICK0..39 instant burst then `cat`; needle TICK39 read directly after spawn — the whole burst can sit in the first chunks) and `:672` `cross_node_cold_attach_to_alt_screen_gets_clean_repaint` (unix-only; `printf '…ALT_VIEWPORT_MARKER'; cat` — needle in the first chunk). Failure shape differs from the fixed member: both children idle on `cat`, so a lost prefix is a HANG killed by nextest's backstop at exactly 240s (slow-timeout 60s × terminate-after 4) — not a natural-life death. Verified NOT in the class: daemon_e2e.rs:209 (needle = echo of post-spawn input), attach.rs:995 + brain_swap.rs:170 (attach/replay reads, not spawn-waits). - **Fix shape (ruled at the v0.63.0 close):** hertz lane, NEXT intake — the same one-line later-needle / robust-read treatment the resume seed got in `dbe3daad`; deliberately NOT landed mid-r4. Both cells passed r4 (0.010–0.058s) — the members are latent, not failing. - **Ripe when:** next milestone intake (hertz test lane) or the first golden red at ~240s on an attach cell — either way the mechanism and fix are pre-derived, triage should cite this entry and skip the RCA. **Size:** two one-line test edits. ### IR-67 — wave-battery gap: a `-p spt --bins` leg compiles bin targets as harnesses and runs ZERO integration/e2e tests, so batteries that lean on it carry silent no-coverage legs - **Status:** BUILT — remedy applied across the IO-PARSER #22 milestone (2026-08-27/28): every wave battery named explicit `-p spt --test ` e2e legs beside the `--bins` unit leg (GW1..GW5 evidence), every builder evidence report carried a named real e2e per the dispatch template, and the one filter mistake (a `--test` name not matching its file) REFUSED loudly rather than silently skipping — the failure mode this entry exists to kill. Battery template = the dispatch text now carried forward in gate craft. - **Was:** OPEN · **Origin:** doyle, banked at the SIGNET #218 gates 2026-08-25 ("gate battery gap learned"), filed at this sweep per the standing rule. - **Mechanism:** `cargo test/nextest -p spt --bins` builds `[[bin]]` targets as TEST HARNESSES (unit tests inside bins only) — `tests/` integration and e2e suites of the crate NEVER run, and the leg's green output is indistinguishable from coverage. Kin of the two banked pool faces (`--bins` never emits fixture exes; fresh-pool fixture reds) but this face is about the BATTERY TEMPLATE: my SIGNET wave batteries carried a `-p spt --bins` leg believed to cover the crate. - **Remedy:** at next intake, the wave-battery template gains an explicit `tests/` leg for the spt crate (nextest `-p spt --test ` or unfiltered `-p spt` where pool history permits), and any battery doc that lists `--bins` as a coverage leg gets the one-line caveat. - **Ripe when:** next milestone intake (the battery template is touched at every intake). **Size:** template lines only. ### IR-68 — PSYCHE_INGEST_FAIL cause class unproven: git index.lock did NOT reproduce the ingest failure it was blamed for - **Status:** OPEN, investigation-shaped · **Origin:** todlando measurement at the W2 int-leg rig (IO-PARSER #22, PR #163 at `769fb0a9`, 2026-08-27), reported measure-first; filed by doyle. - **The contradiction:** the six silent `PSYCHE_INGEST_FAIL:todlando` lines observed at the drop-dir probe (2026-08-25) were attributed to shared-checkout git `index.lock` contention. The W2 rig planted NON-EMPTY `index.lock` files in BOTH places git takes one (bare git-dir + every `/worktrees//`, mirroring `branchstore::sweep_stale_index_locks`, plant count asserted >= 2) — and the ingest COMMITTED ANYWAY (tier write `Written`; `route_slices` propagates `commit_live(...)?`, so a blocked checkpoint would have failed it). Non-empty was deliberate: KH 1.3 reaps only 0-byte locks, and `pulse_tick` runs no boot sweep. So on this store an `index.lock` does not block the checkpoint, and the field incident's mechanism is UNKNOWN, not merely unconfirmed. The rig's doc comment records the attempt; the shipped int leg fails the ingest at the drop READ instead (upstream of the store). - **Strongest negative evidence, pinned to the executable rig:** `crates/spt-daemon/tests/commune_io_events_int.rs:95-107` documents that the lock mechanism was tried **first**, planted non-empty locks in both the bare git-dir and every linked-worktree location, asserted that the population was non-empty, and still observed `Written`. Its own sentence is the required scope boundary: “This leg does not claim to reproduce a mechanism it measured as inert.” The working injection is instead drop-file → directory replacement, which fails the upstream read deterministically and proves only the `COMMUNE_FAIL` event contract. - **NOT claimed:** that the field incident was misattributed to ingest failure generally — the files did survive with failed-ingest log lines; what is unproven is the index.lock CAUSE. - **Ripe when:** next PSYCHE_INGEST_FAIL sighting in the field (capture the failing store state before touching it), or a dedicated probe slot. W2's COMMUNE_FAIL event now pushes a NAMED reason on every failure, so the next occurrence self-reports its cause — read that first. **Size:** investigation; no product change until the mechanism is pinned. ### IR-69 — inherited stderr tokens can tear between format fragments; 26 test consumers parse that surface as structured truth - **Status:** OPEN for the #243 residual population and anchored-consumer work. The original product remedy LANDED at `ec6da9b0`, as recorded in this entry's later amendment; it is not still parked awaiting assembly. Releases#241 retains its original lane evidence in comment 5461613480. This entry is the exposure map and census discipline; residual conversion, generator repair and a SHA-pinned zero recensus remain owed. · **Origin:** CONDUIT #236 r3 golden attempt 2, 2026-08-29: `endpoint_autostart_e2e` missed its contiguous `ENDPOINT_AUTOSTART:gwauto` keystone although the matching fresh session id proved the replay happened. Attempt 3 was clean on the same discarded SHA after 139 GB was reaped; unequal load makes the pair corroborating, never a rate. - **Mechanism, recovered from the literal torn bytes:** two daemon processes inherited one stderr pipe. `BRAIN_UP` and `ENDPOINT_AUTOSTART` are each one `eprintln!`, but `write_fmt` may reach the handle once per format fragment; the per-process stderr lock cannot serialize the other process. The observed interleave split the autostart token between `ENDPOINT_AUTOSTART:` and `gwauto`. This is fragment-level cross-process interleaving, not a failed replay and not a two-thread race. - **Durable remedy, ruled product-side:** render a complete diagnostic line into one buffer and issue the complete rendered text, newline included, as **ONE handle call**. An OS short-write may retry the late tail so completeness wins over a silently truncated line; the deterministic property pins application-side fragmentation, not syscall count under that rare retry. It makes no claim that the OS write is atomic on Windows, and no CI re-fire against a 1-of-2 observation may stand in for it. Widening one test's grep is refused: it greens one consumer while every sibling token remains exposed. - **Cut-SHA census** (todlando generator, independently hash-verified by hertz), measured from `4d6007ac4ee3d0991f4bc60b7e1a55825aad1aaf` via `git show`, not a dirty worktree: **486 real emitter sites / 383 distinct tokens / 26 consumer test files**. The generator emitted 487 site rows, but one is a known phantom: `sealverb.rs:456` is a `format!` inside `map_err` that the four-line lookback attributed to a neighbouring real `eprintln!`. Corrected real emitters by crate: spt-daemon 270, spt 194, spt-runtime 8, spt-live 5, spt-net 5, spt-store 4; by macro: `eprintln!` 484, `println!` 1, `eprint!` 1. `DRIVEN_BY` is the sole stdout row and therefore outside the stderr remedy. A consumer means the test both mentions `TOKEN:` and reads a stderr/log surface; bare-token matching inflated the population to 72 files by admitting prose. This is an **exposure map**, not a rate and not a claim that all 26 have torn. - **Artifacts (the preserved raw generator outputs contain 487 site rows):** cut census SHA-256: sites `f10d6bfe5e0399f98945cf63bb5719a01a62e1251be84165c73030fa9bb224f5`, tokens `80b0d1835d9d46376b2f200b1c50be4ca0e185a135168444414255f9308ed92b`, consumers `249a2e33df43a30570ca82b5bd200d8b6e2bf07aa8250fcc8bace47fe23e3cbc`. The sealed sites file's macro column is wrong on 7 of its 487 raw rows; the corrected raw split is `eprintln!` 485 / `println!` 1 / `eprint!` 1. The sealed tokens file has no final newline, so `wc -l` reports 382 although it contains 383 logical records. The sealed files remain unedited; these corrections are textual. Generator `81df82f01ef33a82307920d9804a2394b787ef2ffbe3b41d2d7dda560d9a62a9` was recorded as asserting newline-terminated output, but the sealed tokens artifact refutes that claim for at least one output. Its remaining guards cover logical record counts, a known-positive `SUBSCRIBE_DECISION` sentinel, four-line macro lookback, and truncation only at a `#[cfg(test)]` that opens a module. - **Census hazards paid for while constructing and reconciling the population:** the provisional instrument moved `277/243 → 286 → 412 → 487 raw → 486 real` as four silent assumptions were found: same-line matching misses multi-line macros; truncating at the first `#[cfg(test)]` drops later shipping code; lookback must prefer the token line's own macro over a neighbouring arm; and even that lookback can promote a nested token literal beneath a real macro into a phantom second site. A file without a final newline also makes `wc -l` silently undercount logical records by one. Every future census must name its SHA, assert a known member, count records inside the generator, and reconcile emitted rows to real sites. - **Separate anchored-matcher finding:** `IDLE`, `DISPATCH`, `BUSY`, and `BOUND` are common words matched as substrings in exposed consumers. One-write emission does not prevent an unrelated log line from satisfying them; those predicates need anchored token matching. Keep this separate from the tear remedy so neither defect is claimed to close the other. - **Kin:** [[IR-50]] (the sink must be read before its absence means anything), [[IR-40]] (a confident signal that does not describe the source truth), [[IR-8]] (a plausible census whose blind spot returns a clean answer). - **CLOSE-OUT ADDENDUM 2026-08-30 (#242/v0.66.0 sweep — the entry's own close-out re-census RAN and FOUND the predicted blind spot LIVE; entry stays OPEN):** re-census at the landed sha `ec6da9b0` (independent containment-classified meter, reconciled with todlando's independent meter — full write-up `EMISSION-RESIDUAL-CENSUS-FINDING.md`): the generator truncated `crates/spt/src/cli.rs` at its FIRST module-opening `#[cfg(test)]` (line 3007, module closes 3164, file runs to 39118) and never scanned the rest — **338 TOKEN-shaped shipping sites remain bare (332 colon-form, i.e. misses under the sealed census's own predicate, + 6 space-form)**, plus `main.rs` 2 sites behind the same mechanism; exactly TWO files tree-wide carry the triggering property (first module-opening cfg(test) precedes shipping code) — the generator fix's owed blind-spot measurement, answered. The census-hazards bullet above already NAMES this third-face truncation hazard; the module-opening fix narrowed the trigger and kept the blind spot for files where a test module CLOSES and shipping resumes — IR-8 shape, predicted by this entry's own text. The shipped #241 conversions are UNAFFECTED (495 removals ≈ censused 486 + space family; the SEEN population is closed; golden green stands). Residual conversion + generator fix + enforcement-at-the-seam = **releases#243** (BACKLOG, operator triages); delivery.rs:149/313 are post-cut MINTS relative to the census sha (todlando's own, settled attribution), deliberately outside #243's census-mechanism scope — and ALREADY CONVERTED: the fix rode his breadcrumb branch (`60a12056`) into the r4 head and shipped IN-TAG (todlando flagged the stale "his thin lane converts post-cut" claim 2026-08-30; re-measured — zero bare TOKEN `eprintln!` in delivery.rs at both `d931dd63` and origin/main). No lane is owed for it. Re-runnable meter `EMISSION-RESIDUAL-CENSUS-METER.py` (repo root, untracked; version-control rides #243's lane). **Common-word matcher RULED at this sweep (discharges the "decide" clause below):** the four common-word consumers (`IDLE`/`DISPATCH`/`BUSY`/`BOUND` substring predicates) get a SEPARATE hertz test-side rider — anchored token matching is consumer-predicate work, NOT folded into #243 (keeps #243 product-scoped) and not claimed closed by one-write emission; lane-link when hertz's spool drains. - **Closes when:** releases#243's residual conversion + generator fix land and a re-census at that sha reads zero shipping residue under both delimiter forms. **Size:** product lane complete elsewhere; register follow-through small. ### IR-70 — a hand-built `IoBus` silently omitted later sinks while every gate stayed green - **Status:** OPEN, remedy unscheduled; the v0.65.0 respin fixed the witnessed call site on PR #173. This entry owns the recurrence class, not that shipped correction. · **Origin:** releases#234, commit `c5459795167`, CONDUIT #236 respin. - **Mechanism:** `publish_commune_io` constructed `IoBus` itself and registered only the sink it knew. `default_bus` already existed as the assembly point and its module contract explicitly says emitters must know only `IoBus::publish`, so adding a later sink costs one registration rather than an emitter sweep. The hand-built publisher recreated exactly the drift that contract warned against: `COMMUNE` and `COMMUNE_FAIL` reached the old sink but never the adapter log, leaving `spt api io-events` permanently short on two documented kinds. - **Why the complete battery was green:** the e2e was vacuous on the broken kinds; units synthesized rows without traversing `publish_commune_io`; and traceability checked attached tags, not whether the tagged path exercised the real publisher. Three green instruments shared one blind seam. The respin routed the site through `crate::iobus::default_bus`, and its source comment now records the failure shape. - **Durable remedy direction (todlando mechanism, not scheduled):** enforce the assembly point so the next hand-built bus is impossible rather than found — make production publishers obtain the composed bus through one construction API, and gate the real publish path for every documented kind. A search or comment is not enforcement; another emitter can satisfy both while rebuilding a partial sink list. - **Kin:** [[IR-39]] (a green fixture never reached the missing dependency), [[IR-37]] (traceability tags prove coverage bookkeeping, not behavioral truth), [[IR-58]] (a hand-built population returns an orderly but incomplete answer). - **Ripe when:** the next `IoBus` construction/API touch, or a new sink registration. **Size:** small-to-medium assembly-point enforcement plus a real-path population test. ### IR-71 — controller-seat release has no persisted breadcrumb, so tests cannot distinguish propagation lag from a missing detach - **Status:** OPEN, observability gap; no remedy scheduled. · **Origin:** CONDUIT #236 r3 `er_brief_once_per_session_e2e` intermittent, classified test-side and fixed on PR #174. …