### IR-26 — POOL-OWNER claims authorize takeover from a DEAD holder, so releases#103's hazard reaches through the guard
- **Status:** OPEN for residual claim-time observability and stale-reader enforcement; the
…
- **RULING (doyle, 2026-08-04) — the claim path must run the same guard the build path runs, and a
…

### IR-27 — A junction-pooled rig is TWO objects and teardown only ever removes one
- **Status:** open, found in the wild 2026-08-04 · **Origin:** hertz's 44-tree worktree sweep
  (IR-26 follow-on 3) · **Cross-ref:** [[IR-14]] (unclaimed pools), [[worktree-target-junction]]
- **What/why:** a rig built as `worktree\target -> junction -> .worktrees\<pool>` has its build cache
  in a directory that is NOT the worktree and NOT in `git worktree list`. `git worktree remove` deletes
  the junction and reports success; the pool survives with zero inbound links and nothing naming it.
  Measured on this box: reaping `golden-render` and `w4-cli-doc` the obvious way would have reclaimed
  ~26 MB of worktree and stranded **14.17 GB** of pool (`gate-target-render` 6,265,448,382 B +
  `gate-target-w4doc` 7,907,558,098 B). Neither pool appears in any worktree listing.
- **The second shape, same mechanism, already realised:** `.worktrees\gate-target` was found at
  **0 files / 0 bytes with FOUR live inbound junctions** (assembly-doorbell, doorbell-w1/w2/w3). Someone
  had already reaped that pool and left four dangling-but-valid links behind. So the defect runs both
  ways: remove the worktree and the pool is orphaned; remove the pool and the links are orphaned.
  Either half alone leaves a lie on disk.
- **Why it is not just "be careful":** the classification step people already know
  (`Get-Item -Force` OUTBOUND, INBOUND reparse sweep) tells you HOW to delete an object you have
  already decided to delete. It does not tell you that a second object exists. The missing thing is an
  enumeration that reaches pools no worktree names.
- **Remedy shape (CORRECTED by builder retraction, 2026-08-04 — the enumeration already exists and
  shipped):** `xtask pool-sweep` (`c6515f1`, `REQ-POOL-GC-ORPHAN-RECLAIM`, ancestor of `b7b00c3` by
  merge-base) walks the root for dirs AND links, counts inbound links over the whole sweep before
  forming a verdict, classifies InUse/Owned/Orphaned, and reaps orphans on `--reap`. The gap is not
  detection, it is TIMING: a junction-pooled tree's pool is `Owned` and not reclaimable right up to
  the moment its worktree is removed, and `Orphaned` only after — so the reclaim always lands in a
  LATER sweep, and nothing triggers one. `gate-target` (0 bytes, four dangling inbound links) is a
  completed instance of that deferral. Remedy is a post-teardown pass or a teardown that runs the
  sweep itself, not new enumeration. (An earlier draft of this entry proposed building the
  enumeration; retracted by its author before ripening — the tool refuting it was one run away.)
- **Ripe when:** next CI/infra batch. **Size:** small (one enumeration + report, no new policy).
- **Discipline this cost, stated so it is not re-learned:** teardown must be TWO EXPLICIT STEPS per
  junction-pooled tree — junction deleted AS A LINK (`Directory.Delete(path, recursive: false)`), then
  the pool AS A TREE after an inbound sweep confirms it is linkless. Executed that way on 2026-08-04:
  28 worktrees, 4 pools, 0 skipped, 0 pinned, 17.04 GiB measured on a box with concurrent writers.

### IR-28 — A wave-gap rider is visible to the request board and invisible to a milestone-narrative notes pass
- **Status:** BUILT 2026-08-29 — PR #176 (`880b3b9c`, landed on main via `37368263`).
  · **Origin:** deployah, v0.53.0 release close 2026-08-04.
- **What/why:** the v0.53.0 changelog omitted `184f2ac` (the releases#125 two-core CPU-burn fix, a
  wave-gap rider that rode the commit range but was never LOCKSMITH scope) while the alchemy release
  verb promoted #125 to DONE and named it publicly as shipped — two published surfaces contradicting
  each other until the post-publish docs-only repair (`9841592`). The rule was already right (the
  runbook audits the changelog against the COMMIT RANGE); the EXECUTION missed it, because a notes
  pass written from the milestone narrative never enumerates the range. The mechanism, not the
  incident: any rider is board-visible and narrative-invisible.
- **Built evidence:** `docs/RELEASE-RUNBOOK.md` now requires a mechanical `vPREV..HEAD`
  user-facing commit list, a changelog match beside every row, and an explicit accounting of every
  unmatched row before the golden run. The repair precedent remains docs-only amend +
  `gh release edit`, never retag. PR #176 passed `traceable-reqs check`.

### IR-29 — twohost ladder: role A fires the done-barrier BEFORE its last cross-node rung, so the re-pull's serve window is won by timing, not guaranteed
- **Status:** OPEN for later serve-window/rung residuals; the original
  `test/twohost-serve-window` fix `17bbbd8` LANDED in v0.54.0, as recorded by IR-30.
  Stale authored-but-unlanded header corrected 2026-09-11; no new acceptance or margin
  measurement claimed. · **Origin:** golden
  30873007187 attempt 1 red, doyle timeline triage + hertz source diagnosis 2026-08-04.
- **SECOND FACE, measured 2026-08-24 (WAX-SEAL #21 W3 gate climb @ 035c3fe6, doyle):** the class
  recurs on a NEW rung, and this face is UNWINNABLE rather than racy. The W3 seal rung S1 mints
  on A ~0.3s before A's ladder completes (mint mono 80843ms, ladder end ~81150ms, walked from
  the capture), while the seal pump worker's cadence is 500ms — the pusher exits before its
  first eligible post-mint tick, so ZERO feed pushes ever fire (both logs hold zero seal-feed
  lines) and role B burns its full 900s window on "seal: A's record replicated into B's store".
  Full-re-presentation heals only while a pump is RESIDENT; the rig kills it. Product not
  implicated (local legs + design review all green at the sha). Dispatched to hertz 2026-08-24
  with two fix shapes (mint early with ~120 ticks of resident-pump margin, or a
  reverse-confirmation barrier on A's done-push); the climb re-runs on his fix. Lesson for
  future rungs, stated as construction: a rung whose delivery is CADENCED must not sit inside
  the terminal margin of the process that pushes it.
- **Mechanism (hertz falsified the gater's first spelling, kept because the correction is the
  entry):** NOT "B exits early" and NOT a missing barrier. B's contract (twohost.rs:1116-1121,
  "hold until A finishes its side — done-file as the ladder's completion barrier") is right and B
  obeys it. A BREAKS it: A pushes done.txt (:1819-1832, payload literally "ladder complete on A")
  then runs the ENTIRE leg-D digest rung including the re-pull assert (:1959) before its own
  `stop.store` (:1966). B tears down exactly when A said it could; the re-pull then races B's
  post-signal teardown. The panic's hint text ("may be running a version without cross-node
  digest") is pre-authored and was NOT evidence of version skew.
- **Margin series, six draws of one race (deployah, markers cited by TEXT and positive-controlled
  against a known draw before producing an unknown one):** golden 30860770146 +60s · a1 −0.6s
  (the RED) · a2 +59.4s · a3 +60s · a4 +59.59s · a5 +63.89s. BIMODAL, not drifting: greens
  cluster within seconds, one collapse through zero. A green does not mean the window got safer;
  sample count characterizes a bimodal race, not margin size — the slack is incidental, not
  designed. Local load on hfenduleam during A's leg D eats the margin directly (role A runs
  there; the done-file is already pushed), which is why builds hold through twohost legs.
- **⚠ THE SERIES IS CLOSED AT SIX DRAWS — ITS DERIVATION IS UNRECOVERABLE, AND NO SEVENTH NUMBER
  MAY BE ADDED (ruled by doyle 2026-08-05, at the tranche-2 golden).** Asked to extend it with a
  draw from run 30971976024, deployah positive-controlled the markers FIRST and the control
  REFUSED: grepping `margin|deadline|serve window|slack|headroom|budget` against a control run
  known to carry good twohost evidence (30940180764) returned ZERO. Source confirms it —
  **`margin` is not an emitted token anywhere**: absent from `.github/workflows/golden.yml`, and
  every `crates/` hit is unrelated (terminal right-margins in broker/resize tests,
  `ROUND_DRAIN_MARGIN` in `pump/mod.rs`). So the six figures were DERIVED from log timestamps
  against a bound that was never written down, by a measurer whose context has since been cleared;
  the gater who recorded them never held the formula either. **Consequence, stated so nobody
  re-derives it:** any new figure computed from these logs would be a DIFFERENT quantity wearing
  the same name, and would enter a series whose value is its bimodality — the one structure a
  mismatched sample corrupts invisibly. This run therefore gets a LABELLED HOLE, not a number.
  What IS reportable for it, with endpoints named rather than a name reused: **ladder span**, node
  start → `TWOHOST role B: ladder complete` = **183.50s** on the batch vs **259.21s** on the
  control. Marker parity established under an IDENTICAL expression on both sides (25 = 25, after a
  first pass that compared two different greps and would have read as parity by coincidence).
- **The fix this makes obvious:** the twohost margin must become an EMITTED token with its two
  events named at the emit site, so the next draw is read rather than reconstructed. A derived
  quantity whose formula lives only in a measurer's context is one context reset away from being
  unfalsifiable — which is exactly what happened here.
- **Fix shape (doyle-approved):** move the done-push block to AFTER leg D, immediately ahead of
  A's stop — one honest barrier made true, no second completion signal (a redundant pair is how
  the next ordering bug lands after the SECOND one). `int->REQ-REACH-1` travels with the block.
- **Cascade note, so a future triage does not count it:** in a1, twohost-b's gated-CLI red
  (twohost_cli.rs:189, 910s) was the CASCADE — role-A's gated driver step SKIPPED after the
  ladder death, so B waited for a row never produced. A red that postdates its carrier leg's
  failure carries zero information about its own subject.
- **Ripe when:** proving run at the next two-host window. **Size:** landed-sized already.

### IR-30 — GOLDEN 4b37512 (#145): five attempts, four distinct Windows victims, one sha — the random-victim family measured end to end, and the instruments it left behind
- **Status:** open for the FAMILY SIGHTINGS ONLY — the instrument lanes LANDED as planned with
  the next golden batches (measured 2026-08-25, doyle, `git merge-base --is-ancestor` + first
  tag: serve-window `17bbbd8`, selection probe `695398ba`, resume taxonomy `58337879` all in
  **v0.54.0** (USHER, merge `390204a3` et al.); attach-intent re-aim `37afa571` in **v0.55.0**).
  Any later record citing these as "authored-unlanded riders" (the v0.63.0 FIELD-SEAL plan did,
  carried forward from this ledger) is stale — this row is the correction. The #145 gate itself
  CONCLUDED GREEN attempt 5, main ff'd, tested==merged · **Origin:** doyle, night of 2026-08-04,
  run 30873007187 attempts 1-5.
- **The record:** four reds, four DIFFERENT daemon-spawning tests, Windows leg only, Linux green
  at the same sha every attempt: a1 `daemon::tests::a_tree_teardown_reaches_a_grandchild…`
  (10.225s full deadline, 2nd golden sighting — see [[IR-17]]'s updated sub-observation); a2
  `registry_lifecycle::multichunk_feed_applies_with_exactly_one_snapshot_write` (0-vs-1 at
  mono_ms 77, THIRD sighting of the 2026-07-22 seed; hertz source-named the window: converge
  polls rows landed at merge, assert reads `snapshot_writes` incremented in `write_snapshots`,
  unjoined-thread gap between — predicts under-count only, matching all sightings; quiet-arm
  control 40/40 PASS 0 leaky on a still box); a3 `brain_split::broker_survives_brain_kill…`
  ("supervisor did not respawn the brain", 32.8s window burn; characterization queued); a4
  `resume_no_control_steal_e2e::brain_respawn_keeps_every_session_controller…` — UNDER the
  ruled quiesce-partial window with a measured-clean box, and its panic NAMED A MECHANISM ITS
  OWN DATA CONTRADICTS (pre-authored Failure-A text; gained=[0,15,17] through ONE
  resume_sessions while a steal displaces the SET; session 0 already 4x behind BEFORE the
  window; the rig's child-liveness immunity was a COMMENT nothing measured). Every red
  lane-independent by per-row delta test run fresh each time, never transferred.
- **Instruments authored off it (all thin test/obs lanes off `11169c1`, compiled where stated;
  ALL LANDED — v0.54.0/v0.55.0, see Status):** hertz `test/twohost-serve-window` @`17bbbd8`
  ([[IR-29]]); hertz grandchild SELECTION probe (+166/-8 daemon.rs test-mod: IsProcessInJob at
  selection time — decisive H1/H2 splitter, birth-stamp one-directional, image, same-snapshot
  match COUNT; compiled + deliberate-break positive control); hertz `test/resume-steal-taxonomy`
  (+109/-6: producer counter `Broker::session_output_seq` bracketing the consumer window,
  authenticated child pin at t1 BEFORE teardown — read at assert time would convict the rig of
  its own cleanup — three-way verdict PRECONDITION / measured-Failure-A-with-producer-story /
  absent-producer-is-its-own-story); todlando `obs/resume-attach-intent` @`9c9e6c5`
  — **a DEAD-PATH emit that never fired in production; removed 2026-08-04.** The
  `RESUME_ATTACH_INTENT` breadcrumb sat in `resume_sessions`, which has had NO production
  caller since `03c7109` (2026-07-09): the daemon's respawn path is `run_brain` ->
  `resume_session_cursors`, cursor-only, no attach. Its absence from a field log therefore read
  as "no resume happened" when it meant "uncalled function" — a clean-zero manufactory aimed at
  the very #123 hunt it was built to serve. **Do not hunt for this token.** The instrument now
  lives at the choosers the daemon actually executes, as `ATTACH_INTENT_CHOSEN` with a distinct
  `site=` per chooser (`gap_resume` | `serve_request` | `shell_channel`), carrying the emit
  discipline this one always had — intent bound once, logged and passed from that same binding,
  wildcard-free label. No REQ, per the OBS-rider precedent.
  - _Corrected 2026-08-04 (todlando, in the re-aim rider lane): this row previously described
    the breadcrumb as a live instrument — "intent bound once, logged and passed from the same
    binding, per-call epoch makes set-vs-one readable off the log". That sentence was true
    about the emit's CONSTRUCTION and false about its REACH, and a reader consulting this
    register during the #123 hunt would have been sent after a token that cannot fire.
    Replaced rather than annotated, per the register's correction convention; the superseded
    wording lives in git._
- **Rulings that outlive the night:** a green retires NO intermittent row — grandchild and the
  a4 row are INSTRUMENTED-AWAITING-FIRE, the next occurrence carries its own verdict; the
  environmental family's leg 3 (runner off the fleet host) stays operator-ruled NON-OPTION
  ("stop proposing it") — sightings accumulate in the family record, evidence files itself,
  re-asking is direction; the quiesce-partial window is the sanctioned tool and it WORKED as a
  discriminator (a4's red under quiesce is what forced the rig-soundness finding).
- **Instrument notes minted on the way, cheap to lose:** (a) `gh run view --log` refuses for a
  COMPLETED attempt while any later attempt is live (gates on the RUN) — recover per-job with
  `gh api repos/<o>/<r>/actions/jobs/<id>/logs`; (b) a process-census RESIDENT COUNT is not
  trendable (23→17→15 in 90s of inbox-poll CLI churn) — the CLASSIFICATION is the measurement,
  the count is noise; (c) nextest's per-run LEAKY count is a free process-leakage series already
  in every log (a1=12/a3=10/a4=13, and the multichunk row alone leaks 0/40 — the leaks are the
  row's NEIGHBOURS); (d) diagnostic-token greps derive from the FAILING FRAME's own emit sites,
  never from the register entry discussing the symptom — the gater's own
  `REAP_JOB_TERMINATE_FAIL` zero over a path that emits `SERVICE_TREE_KILL_INCOMPLETE` was VOID,
  and the emit sites document their own vocabulary (tree_kill_incomplete_line's doc names its
  grep-partner); (e) **"golden green ⇒ box free" is FALSE — the ff-push that concludes a golden
  STARTS the automatic post-merge ci run on the same box** (hertz, measured to the second:
  Runner.Worker up 00:13:02 local = run 30886843672 job start 07:13:02Z, ~2min after the ff), so
  the box empties after the POST-MERGE run, not after the golden; the box has a fourth actor no
  agent steps off, woken by every main push (todlando's spelling), and post-golden sequencing
  must gate on `gh run view --json jobs` of the post-merge run before any timing-sensitive work.
- **Ripe when:** ~~instrument lanes land~~ (DONE, v0.54.0/v0.55.0); family sightings stay until
  the family record closes them — the entry now waits on FIRES, not landings. **Size:** nothing
  left to build; the next family sighting carries its own verdict via the landed instruments.
- **LINUX-FACE SIGHTING + ITS RESOLUTION (doyle, v0.63.0 FIELD-SEAL goldens r1-r3 + proof runs,
  2026-08-25 — the family's first measured MECHANISM, and it is environmental-amplifier ×
  latent-test-defect, not a product fault):** three goldens, three DISTINCT kitsubito victims,
  8/9 green each, victims migrating across same-sha reruns (r2/r3), every red a LONG death
  (9.9s/59.4s/62.7s) of a fast cell — the family signature on the OTHER OS. Root-caused to ONE
  window whose WIDTH varies with load: the brain's `spawn_session_pid` Spawned-wait
  consumes-and-discards output racing ahead of the reply (KNOWN-HAZARDS 6.9, same-session face,
  amended at `dbe3daad`); the broker execs the PTY child ~2ms BEFORE writing `Spawned`, so a
  fast first chunk can be eaten. Under kitsubito's then-active kernel-audit backpressure
  (see the kitsubito-audit entry below) the broker DISPATCH thread could stall arbitrarily in
  that gap — the ~2ms window stretched to seconds, swallowing ANY marker prefix of ANY
  spawn-wait test: random victims, long deaths, spawn-intensity × serialization scaling
  (deployah's measured pair), migration across reruns. Box remediation narrowed the window back
  to ~2ms, leaving exactly one knife-edge victim (a first-chunk needle, near-deterministic red,
  62.7s natural-life death), fixed test-side in `dbe3daad` (v0.63.0's head). Full RCA + the
  observer-effect instrument record: releases#225 comments 5417343026/5418844404.
  **Standing lesson for the family:** an environmental slowdown is an accidental mitigation —
  REMEDIATING a box can EXPOSE latent knife-edge races (the storm had hidden this one for
  releases). And a "random victim family" should be tested against ONE window with
  load-dependent width before positing per-victim mechanisms. The Windows face above remains
  open on its own instruments; the two faces now have one shared candidate SHAPE (a race window
  amplified by box load) with different windows.
- **Status:** open · **Origin:** measured box event, HFENDULEAM 2026-08-04 ~05:00 local, during
  USHER lane concurrency (hertz mechanism statement + both agents' reclaim arithmetic).
- **What/why:** the box hit **0.00 bytes free** mid-build. Failure signatures it manufactured
  look like toolchain or code defects, not disk: `rustc-LLVM ERROR: IO failure on output stream:
  no space on device`, `LNK1318: Unexpected PDB error; LIMIT (12)`, `LNK1108: cannot write file`
  — a red wearing a linker's face (doyle's U2 gate rig ate exactly this; verdict legs already
  green survived, the suite leg had to be re-run). Contributions measured, not inferred: hertz
  ~70 GB across four lane targets (er-seams **42.66 GB** cold `--workspace --tests`,
  selection-probe 25.80, poolowner 1.03, ci-riders 0.91), doyle gate rig 15 GB cold full build.
  Reclaim arithmetic reconciles both and neither alone: 0.00 → 25.47 GB (hertz reaps
  selection-probe) → ~40 GB (doyle reaps rig). **The mechanism (hertz, ruled register-worthy):
  every isolated lane worktree carries its OWN `target/`, so disk cost is multiplied by lane
  count, while pool-claim — built to arbitrate a SHARED pool — sees none of it; a claim on
  main's pool is ceremonial for a lane that never writes there. The tool we use to reason about
  build-cache contention cannot see the resource that actually ran out.** Eight-plus worktrees
  at 25–43 GB per cold full build is the shape of the next occurrence, and it will not announce
  itself through pool-claim. Adjacent discipline failure the same night, named so the entry
  carries it: a gater firing a cold full-workspace rig into a window with two live builder lanes
  is the pre-flight question-1 failure (right-size the run) — targeted legs and warm pools
  first.
- **Remedy shape (sketch, not ruled):** (a) a box-level free-space floor as a RIG STEP at lane
  start — the claim verb is the natural seat (print box free + du of known lane targets at
  `pool-claim`, warn under a floor); kin to the CI-side `REQ-CI-FREE-SPACE-PREFLIGHT` (IR-1's
  companion fix), which covers runners but not agent lane rigs; (b) teardown-on-gate-close is
  already a rig step (the gate-target-disposal rule) — the gap is the AGGREGATE view across
  lanes nobody owns; (c) possibly a `pool-census` xtask verb listing every `.worktrees/*/target`
  with sizes, so the sweep is one command instead of a du walk each agent re-derives.
- **Ripe when:** next CI/rig-touching wave, or the next ENOSPC-signature red — whichever first.
- **Size:** small-medium (claim-verb print + floor; census verb optional).
- **Field addendum (2026-08-04 second event, same day filed — ripeness condition met):** the box
  fell under the CI runner's 32 GiB free-space floor twice more (12:31 main @9d65e65 docs-only,
  12:50 PR core#144 @b110bc8) while todlando's F-lane built. Both Windows unit legs REFUSED with
  `RESOURCE=disk drive=C:\ free_bytes=…` — the `REQ-CI-FREE-SPACE-PREFLIGHT` floor did exactly its
  job: a docs-only main red named the resource instead of wearing a linker's face, and triage was
  one log read instead of an RCA. That is the instrument's first field catch; the CI side of this
  entry is PROVEN. The agent-lane side stays open: local trough measured 8.8 GB free mid-F-lane.
  Reclaim, measured before/after per the teardown rule: doyle reaped gated u1+u2 lane targets
  (POOL-OWNER claims verified own+dead-holder, inbound reparse sweep clean, worktrees kept)
  8.8 → 59.5 GB (+50.7); hertz reaped er-seams target (pool-release first, same discipline)
  59.46 → 101.16 GB (+42.66). Refined mechanism statement (hertz, this event): the disk floor is a
  per-BOX resource our per-POOL instrument is structurally blind to — pool-claim answers a
  question about contention that is not the question the box ran out of.
- **AXIS ADDENDUM (deployah, golden 30928816784 / USHER `fc7fad1`, 2026-08-04) — one floor reading
  is a SNAPSHOT, and the swing is bigger than the margin you fire on.** Two facts this entry's
  remedy (a) has to be built against, both measured rather than reasoned:
  (1) **A pre-fire PROCESS census cannot see the floor at all.** Mine came back clean minutes before
  the run — zero test-path `spt.exe` residents, zero `cargo`/`rustc`/`link`/`cl` — and both Windows
  legs then died in the disk preflight (`drive=C:\ free_bytes=26099576832 floor_bytes=34359738368`,
  `RESOURCE=disk`, exit 1) with a 128-line log carrying ZERO `Compiling`/`PASS`/`FAIL`/`Summary`
  lines: no test signal, and the merge chain never indicted. Both readings were TRUE at the same
  instant — the gater's finished assembly gates were sitting on disk as a DIRECTORY, not running as
  a process. A process-axis probe is blind to a finished build's cost by construction; "re-check
  closer to the fire" would have changed nothing, because the axis was never read.
  (2) **The floor number itself moves by tens of GB inside one run window.** Same box, same drive,
  same run, pulled from its own logs: `16:22:55` test-Windows free=26099576832 REFUSED · `16:23:07`
  n1-gate-Windows free=26096607232 REFUSED · `16:46:54` twohost-a free=71033049088 PASSED and then
  ran 11 minutes to success. ~45 GB returned with NO deliberate teardown, and my own reading at
  17:13:45Z was 61352714240 — ~10 GB BELOW what twohost-a saw 27 minutes earlier. The observed swing
  amplitude EXCEEDED the margin I was about to fire on (25.14 GiB).
  So the rule remedy (a) must encode: measure BOTH axes (process residents AND free space against
  the workflow's own 32 GiB floor), and reclaim until the margin exceeds the observed SWING, not one
  sample. Triage corollary, equally load-bearing: twohost-a runs the same preflight on the same C:
  and PASSED, so a preflight refusal is a threshold event on a moving number — never evidence the
  box cannot run the work, and never by itself a reason to indict a merge chain.
- **THIRD ADDENDUM (deployah, v0.54.0 cut, 2026-08-04) — the sweep answers "0 B reclaimable"
  TRUTHFULLY on a box that cannot run its own work, because the reclaimable population and the
  owned-lane population are DISJOINT.** This hazard blocked a release twice before it was seen.
  Both Windows legs at the shipped sha `86f0d84` refused at the guard before compiling anything —
  `ci.yml` at `free_bytes=28167569408` (26.2 GiB) and `release.yml` at `27690885120` (25.8 GiB),
  both against `floor_bytes=34359738368`. `assemble` skipped in consequence, so no draft release
  existed: the release was hard-blocked on disk, not on code. Neither leg produced a test verdict,
  so both are LABELLED HOLES, not reds (ruled recorded-and-proceed by doyle, the shipped-sha delta
  being 5 files and zero `.rs`).
  **The finding is not the disk.** `xtask pool-sweep --root .worktrees` reported, correctly,
  `total 66.43 GB across 3 pool(s); 0 B reclaimable in this sweep's scope` while the box sat ~6 GB
  under its own floor. The sweep is behaving as designed — it refuses to reap owned, live lanes.
  But the floor reasons over an AGGREGATE the sweep is forbidden to touch, so the designed
  instrument, run at the exact moment of refusal, tells an operator there is nothing to reclaim.
  That is true and useless. The gap between "the sweep is correct" and "the box can run work" is
  the defect; it is not fixed by making the sweep more aggressive.
  **Aggregate measured under `.worktrees`** (real target bytes, junction-classified first): 87.79 GB
  across 9 lanes — 2.7x the entire 32 GiB floor. Registered pools: `w1t2-relink-force` 54.67 GB,
  `obs-resume-attach-intent` 10.18, `w1t2-subnet-status` 1.58. Carrying targets the sweep does not
  count as claimed pools: `hertz-teardown-bound` 11.25, `hertz-liveresolve-diag` 4.83,
  `hertz-psyche-bound` 4.19, `hertz-poolowner` 1.03, `hertz-ci-riders` 0.91.
  **The 54.67 GB single lane is NOT waste** (doyle's classification, ratified at this filing): a
  verb lane at that size is workspace-all-targets e2e cost. No lane is misbehaving. That is what
  makes this structural rather than a cleanup task — every lane is individually justified and the
  sum still exceeds the floor.
  **Reclaim taken, and its boundary.** 82.12 GB, from `spt-core/target` — the release driver's OWN
  main-checkout pool, NOT a lane; free 23.23 → 105.34 GB. Classified before removal per the
  teardown rule: OUTBOUND `Get-Item -Force` reported a real directory rather than a reparse point,
  the INBOUND sweep found zero reparse points aimed at it, `CARGO_TARGET_DIR` was unset (no env
  aliasing), the target SUBTREE only was reaped, both sides measured.
  **Snapshot behavior reproduced inside this measurement window**, corroborating the axis addendum
  above at a smaller amplitude: free read 25.49 GB when first measured and 23.23 GB at the reap
  minutes later — it drifted 2.26 GB DOWNWARD while the operator was deciding what to do about it.
  **Priced side effect, for the next reader:** reaping the main pool took the prebuilt `xtask` with
  it, so the next lane claim rebuilds it first — the lane-check shortcut is cold until then. It cost
  a 2m11s cold rebuild inside this release's own publish step.
  **What this does NOT license:** reaping another agent's owned lane to clear a floor. The sweep's
  refusal is correct and stays. What is missing is an AGGREGATE-AWARE signal — the box knowing its
  lanes sum past the floor *before* a run is dispatched into a guard that will decline it.
- **FOURTH ADDENDUM (doyle, 2026-08-04 late evening — fourth event in one day, and the first
  RULING on this entry).** C: hit **0.44 GB free** during doyle's lane-2 stack gate and todlando's
  re-aim leg set. Signatures manufactured this time, all initially read as something else:
  `os error 112` mid-rlib-archive surfacing as xtask "building spt failed" (exit 101); a
  servicehost force-kill unit red at a sha gated GREEN on the same rig an hour earlier; todlando's
  6-of-7 leg table red with `LNK1318` while only traceable-reqs survived. Both agents' verdicts
  from the window were VOIDED and re-run, not re-read.
  **Discriminator correction (hertz, ratified at this filing):** "treqs alone survives" is a
  POSITIVE TELL, never a clearing test — a full disk reds BEFORE any link step (rustc writing
  rlibs), and treqs can red for its own reasons; signature absence says NOTHING. The only
  falsifier for "this red was the disk" is free space AT RUN TIME, and no log on the box recorded
  it, which made every red from the window unanswerable after the fact.
  **RULING (doyle):** every rig/gate script records `FREE-AT-START` / `FREE-AT-END` in its own
  SUMMARY — one line each, the datum that makes a disk confound answerable post-hoc. Effective
  immediately for hand-authored rigs; hertz builds it into the shared rig harness at next touch
  (assigned, not unasked). This is remedy (a) narrowed to its cheapest load-bearing slice.
  **Reclaim, all FS-delta-measured:** todlando +59.4 GB (obs-resume-attach-intent 8.56 +
  w1t2-relink-force 50.83; 0.44 → 59.83), hertz +1.79 GB (ci-riders + poolowner; sum-of-lengths
  said 1.94, the FS delta governs; 59.09 → 60.87), doyle +38.8 GB (w1t2-subnet-status +
  w1t2-perch-gc + w1t3-node-verb targets; 60.75 → 99.54). Full discipline each: outbound
  classification, inbound reparse sweep (zero), CARGO_TARGET_DIR confirmed unset, subtree-only.
  **Mechanism sharpened by this event:** the standing swing IS the finished-lane population —
  ~110 GB of pools belonging to lanes already GATED AND PUSHED, held for hours because disposal
  fires at GATE close (a rig step) while nothing fires at LANE finish; a pushed lane awaiting
  assembly holds its pool invisibly. Corollary corrections carried: todlando withdrew his
  name-based pool census (10x off; ancestry, not directory names, classifies a pool as closed),
  and hertz-selection-probe's worktree removal REFUSED Permission denied — IR-38's second holder
  class recurring, left for retry rather than forced.

- **FIFTH ADDENDUM (deployah, v0.63.0 FIELD-SEAL golden, 2026-08-25) — SCOPED DELIBERATELY TO ONE
  CONSEQUENCE: reaping a pool UNCLAIMS its tree, and the next builder meets a refusal that is the
  rule working.** (The disk-floor mechanism from the same event is doyle's to file at his
  release-close sweep — one voice each, by division agreed in-window. This addendum stops at the
  pool-claim consequence and deliberately does not restate the floor finding.)
  Five FIELD-SEAL lane pools were reaped to clear the golden floor — gate rig `gate-222-ca30a79e`
  plus lanes `fix-222`, `w2-seal-ux`, `w3-ingest`, `w4-exit-subject`; **148.48 GB measured by FS
  delta**, free 1.37 → 149.84 GB, worktree checkouts kept, `main/target` untouched by ruling.
  **The consequence to record:** `POOL-OWNER.json` lives INSIDE `target/`, so reaping the subtree
  takes the claim with it. Those five trees are now **UNCLAIMED — which is fresh-not-foreign**, a
  different state from the `SPT_POOL_FOREIGN` refusal. Whoever resumes one of those lanes (a hertz
  fixup, a golden-red rebuild) must run `cargo run -p xtask -- pool-claim --pool <dir> --label
  <lane>` **from that worktree** before the first build, or `crates/spt-store/build.rs` refuses.
  **A refusal there is the rule working, not a defect** — filed precisely so a later reader does
  not open an issue against the build script for behaving correctly. Naming it costs one line;
  the alternative is an RCA against our own guard.
  **Prediction-vs-meter, corroborating hertz's fourth-addendum note at ~75x its scale:** pre-reap
  sum-of-lengths sizing predicted 163.9 GB; the FS delta paid 148.48 GB, a 15.4 GB shortfall left
  UNEXPLAINED here rather than rationalized (allocation granularity, sparse/compressed extents and
  concurrent writes all sit between the two meters). **The FS delta governs** — hertz ruled this at
  1.94-vs-actual and it holds at three digits. Report the meter, never the estimate that agreed
  with your plan.
  **Discipline executed, for the audit trail:** outbound classification re-read AT REAP TIME (all
  five real dirs, zero LinkType); inbound sweep over **2854** reparse points under `projects\`
  found zero aimed at any victim; `CARGO_TARGET_DIR` confirmed empty in process, **Machine and
  User** scope (the arm that leaves no directory entry to notice afterwards); process census
  RE-RUN at reap time rather than carried from a peer's snapshot — zero builders, zero processes
  imaged out of a victim pool, both live `spt` images resolving to the installed path. The peer's
  snapshot proved correct; it was re-run because a snapshot is not a standing property, which is
  the reason it was offered with that caveat.

### IR-32 — Docs-drift gate blesses its own gen: an empty-emitting producer agrees with itself perfectly
- **Status:** open · **Origin:** todlando mid-lane stop-and-report, U1 (#144) 2026-08-04. Filed by
  the builder to the gater deliberately — register shape is doyle's to own.
- **What/why:** with a defective binary in the tree (stack-overflowed before reaching its own
  code, empty stdout, non-fatal to the generator), `cargo run -p xtask -- gen` wrote
  `docs-site/src/cli/reference.md` reduced to EIGHT lines — title, do-not-edit banner, empty code
  fence — deleting 3193 lines of published CLI reference. `xtask check` then exited 0, because
  the drift gate compares what the binary emits NOW against what the file holds, and gen had just
  overwritten the file with exactly that emit. **A producer that emits nothing agrees with itself
  perfectly.** Caught only because the builder grepped the regenerated page for his new flag
  names and treated the clean zero as suspicious ([[zero-match-filter-reads-as-absent]] shape);
  the gate itself would never have said a word, and the gutted public reference ships green.
  The mechanism generalizes past the stack overflow that exposed it: ANY failure mode that makes
  `spt --help` produce empty stdout while exiting non-fatally to the generator gets the same
  green. Kin to [[cli-command-docs-drift]] (the gate this defeats) — the gate detects DRIFT
  between binary and page, and is structurally blind to a page just regenerated from a broken
  binary.
- **Remedy shape (builder's sketch, sound; not yet ruled on seat):** a floor in `xtask gen` —
  refuse to write a page whose help block is empty, or whose output is implausibly shorter than
  the file it replaces — so the generator fails loudly instead of producing a stub the gate
  blesses. Gen is the right seat: check runs in CI on a fresh emit too, so a check-side floor
  alone still lets a local gen gut the working tree.
- **Ripe when:** next docs-tooling or xtask-touching lane; SOONER if any lane regenerates the CLI
  reference before the floor exists (a gate on that lane must assert page LENGTH, not gen's exit
  code, until this is built).
- **Size:** small (one refusal + a length-plausibility floor in gen).

- **Kin instance 2026-09-11 (hertz, #304 lane, caught before launch):** the RUN expression for the
  spt-daemon lib producer was still the 15-term webserve list after six #297 cases had been admitted
  and inventoried at 21 terms. It would have executed 15 and reported against a 21-term inventory —
  a subset quietly narrower than the thing it claims to discharge, with a count that reads fine.
  Rule: a run filter is diffed TERM-FOR-TERM against the inventory it discharges before launch; a
  matching case count is not that check.

### IR-33 — Debug-build clap Command tree runs near the main-thread stack ceiling; the margin is THREE net new args, bisected at `8f291e1` (the original ~6 was measured on U1's tree and is superseded)
- **Status:** OPEN for acceptance/margin reconciliation. Current source at `e5a2fed9` runs
  the CLI on an owned 16 MiB thread stack and includes `cli_stack_smoke`; the three-argument
  ceiling below is a historical measurement at `8f291e1`, NOT today's measured margin.
  Do not redispatch an already-present sized-stack implementation. No fresh debug-run
  acceptance is claimed by this source read (2026-09-11). · **Origin:** todlando U1 (#144)
  2026-08-04, delta-tested mid-lane.
- **What/why:** eight extra hidden bool args across the five knock seats grew the derive-built
  Command tree past what the debug binary's main thread stack can construct: EVERY invocation
  (`spt --version` included) died with `thread 'main' has overflowed its stack`, exit
  -1073741571, before reaching any of its own code. Delta-tested, not assumed: the same command
  on the main-pool binary from main printed normally. U1 repaired its own trigger (raw-argv
  pre-scan for retired flags before clap parses; lane ends net +2 args) — but the CEILING
  remains: the tree is now close enough that a handful of net new arguments in a debug build
  reproduce a total binary outage — **and the handful is THREE, not six; see the correction
  below before planning against this entry.** **#5's verb-surface rework is the next lane that adds
  arguments and it is much bigger than U1** — this entry exists so #5 is planned knowing the
  margin, not discovering it. Note the failure's face: it presents as a broken binary, and via
  [[IR-32]] it presents as a silently gutted docs page — neither names the stack.
- **CORRECTION — the margin is THREE, bisected at `8f291e1` (todlando's U3 lane
  `build/usher-u3-verb-surface`, own pool, debug profile; filed by deployah 2026-08-04).** The
  original ~6 was measured on U1's tree and was right when written; it is wrong now, and the
  difference is the difference between "plan carefully" and "one flag anywhere takes the binary
  down". N hidden bool args added to the ROOT `Cli` derive, tree restored from git between every
  row, `--version` as the invocation (it carries no work of its own, so whatever it costs IS tree
  construction):

      N=0  exit 0                OK  (control — unmodified lane binary answers `spt 0.53.0`)
      N=1  exit 0                OK
      N=2  exit 0                OK
      N=3  exit -1073741571      STACK-OVERFLOW
      N=4 / N=6 / N=8            STACK-OVERFLOW

  PLACEMENT DIFFERENTIAL, run because #5 adds args at `EndpointCmd` seats rather than at the root
  and a root-only number could have measured the wrong thing: same N injected inside a NESTED
  endpoint seat gives `SEAT N=2` OK, `SEAT N=3` STACK-OVERFLOW. **Identical ceiling — placement does
  not move it**, so three is the number for the shape #5 actually builds. (Rig hazard worth keeping:
  the first seat attempt produced a COMPILE error, E0027, because the dispatch destructures that
  variant exhaustively — taken at face value it would have read as "the seat is fine". Both rows
  above are from the fixed rig.) CONSEQUENCE FOR #5: the ratified MIN spelling ends net +2, i.e. it
  would have shipped with ONE argument of headroom, and any later lane adding a single flag anywhere
  in the tree would then take the whole binary down, `--version` included. Remedy (b) below stops
  being "buys headroom" and becomes the precondition for #5 shipping safely.
- **Remedy shape (sketch, not ruled):** (a) cheapest tooth — a debug-build smoke that runs
  `spt --help` and asserts non-empty stdout + exit 0, which also backstops IR-32's trigger;
  (b) raise the main thread stack for the binary (build config), buying headroom without
  restructuring; (c) structural — box/flatten the derive tree so construction cost stops scaling
  with arg count. (a) is a rider candidate for any lane; (b)/(c) want a real measurement of
  where the ceiling sits before choosing.
- **Ripe when:** #5 (U3 verb surface) PLANNING — this is a planning input, not just a build item;
  the smoke tooth (a) is ripe for the next CI-touching lane regardless.
- **Size:** small for (a); medium for (b)/(c) with the measurement.

### IR-34 — nextest LEAK flag on the zombie-fixture row is dominant-but-intermittent (19/20 measured); any gate reading it as a signal flaps
- **Status:** open · **Origin:** doyle #142 F-lane gate 2026-08-04 (first sighting in a gate run);
  characterized same day by hertz from retained logs, ownership falsified by todlando.
- **What/why:** `broker::tests::windows_session_is_zombie_sees_a_handle_held_corpse_as_dead` (the
  ADR-0041 zombie-detection fixture, whose subject is a corpse process kept alive-looking by a HELD
  HANDLE) flags nextest LEAK on most draws but not all — measured 19 LEAK of 20 on a tree carrying
  no #142 content (`test/grandchild-selection-probe` @`695398b`, based on `4b37512`: lib arm 10/10
  LEAK across 822-test runs; full-suite arm 9/10 across 1044-test runs). The single clean PASS
  kills "intrinsic therefore always": leakiness is DOMINANT BUT INTERMITTENT. Consequences:
  (1) a gate or reader that treats this row's LEAK as a defect signal flaps at roughly 1 in 20;
  (2) one non-leaky run is NEVER evidence that something fixed it (kin:
  [[intermittent-green-is-zero-information]]); (3) the verdict method that closed it is the
  template — two independent legs, neither load-bearing alone: the suspect lane's diff grepped
  zero hits on the row's subject (zombie / handle_held / OpenProcess / corpse), AND a 20-draw
  baseline on a tree predating the suspect change. This entry exists so the next gater who sees
  the flag reads one register line instead of running that RCA cold.
- **Remedy shape (sketch, not ruled):** annotate the row as expected-leak in nextest config
  (per-test `leak-timeout` override or documented allowlist) so the flag stops presenting as
  signal; alternatively a fixture-side close of the held handle on the clean path if ADR-0041's
  arrangement permits — hertz's call, test/CI lane.
- **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.
- **Ripe when:** hertz's next nextest-config-touching lane; blocks nothing today.
- **Size:** small.

### IR-35 — hfenduleam Windows test-leg victim rate: one teardown/liveness family, measured at ~half of all executions
- **Status:** open · **Origin:** USHER #150 golden triage 2026-08-04 (doyle; all rates deployah-measured).
- **The numbers (15 golden runs 2026-08-02..08-04 + the USHER cycle, deduped on `(run, box,
  started_at)` — GitHub partial reruns COPY untouched jobs into the new attempt with their ORIGINAL
  `started_at` and carried conclusion, so a carried failure is the SAME observation; dedupe before
  any rate math):** Windows (hfenduleam) 13 red / 22 executions = 59% leg-red, splitting 10/22 = 45%
  test-victim + 3/22 infra (IR-31 class). Linux (kitsubito) 2/20 = 10%, 1 victim. Every victim-red
  leg had EXACTLY ONE victim (8/8 legs). Clean-cycle arithmetic ≈ 0.55 × 0.95 ≈ half — a golden
  cycle at these rates is a coin flip. knock145 (the previous green golden) took FIVE Windows
  executions to its green; USHER took four. **A both-green draw is a draw, not evidence the family
  closed.**
- **The family:** 11 victim legs, 8 distinct tests, ONE cluster — process teardown / kill-reach /
  respawn-controller survival, concentrated on hfenduleam. Per-victim dispositions live in the USHER
  #150 triage ledger (releases#150 record). The only surviving cross-sha EXACT repeat after source
  verification is `resume_no_control_steal_e2e` (:488, byte-identical @2138b16 + @4b37512) — and
  both its reds PREDATE the post-#145 producer-side instrumentation, so what repeats is an AMBIGUOUS
  observation (stolen controller vs starved child) twice; only a post-#145 red discriminates. The
  `a_tree_teardown` pair was a FALSE repeat — two mechanisms wearing one assert string (see
  FLAKE-LEDGER row; the counting lesson: assert-body identity must include the polled predicate's
  SUBJECT).
- **Off-CI discriminator (todlando 2026-08-04):** 0/400 (A 0/200 + B 0/200, interleaved,
  `--test-threads 1`, filters positive-controlled, by-path sweeps every iteration) on the warm
  d449ce5 pool UNDER live-fleet load (CPU 46-59%, 13-18 spt processes). Points the family at the
  RUNNER ENVIRONMENT rather than a product race any Windows box expresses — not exoneration (absence
  of reproduction is not proof of absence), but where the next hour goes. A-alone N=500 on the
  instrumented tree ran post-close (result on releases#150).
- **Remedy lanes already moving:** hertz 4-item test-rework package dispatched 2026-08-04 (psyche
  bound split, live_resolve rig instrumentation, green-capture probe profile, resident_service/
  teardown hardening); prod `wait_bounded` tree-kill-on-timeout filed to board as EVAL. This entry
  is the RATE's home — it leaves the register when the operator has ruled on the rate (accept vs
  hold-for-hertz) AND the hertz package has landed with a re-measured victim rate.
- **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); the rate re-measure rides that lane's landing.
- **Ripe when:** operator brief at USHER close (immediate); re-measure after the hertz package lands.
- **Size:** visibility entry + the re-measure; fix cost carried by the hertz package.

### IR-36 — `output_bounded` is a 51-copy clone estate with a named-but-empty shared home; hoist-and-delete wants its own lane
- **Status:** BUILT 2026-08-18 on KEYSTONE #182 hygiene lane. · **Origin:** hertz measurement
  2026-08-04 (at `7465ac1`, counted before listing, listed untruncated), during the USHER package
  item-2 sweep ruling; doyle ruled file-don't-sweep.
- **What/why:** 51 `fn output_bounded` definitions under `crates/spt/tests` — 50 per-file copies
  plus `tests/common/mod.rs:53`, which is NOT pub, has ZERO callers outside its own module, and
  whose doc comment states outright that the estate's copies predate the shared module. The lossy
  timeout arm (panic loses everything captured, names nothing) is in 38 sites across 36 files.
  The copies have already drifted: two variants of the deadline expect-string exist in the estate
  (`"captured spt call must complete within its deadline"` in common/mod.rs:60 vs the
  no-deadline-clause spelling in per-file copies), so a grep keyed to either string undercounts.
  The right fix is a hoist-and-delete refactor (make the common copy pub, adopt it estate-wide,
  carry the item-2 diagnostic arm once) — a 50-file test-estate touch that must NOT ride golden
  cadence as a rider or hide inside a scoped diagnostics item (ADR-0050 thin-lane rationale;
  hertz's USHER item 2 stays scoped to live_resolve, which keeps ONE improved copy as the model).
- **Built evidence:** one public owning helper replaced all 50 file-local
  clones. It owns and tree-kills a timed-out child, waits for reap, drains both
  pipes, and includes the deadline plus partial stdout/stderr in the panic.
  A dedicated regression observes both diagnostics and proves the timed-out PID
  is gone.
- **Ripe when:** a dedicated post-batch test-hygiene lane (natural companion to IR-13's
  mutation-proof loop and IR-23's home-collision fix — same hertz wave shape).
- **Size:** medium by file count, small by risk (mechanical hoist; no assertion changes).
- **Hygiene-lane scope addition (todlando, at #6, 2026-08-04):** a CI prebuild of
  `cargo build -p mock-adapter --bin mock-shell` (derived from tracked `.github/` content) turns
  SIX binedge baseline rows green at once instead of growing the burn-down list one consumer at a
  time — belongs to this lane, not to any thin verb lane. [[IR-38]] (live-binary e2e reap sweep)
  rides the same lane.
- **Built evidence:** all 51 file-local definitions are gone; 158 call sites use the one public
  `common::output_bounded`. The shared helper owns the child, kills and reaps its process tree on
  timeout, drains both pipes, and reports partial stdout/stderr. `bounded_output_e2e` mutation-pins
  both timeout ownership and retained diagnostics.
- **Declared validation extra:** the lane's docs-link gate exposed that `llms_target_exists` treated
  generated targets as absent before generation. Its small refactor + unit keeps source and
  generated link targets distinct; it is deliberate validation fallout, not part of IR-36.

### IR-37 — `traceable-reqs check` is coverage-only: tag PLACEMENT is unenforced on any multi-tagged REQ, and the more tags a REQ accumulates the less any one is checked
- **Status:** UPSTREAM CLOSED THROUGH RELEASE 2026-08-19 — traceable-reqs PR #19 squash-merged
  @`82d8b14` after doyle's targeted re-review PASS (defect A item-tables + 9 red-first regression
  cells + sighted control; defect B enclosing-item fallback DECLARED in SPEC with cost; 267/267,
  blind repros exit 0); v0.4.0 cut (version bump @`c9a8eb5`, tag pushed, 3 platform assets,
  release notes authored; refs sent to hertz). REMAINING and dispatched to hertz post-#182-landing:
  spt-core consumes v0.4.0 — CI version bump + placement config (enforce-on, module_banner=accept);
  banner cleanup rides a later lane. Entry closes when the consume lane lands. · **Origin:** hertz
  measurement 2026-08-04 (filed by doyle; the measurement is
  hertz's), found when his own pre/post `check` comparison around a tag-adjacency fix came back
  EXIT=0 on BOTH sides — the green he had cited beside the fix validated nothing.
- **What/why:** measured on `test/teardown-bound-shape`: a `unit->REQ-RESIDENT-SERVICE` tag
  SEPARATED from its `#[test]` fn (a const landed between tag block and fn — an AGENTS.md rule-1
  violation) scores EXIT=0 identically to the fixed adjacency. Positive control explains the
  mechanism: that REQ carries 57 unit tags across five files, so 56 other sites decide the
  coverage verdict and no single tag's placement can turn it red. Consequence: AGENTS.md rule 1
  ("tag on or immediately above the real evidence") is agent discipline only — drifted tags decay
  silently while coverage stays green, and heavily-tagged REQs decay fastest. This is the
  [[IR-32]] family shape (a gate that cannot see its own blind spot) applied to the traceability
  gate itself.
- **LIMIT, with falsifier (hertz's, verbatim in kind):** behaviour on a SINGLE-tagged REQ was NOT
  established. Separating the only tag of a single-tagged REQ at the stage under test would settle
  whether placement is unenforced outright (still exit 0 ⇒ the checker never reads adjacency) or
  merely un-enforceable at scale (exit 1 ⇒ the checker sees absence, and only multi-tag redundancy
  masks drift). Run that discriminator BEFORE designing any remedy — the two outcomes want
  different fixes (a placement rule in the checker vs a per-tag-nearest-item heuristic).
- **Transfer:** doyle accepted this lane's independent EXIT-0 remeasurement and confirmed it
  matches todlando's settled 2026-08-04 discriminator. Upstream remedy: enforce adjacency for
  each individual `doc`/`impl`/`unit`/`int` tag, with separated-tag negatives covering
  single-tag, interposed-const, file-top-banner, and one-of-many displacement. This repo consumes
  the released checker only.
- **Close condition:** doyle reviews and merges the upstream lane, cuts the `traceable-reqs`
  release, and spt-core consumes that release. Issue/branch/PR/commit refs append here when the
  upstream lane lands.
- **Size:** measurement complete; remedy scope is upstream-owned and dispatched.
- **CONSUME LANE + REGRESSION (doyle, 2026-09-11):** hertz's #304 lane carries the consume (2072b467 ci.yml
  WANT 0.4.0, c3b5feec golden.yml pin, 33936943 `[placement] enforce=on, module_banner=accept`).
  Measured on his tip under 0.4.0: misplaced 9 (tags quoted in backticks in prose; fixed on main
  dd0679dc) and 81 doc stages MISSING that 0.2.0 counted — a checker regression, not drift: 0.4.0's
  git enumeration skipped a FILE root (`CONTEXT.md`), see [[IR-104]]. Fixed upstream as v0.4.1
  (PR #21 -> d9af11d); the lane pins move to 0.4.1 in one fixup after hertz's window. Entry
  closes when that fixup lands on main.
- **DISCRIMINATOR RUN 2026-08-04 (todlando, authorized specimen on `build/w1t2-shell-relink-force`;
  filed by doyle — the measurement is todlando's): the answer is the EXIT-0 ARM.** Single-tagged
  int stage (`REQ-SHELL-RELINK-FORCE`), tag SEPARATED from its fn (parked at file top):
  `traceable-reqs check` EXIT 0 and the REQ still reports `+int`. Tag reverted to adjacency:
  EXIT 0, `+int`. Both exits redirect-read, no pipes. **Placement is UNENFORCED OUTRIGHT — the
  checker never reads adjacency; multi-tag redundancy was never the mechanism, it only widened the
  blind spot.** Remedy option (a) is the live one: a real placement rule in the checker (upstream
  experimplate), not a per-tag-nearest-item heuristic. Measurement caveat, carried at the
  measurer's own insistence: an intermediate probe printed `TAG_ADJACENT_AFTER_REVERT=0` and that
  was the PROBE wrong (`grep -B 1` above the fn lands on `#[test]`, not the tag above it), not a
  failed revert — the revert was verified directly (exactly one tag, above `#[test]`). The
  discriminator result is the record; the intermediate zero is not.
- **REMEDY DISPATCHED 2026-08-18 (doyle):** upstream lane opened in BigscreenVR/traceable-reqs
  (the actual upstream remote; the checkout at `~/Documents/projects/traceable-reqs` tracks it —
  "experimplate" above named the tool's origin project, not the repo) — checker-side placement
  rule, default-on in `check`, positive controls all four stages + separated-tag negatives
  including the single-tag displaced discriminator shape and the interposed-const shape.
  Requested by hertz as the IR-37 prerequisite of his test-hygiene family lane (KEYSTONE #182).
  spt-core consumes the upstream RELEASE only — no local shadow checker. Issue/branch/PR refs
  land here when the lane reports.

### IR-38 — CLASS: an e2e that ends with a live daemon-spawning binary wedges the NEXT build in its pool, and the diagnostic names the wrong lane
- **Status:** BUILT 2026-08-18 on KEYSTONE #182 hygiene lane. · **Origin:** todlando 2026-08-04,
  `shell_relink_force_e2e` on the #6 lane (filed by doyle; the finding and the fix are todlando's).
- **What/why:** the e2e ends with a LIVE binary by design; on Windows a live process holds its
  image open, so the NEXT cargo invocation in that target dir dies with
  `failed to remove file target\debug\spt.exe: Access is denied (os error 5)` — surfacing as
  exit 101 with NO test summary, because the failure names the BUILD and the FILE, never the test
  that leaked the holder. Actual holders measured: two lane-local `spt daemon run --detached` +
  `daemon brain` processes spawned under the test's temp SPT_HOME by a child CLI's
  `ensure_running`, still alive from an earlier run. **Reap BY IMAGE PATH** — the fleet's other
  eleven spt processes run from the installed binary; a name-based sweep takes your own daemon.
  The live shell-spawn population is eleven e2e files. Nine already end through product teardown
  or their authenticated home-scoped reap. The two intentionally live-at-success siblings now
  kill and prove the final resident gone AFTER all identity/wake assertions:
  `shell_relink_force_e2e` and `shell_stale_online_e2e`.
- **Kin:** [[IR-7]] (phase-A daemon+brain pair leak), the exe-lock reap-by-path rule, and the
  wrong-lane-diagnostic family ([[IR-21]]'s location-not-build class).
- **SECOND HOLDER CLASS, measured 2026-08-04 (doyle, own gate rig):** an **ORPHANED CONHOST with an
  inherited CWD** inside the test tree blocks `git worktree remove` with Permission-denied on a
  DIRECTORY handle — invisible to any exe-path scan (conhost runs from System32; the parent that
  spawned it was already dead). Found via `.github/ci/find-cwd-holders.ps1` (IR-11's instrument);
  killed by pid after parent-dead classification; 34.78 GB reclaimed. Mechanism chain: the
  windowless spawn path masks DETACHED_PROCESS off, the child owns a console, conhost inherits the
  child's cwd and can OUTLIVE it. Boundary (hertz's, correct): this find and his field-4 companion
  are the SAME MECHANISM FAMILY measured on DIFFERENT populations by different instruments — his
  capture measured a ppid-match COUNT (floor 2, companion identity UNMEASURED, his stated limit),
  and this conhost is the first FIELD identity evidence in the family, on THIS population. Do not
  cite his row as identity data it never carried. (His box-wide accretion count 77→80 is a third
  population again.) Teardown rule
  addendum: a disposal leg must GATE on the removal's exit code (a rig that logs "reclaimed 0.01
  GB" from a failed remove fabricates its own success) and sweep CWD HOLDERS, not only image
  locks — two populations, either alone is a clean zero on the other.
- **Ripe when:** the test-hygiene lane (IR-13/IR-23/IR-36 family) — sweep every e2e that ends
  with a live spawning binary, apply the same reap-after-assertions shape.
- **Size:** small per test; population unknown until swept.
- **Built evidence:** focused runs of both live-at-success tests pass back-to-back in one target
  pool, followed by a build invocation from that same pool; the second test's final kill is polled
  to proven process death rather than treated as fire-and-forget.

### IR-39 — CLASS: the missing-fixture-bin defect has TWO failure faces, and one of them impersonates a lifecycle defect of the subject under test
- **Status:** BUILT 2026-08-18 on KEYSTONE #182 hygiene lane. · **Origin:** hertz + todlando
  2026-08-04, same evening from opposite sides (filed by doyle; hertz relayed todlando's
  suggestion without endorsing scope).
- **What/why:** a rig whose narrowed build (`-p <pkg> --test <one>` / `-p spt --bin spt`) skips a
  cross-package fixture bin fails in one of two ways depending on the consuming site.
  Face 1 (cheap): `translate_proof_fixture` panics "must be built: <path>" — names the artifact
  and the recipe, costs one build. Face 2 (expensive): `sibling_bin("mock-session")` resolves to a
  nonexistent exe, nothing spawns, and the test reds at a PRECONDITION assert whose message
  ("warm bring-up spawned=false", left None / right Some("offline")) reads as a lifecycle defect
  of the subject — measured cost 186s + a triage inside a lent box window (hertz's F1 red arm,
  attempt 1). The build gap itself is the known cross-package row of the fixture-bin population;
  what this entry carries is the DIAGNOSTIC asymmetry.
- **Ask:** a fixture-bin existence precondition that NAMES the missing exe and its build recipe
  wherever a rig consumes one — `sibling_bin` (and the shared
  `crates/spt-term/tests/support/fixture_bin.rs` resolver already carries the recipe string as an
  argument, the shape to copy) refuses with the artifact + recipe instead of letting the consuming
  test fail downstream in its own vocabulary.
- **Kin:** [[IR-21]] (wrong-lane-diagnostic family: the failure names the wrong actor), the
  cargo-builds-package-bins-for-integration-tests rule (cross-package row is the only unguaranteed
  build), golden.yml's dedicated fixture prebuild step.
- **Ripe when:** the test-hygiene lane (IR-13/IR-23/IR-36/IR-38 family) — same sweep population;
  or standalone small if that lane keeps slipping.
- **Size:** small — one shared helper + a sweep of local `sibling_bin` resolver copies (24 known).
- **Addendum (doyle, 2026-08-04 late): third and fourth sightings inside 24 h.** Face 1 twice
  more the same evening — todlando's teach-lane leg set (his own translate_proof_fixture, caught
  by his prebuild), and doyle's cold gate rig for the same lane (first-pass spt-bins red at
  136/611, correctly withheld from the lane verdict as rig evidence, fixed by `cargo build -p spt
  --bins` + rerun 611/611). Four sightings in one day across three agents and both faces: the
  ripeness condition ("the test-hygiene lane keeps slipping") is under measurable pressure — the
  prebuild remedy is being re-derived per-rig per-agent, which is the recurring cost the shared
  precondition helper exists to delete.
- **Built evidence:** all 29 file-local `sibling_bin` resolvers now route through one shared
  precondition. A missing fixture names its path and the package-correct `cargo build -p <owner>
  --bin <name>` recovery command before product assertions or timeout paths run; a focused
  negative test pins that diagnostic.

### IR-40 — CLASS: NO envelope-side ordering signal on a resume brief tracks content recency, and a CI informant's per-job line is a claim about that STEP, not the run
- **Status:** open · **Origin:** three sightings in one night, 2026-08-04/05 — hertz, doyle,
  todlando (filed by doyle; the artifacts are hertz's and todlando's, the CI arm is doyle's with
  deployah's framing). Two arms of ONE family: a stale record that carries a confident ordering
  signal, and a status claim that arrives before the thing it describes.

- **ARM A — resume briefs. What/why:** a session can receive TWO start-of-session briefs, and the
  one routed LATER can carry the STALER project-context. Measured on hertz's pair (same node id):
  routed_at_ms `1785897407373` > `1785896642480`, spill-filename epoch `1785897764588` >
  `1785896658159`, and vector sequence `1242529/1242531` > `1241542/1241544` — **all three
  monotonic orderings rank the staler-content brief as newer.** todlando's pair is the NEGATIVE
  arm: his later brief (`…1785897765196`, routed `…577476`, vector `1242756/7`) genuinely WAS the
  fresher one, so the same heuristic happened to pick right.
- **The finding is UNCORRELATED, not inverted** — and that is the whole entry. An inverted signal
  is usable once you know to flip it; an uncorrelated one reads as reliable until the pair where it
  costs you. Neither agent could have known which pair he held without checking content against
  measurement. **Do not name routed_at_ms specifically** — naming the stamp invites the repair that
  fails ("the timestamp is unreliable, use the sequence number"). The vector is the most dangerous
  of the three: a stamp looks like a clock and invites suspicion, a sequence number looks like an
  ordering and does not.
- **Visible failure mode if a brief is obeyed as instructed** (hertz's, measured): re-open
  `releases#123` — work already ruled closed — and under-report his own claimed-pool count by one,
  the row sitting under a live gate. doyle's own sighting the same night: a brief describing main
  @`92b2482` with a teach lane "mid-flight" hours after every lane had gated.
- **PRE-REFUSED DISCRIMINATOR, recorded so it is not rediscovered as a finding:** file SIZE ranks
  the fresher brief correctly on BOTH pairs (hertz 16308 > 12649; todlando 14138 > 10418) — 2 of 2,
  the only signal surviving both samples. **Do not use it.** Size measures RICHNESS, not recency;
  the two correlated only because todlando's thin brief was a correction fragment, and hertz's
  STALER brief was a full 12649-byte dump. Two full dumps hours apart go flat or inverted. Handed
  over pre-refused by its own finder.
- **ARM B — CI informants (doyle, 2026-08-05, run 30971976024).** `CI-KITSUBITO` sent
  "CI SUCCESS … sha 0a25b77" while the run was measurably `status=in_progress` with
  `conclusion=""` — the EMPTY STRING, not `success`. The informant fires from a per-job `notify`
  step, and at send time `notify` itself had no conclusion. All eight substantive jobs were green,
  so the line was **right in the end but EARLY**. deployah's framing, kept verbatim in kind: *an
  informant line that is right in the end but early is worse than one that is simply wrong, because
  a wrong signal gets distrusted while an early-but-correct one gets promoted to the conclusion.*
  todlando's sentence is the one to keep at the point of use: **a per-job notify step's message is
  a claim about that STEP, not about the RUN.**
- **ARM B MECHANISM — hertz, source read 2026-08-05, zero box cost. It is NOT a race; it fires
  early on EVERY run, and the entry above understated it.** `notify` is a job INSIDE the run
  (`golden.yml:1138`), and a job cannot observe its own run's conclusion — so `conclusion: ""` is
  not a timing artifact, it is **the only value that can exist when the informant speaks. The
  informant has never once made a statement about a run conclusion.** What `ci-notify.sh` actually
  asserts is narrower and worth naming exactly: a verdict computed PURELY from six `needs` results
  (changes, traceability, test, n1-gate, twohost-a, twohost-b — the two matrices collapse to one
  result each) being neither failure nor cancelled. Nothing more.
  **The blind spot is exactly ONE job: `notify` itself, the 9th — it cannot appear in its own
  `needs` list. And that one job has a WITNESSED red path**, documented in the script's own header
  (2026-07-27, twice on kitsubito): verdict computed, then `spt send` HUNG ~5 minutes until the
  job's own 5-minute budget cancelled it, and that cancellation reddened the run. So *"informant
  says SUCCESS, run concludes FAILURE"* is a real observed sequence, not a hypothetical. The 30s
  `SEND_BOUND_SECS` added since bounds the hang but does not close the class — it makes the
  informant's own failure FAST rather than impossible.
  ⇒ The informant's SUCCESS covers 8 of 9 jobs and is blind to the 9th, and the 9th is the only one
  with an observed failure mode that reds the run. This is why the ff predicate is the run's
  conclusion field and never the informant line.
- **RECOVERY, and it is the same for both arms: never rank the claims — re-derive from the source
  object.** For briefs, hertz's four falsifiers are the method (main sha, claimed-pool count, lane
  tip, issue state) and they work because each is a content claim checkable in ONE command against
  a source NEITHER brief controls. For CI, read the RUN's own `conclusion` field, and prefer
  independent reads of the run object (`gh run watch --exit-status` polls the run, so its exit is a
  second measurement rather than an echo of `notify`). On the batch this was caught in, three
  sources agreed with the informant excluded from all three before main was fast-forwarded.
- **Standing rule this entry exists to enforce:** a resume brief's RULINGS are durable; its STATE
  is a HYPOTHESIS to re-derive before acting.
- **Kin:** [[IR-21]] and [[IR-39]] (the diagnostic names the wrong actor / the wrong subject),
  [[IR-32]] (a gate that cannot see its own blind spot), [[IR-34]] (an intermittent marker read as
  a signal).
- **Ripe when:** the next commune/psyche-tier touch for arm A (the routing layer is spt-core's own
  `spool`/psyche ingest, so a remedy is in-repo, not upstream); for arm B, the next `golden.yml`
  informant touch — the cheap fix is that the notify step names its own scope in the message body
  (STEP vs RUN) rather than emitting a bare "CI SUCCESS".
- **Size:** arm B small (message text + scope word in one workflow step). Arm A unsized —
  establishing whether ANY durable content-recency signal can ride the envelope is the measurement,
  and until it runs the answer is "re-derive, do not rank."

### IR-41 — A QUEUED main run is superseded without a record; `cancel-in-progress: false` protects only STARTED runs
- **Status:** open — mechanism CONFIRMED (doyle ruling 2026-08-05); the runbook sentence it
  falsified is already corrected (`docs/RELEASE-RUNBOOK.md` step 3, same commit as this entry)
  · **Origin:** deployah, v0.55.0 publish night, filed by him explicitly as UNPROVEN with the
  manual-cancel alternative not ruled out; confirmed by doyle on the run objects.
- **What/why:** `ci.yml` sets `cancel-in-progress: false` on main and the runbook read that as
  "main's concurrency policy never cancels this run; that preserves the record." FALSE for the
  queued phase: a concurrency group holds at most one running + one pending run, and a newer push
  REPLACES the pending run regardless of the flag — the flag governs only whether a STARTED run
  is cancelled. A superseded queued run leaves NO record: zero jobs, conclusion `cancelled`,
  nothing measured about its sha.
- **Evidence (all read off the run objects, not the informant):** run 30973909279 at `327f1f8`
  (push, main) — created 04:01:08Z, **zero jobs ever started**, cancelled 04:03:49Z, ONE SECOND
  after `e8805f7`'s run 30974041521 entered the group (created 04:03:48Z), while `0a25b77`'s run
  30973770039 was still in flight (done 04:07:59Z). One-running-one-pending, newer push landed,
  pending run died. The 1s coupling to an unrelated push is the discriminator against deployah's
  own manual-cancel alternative — a human cancel co-timed to the second with a push it had no
  view of is not a credible mechanism; supersession fires on exactly that trigger by design.
- **The hole this leaves:** under a rapid push sequence, an intermediate sha on MAIN can have no
  thin-CI verdict AT ALL, and the absence reads as nothing rather than as supersession. Anyone
  auditing "did sha X pass main CI" gets a hole where the runbook promised a record. Absence of
  a run is now a labelled state, not evidence about the sha.
- **Ripe when:** next ci.yml/runbook touch. Candidate remedies to weigh THEN, not now: accept and
  document (done — the runbook now carries the mechanism), or give main's group per-sha keys
  (`group: ci-${{ github.sha }}`) so runs never share a group — at the cost of concurrent main
  runs competing for the boxes, which is exactly what the group exists to prevent. The trade is
  real; do not fold it into a drive-by.
- **Size:** docs half DONE in this commit; ci.yml half small but load-bearing — needs its own
  lane if taken.
- **Kin:** [[IR-40]] (a record that is right-in-the-end-but-early vs a record that never comes to
  exist — both read as clean states unless labelled), [[cancelled-measurement-leaves-labelled-hole]].

### IR-42 — `pool-claim` writes a record; only the BUILD enforces — and AGENTS.md invited the misread
- **Status:** BUILT 2026-08-19 — the AGENTS.md corrective line lands in the SAME COMMIT as this
  entry (the register batch commit), which is the entry's stated exit condition. The optional
  code-side nicety (claim verb prints the incumbent record it overwrites, information only)
  remains unclaimed — a candidate rider on the IR-26 remedy lane, which already touches
  `pool_claim`'s read-before-write path, NOT a reason to keep this entry open ·
  **Origin:** doyle + todlando independently at source, 2026-08-19, during the #193 gate.
- **Mechanism (source-verified):** `xtask pool-claim` (crates/xtask/src/main.rs:2232-2294 at the
  read sha) parses its args, reads the lane's own git identity, builds a `PoolOwner` and calls
  `spt_poolguard::write_owner` UNCONDITIONALLY (:2280) — no `read_owner`, no verdict, no
  comparison against the incumbent claim anywhere in the function. Claiming is last-writer-wins
  by construction: two lanes can each "hold" a pool in sequence with only the last write
  surviving, and the displaced lane learns nothing at displacement time. All four enforcement
  arms — `Refuse` (SPT_POOL_FOREIGN), `Takeover` (loud), `Unproven`, `HatchOpen` — live in
  crates/spt-store/build.rs:31-113 and speak only at the next BUILD. (Same object [[IR-26]]'s
  CLAIM-OBSERVABILITY measurement saw from the displaced side; this entry is the CLAIMING side
  plus the doc that invited the misread.)
- **Measured consequence:** 2026-08-19, doyle's gate claim over todlando's unlanded
  redeem-echo-diag claim — no refusal, no notice (three sequential overwrites that session, one
  over a lane with an unlanded commit). todlando then predicted from AGENTS.md's refusal
  sentence that the gate's claim "will be REFUSED" — a false warning to a gater mid-run. The
  refusal sentence sat directly under the "Claim a pool at lane start" instruction, inviting the
  build-time semantics to be read onto the claim verb.
- **Corrective landed:** the claim WRITES a record without adjudicating the incumbent lane;
  predict **lane-identity** refusals from builds, never from `pool-claim`. The broader original
  "never refuses" wording is superseded by IR-56's **addressing** guard (wrong-tree claims need
  explicit `--foreign-pool`); that guard does not add incumbent-lane adjudication.

### IR-43 — knock answer carrier: `NoReply` landed at 60.08s against a stated 30s carrier deadline
- **Status:** open, OBSERVATION — mechanism unmeasured, filed exactly as wide as the datum ·
  **Origin:** KNOCK-169 RCA layer 1 (todlando, read-only), golden 32191618042 @`93c1130`,
  twohost-b, 2026-08-18.
- **What/why:** B's `request_answer` yielded `NoReply` at 22:50:08.3605Z — 60.08s after A's
  death — while the carrier deadline is stated at 30s. Recorded in the RCA as a side observation
  with no claim; the cell's red itself was a CASCADE of A's earlier death (answerop.rs:73-81
  produces the courtesy BEFORE returning, so the reply was never sent — that half is settled and
  is NOT this entry). What this entry carries: a transport/liveness bound that reported at 2x its
  stated value. Candidate shapes, neither asserted: two sequential 30s legs each honoring its own
  bound (a composed wait wearing one bound's name), or a bound armed after a wait it does not
  cover (the [[IR-30]] nethost.rs permit-wait shape: `sem.acquire_owned()` outside the timeout).
- **Ask:** derive where the 30s is armed and what path yields a 60s `NoReply` — one code read
  from the emit site, before any instrument.
- **Ripe when:** next knock-carrier touch, or the next `NoReply`-shaped red — whichever first.
- **Size:** small (code read; a token only if the read forks).

### IR-44 — perch-sentinel comment overclaims: serialization is not preservation, and the comment teaches the false step
- **Status:** open · **Origin:** #188 RCA lock read (todlando flagged, doyle confirmed the lock
  read), 2026-08-18; the collapse-of-branches argument is on #188 and in the RCA record.
- **What/why:** `lock_perch_sentinel` (info.rs:778 at `b20e770`, the diag sha — re-derive the
  line on main before editing) takes a cross-process fs2 lock on a stable per-perch `.info.lock`
  sentinel, and its comment claims it serializes "ALL info.json writers so a whole-record write
  and a locked RMW can never lose each other's update (`REQ-HAZARD-INFO-RMW-LOST-UPDATE`)" —
  TRUE for interleaving, FALSE for preservation. `write_info_unlocked` is module-private with
  exactly three callers, all taking the sentinel first (bypass refuted by visibility), but every
  caller of the public `write_info` composes its record BEFORE the lock is taken (:842) — **the
  lock makes that write atomic; it cannot make it preserving.** Only `mutate_info` /
  `establish_locked` read under the hold and can preserve. Measured field case: census write #1
  (`twohost.rs:736`) clobbered `controlled` while correctly locked. A reader trusting the
  comment infers lost-update immunity the funnel does not provide — the #188 hunt burned a
  branch on exactly that inference before the collapse argument killed it.
- **Ask:** respell the comment — serializes writers; a composed `write_info` is atomic, never
  preserving; preservation requires `mutate_info`/`establish_locked` — and weigh whether
  `REQ-HAZARD-INFO-RMW-LOST-UPDATE`'s doc wording carries the same overclaim.
- **Ripe when:** next spt-store/info.rs touch. **Size:** tiny (comment + possibly one REQ doc
  line).

### 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
  re-homed (see Answer). · **Origin:** #188/#189 RCA readouts (todlando, doyle's 2a-2d), runs
  32097943571 + 32108557362 + 32111921251, 2026-08-18.
- **What/why, two measured halves in tension:** (1) B's pump dialed a THIRD node 155-159 times
  per run at kitsubito's OWN tailscale IP (`100.98.197.12`), different hex + different ephemeral
  port each run — a short-lived local endpoint re-minting identity between runs, present in both
  the golden and the diag run. Read at the time as: the rig uses the CANONICAL home
  (`canonical_pump_paths` → `perch::spt_home()`), so B's roster is kitsubito's live fleet
  roster — environmental coupling of a CI rig to host fleet state. (2) The ER perch measured in
  the chain runs resolves under a per-run TEMP root
  (`…/_temp/spt-test-tmp-<run>…/owlery/engine-room`), NOT the canonical home. Both measurements
  stand; they answer different artifacts (pump roster vs perches), and nothing on record settles
  which home the PUMP paths actually resolve. #189's third-node evidence and its
  cache-leg-never-heals reading rest on that premise (the tension is filed on the #188 record as
  an open question against #189).
- **Answer (2026-08-19, code read at `78a9a16`, unambiguous — no run token needed):** both role
  tests set `SPT_HOME` to a fresh per-run `TempDir` as their FIRST act (`twohost.rs:813-814` role
  B, `:1501-1502` role A), before any store touch. `canonical_pump_paths` resolves every path via
  `perch::spt_home()` (`twohost.rs:396-414`), which honors the `SPT_HOME` override first
  (`perch.rs:34-41`); the pump's roster source `presence::registry_snapshot_dir()` →
  `perch::identity_dir()` sits under the same root (`presence.rs:83-85`). The rig is
  DISK-HERMETIC per run; both prior measurements reconcile (ER perch observed under the temp
  root, pump paths resolve there too). The misleader was the helper's name + doc comment ("real
  homes, not test roots"), which describe production path LAYOUT, not the resolved ROOT.
- **Residue disposition:** (1) #189's third-node evidence was corrected on the board (comment
  5337519936) — the roster row arrived at RUNTIME into a temp-rooted store, ingress mechanism
  OPEN on #189, no longer explained-environmental. (2) KEYSTONE #182's hygiene lane repaired the
  `twohost.rs:394` comment to say exactly what the helper does: production path layout rooted in
  the process's fresh per-run `SPT_HOME`.

### 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
…
  version of it.
…

…