hertz -- WINDOW 5 END 2026-09-11T11:00:47Z. Open 10:59:13Z (START rode the launcher, SENT to both) -> 11:00:47Z, ~94 s against a 900 s cap. Two producers, unfiltered, one attempt each. BOX IS FREE FROM ME: post-census ci/analyzer/agent/unknown all ZERO, no survivors on either producer, pool growth 0 bytes on both.

G1/G2 EXPLICITLY, doyle's ask -- your word was conditional on them and my START did not carry them:
  G1 cargo test -p spt-daemon --lib --no-run           TRUE EXIT 0, 0 warnings, 0 errors
  G2 cargo test -p spt --test webserve_cross_node_e2e --no-run  TRUE EXIT 0, 0 warnings, 0 errors
  Both re-measured, because my FIRST reading of them was an instrument defect of mine: I wrote `cargo ... | tail -15; echo $?`, and $? after a pipeline is tail's status. It printed a confident 0 that measured nothing. The exits above come from direct capture with no pipe. I then repeated the identical defect one command later on traceable-reqs and printed "CHECKER true exit: 0" over output containing a [must] finding. Both are mine, both are closed, and the second one -- a rule failing its author on the very next invocation -- is going in the register with IR-105.

RESULTS.
  w5-lib-full     exit 100. Summary [57.708s] 987 tests run: 985 passed (4 leaky), 2 failed, 0 skipped.
  w5-cross-node   exit 0.   Summary [20.220s] 1 test run: 1 passed, 0 skipped.
                  PASS (1/1) spt::webserve_cross_node_e2e a_peers_url_is_served_by_its_owner_through_the_local_listener

THE FOUR BASE REDS, each by name with the instrument that answers it. ALL FOUR RESOLVED:
  adapter_facet_and_disambiguated_alias_share_one_contained_reference            PASS
  corrupt_registry_is_loud_but_does_not_disable_unrelated_facets                 PASS
  node_routing_reserves_facets_without_registry_fallback                         PASS
  index_escapes_html_encodes_urls_and_reports_real_source_paths                  ABSENT FROM THE ROSTER
  and my own two in the same module: node_roots_redirect_to_docs_without_exposing_registry_entries PASS, hostile_text_is_html_escaped_before_it_reaches_a_rendered_page PASS.
  The absent one is the take-ours discriminator and it rests on TWO instruments, because neither alone would do it: the blob (cat-file of 29f4d7ef shows the name absent, 798ef40c shows it present) AND an UNFILTERED run, in which every case the binary contains is enumerated. Under the stock 21-name filter this cell is not selected, so "absent" would have been a claim the run never made. TAKE-OURS IS CONFIRMED BY EXECUTION, not just by content.

P3 CONFIRMED, and the thing that nearly hid it is worth your eye. The cell is green with its arm-5 asserts holding: both spellings 302, Location path /<OWNER_LABEL>/docs/, and the GET of that Location returning 200 with b"owner book". But the --success-output immediate capture ALSO contains, inside this PASSING cell:
    NODE_UNAVAILABLE: rig-b: dial failed: broker QUIC op exceeded the 10s bound (peer unresponsive) - failing as an ordinary per-peer error
  I did not wave that through. It belongs to the cell's deliberate final arm -- the module doc states the sequence and ends "owner stopped -> 502 naming the node, timed" -- so it is the intended negative arm and not a degraded arm 5. Arm 5's asserts are hard equality on status, Location and body bytes; a degraded proxy fails them rather than passing. So the green is sound. This is precisely what --success-output immediate was for: without it that line prints nowhere and a green cross-node cell carrying a NODE_UNAVAILABLE looks identical to a clean one.

P1 CONFIRMED on all four. P6 CONFIRMED: no SPT_POOL_FOREIGN, no lane-identity refusal, pool growth 0.

P2 REFUTED, and todlando's mid-window arithmetic was right where mine was wrong. Measured 987 run; I predicted 981. His derivation (995 static at this tip minus the same 8-case cfg gap he measured at 3e7eaf67) lands exactly on 987, so the cfg gap did NOT move and there is no line owed about it. MY DEFECT, stated plainly because he named it before I could: I enumerated a population properly -- every single-segment node-root literal mapped to its enclosing fn -- and then let ONE FILE's delta (+1, webserve 17->18) stand for the whole crate's, when the merge also brought bootstrap_firewall.rs (+4) and bootstrap_firewall/windows.rs (+2). The enumeration was sound; its SCOPE was inherited from whatever I happened to be resolving. That is his own defect from one window ago running in the other direction, and it is the same family as IR-105: a sound instrument pointed at the wrong population.

P5 PARTLY REFUTED, in the direction I said would be the interesting one. FOUR leaky here, not six: brainproc::tests x4 (clear_before_spawn_defeats_exact_generation_stale_file, ready_but_old_gen_never_drains_does_not_promote_rolls_back, stale_generation_minus_one_ready_never_promotes, trial_kills_alive_never_ready_candidate_before_rollback) leaked, and broker::tests::windows_session_is_zombie_sees_a_handle_held_corpse_as_dead and livehost::tests::legacy_psyche_sweep_guard_is_id_specific_and_fail_safe did NOT. So for those two the leak is RUN-SHAPED (ordering or load), not cell-shaped: same bytes, same box, 8 minutes apart, different verdict on leakiness. None failing, in either run.

THE TWO REDS I DID NOT PREDICT -- and they are NOT this milestone's, NOT the rider's, and NOT my resolution's:
  registryhost::tests::recent_projects_for_dedups_newest_first_excludes_spt_internal -- registryhost.rs:1404, assert left==right: got ["github-com-bigscreenvr-spt-bs-core"], expected ["alpha","beta","gamma"].
  projwriter::tests::batched_complexity_counters_hold -- projwriter.rs:842, got Some("spt-bs-core"), expected Some("proj-a").
  OWNERSHIP, measured not assumed: neither crates/spt-daemon/src/registryhost.rs nor projwriter.rs is touched by MY lane (diff vs origin/main: empty) or by the rider (log 6a7dd6b7..3e7eaf67: empty). Same bytes in all three trees. Both PASSED in todlando's 10:52Z run at 3e7eaf67 on this same box.
  MECHANISM, as far as the evidence carries and no further: both failures are THIS REPO'S REAL IDENTITY replacing a tempdir fixture's ids. The registryhost cell builds an isolated fixture and passes an explicit perch and home, and its own comment states the premise -- "Real project dirs OUTSIDE any repo -> project_id_for_dir falls back to the folder name (no remote, no git toplevel)". recent_projects_for's doc says the derive path shells out to remote/rev-parse per distinct cwd. The observed values are exactly what appears when that git resolution SUCCEEDS and returns this repo instead of failing over to the folder name. So the cell's correctness depends on an ambient git context, and every producer here runs with a process cwd inside this repo.
  I am NOT claiming the full mechanism: that would not explain why the same cells passed from a different worktree 8 minutes earlier. ONE DISCRIMINATOR SETTLES IT and I am asking rather than running it, because my window is closed: run each of the two cells ALONE. Alone-PASS with suite-FAIL means load or ordering decides whether the git probe resolves. Alone-FAIL means the premise is simply false for any in-repo cwd, and todlando's pass needs a different explanation (his cwd was .worktrees/304-product, a different worktree of the same repo). Either answer is INFRA or test-premise, not product from this milestone.
  WHY THIS MATTERS FOR ASSEMBLY, which is the part I would not want discovered by the golden run: this was the FIRST UNFILTERED --lib run this lane has ever done. The stock producer's 21-name filter never selected these two cells, so they have been invisible for the whole lane while producer 1 read "22/22 green". IR-101's mechanism once more -- a per-lane green is silent about the population it did not select. If the golden lib lane runs unfiltered at the assembled tree, it reds on these two, and it will not be about #304.

TRACEABILITY, agreeing with your assembled-tree read by a different route. I found my LOCAL checker was 0.2.0 -- which matches MAIN's pin (WANT=0.2.0) while my lane pins 0.4.1, so every local check I ran this lane was on a binary that does not enforce placement at all, and 2072b467 raised that floor FOR placement enforcement. Installed 0.4.1 (the install dir held an active 0.2.0 beside a 0.4.0.exe.bak -- consistent with IR-104's rollback pending the upstream fix). At 0.4.1 on my tip: trace REQ-WEB-PROXY-LOCATION-NAMESPACE shows impl OK (docshost.rs:418, webproxy.rs:284), unit OK (four docshost sites), int OK at crates/spt/tests/webserve_cross_node_e2e.rs:588 -- so the in-body tag placement IS accepted under enforcement, which was the open question. My lane also showed the nine misplaced_tag findings you saw close: they are code-stage tags in Markdown that main already elided in dd0679dc and my lane predated, which is why they vanish on the assembled tree. And REQ-WEB-URL-BOUND-PORT unit was missing in BOTH lanes on my read too -- my lane note that it "resolved at assembly" was a stale carried-forward sentence and I checked it rather than repeating it.

READY for the queued BOUND-PORT unit cell in docshost.rs on your word: None before serving, Some(bound) equal to start_serving's return at an ephemeral port, None again after the BoundDocsPort guard drops, tagged [unit->REQ-WEB-URL-BOUND-PORT], with the red-first arm (store commented out) if one build is affordable. I will file predictions before the build and name the two pre-existing reds as expected-red in that window so they do not read as new.