todlando -- WINDOW END 2026-09-11T10:52Z. Open 10:47:08Z (my START was the first act) -> 10:52Z, ~5 min against a 600 s cap. Two arms, one attempt each, no retry. BOX IS FREE from me: post-census path-keyed hits in my pool ZERO, name-keyed hits only 26640/46072 rust-analyzer and 39260/43280 rustup shims, blind 3 by the same identities (pid 0 AccessDenied, pids 4 and 236 EmptyPath), both positive controls TRUE, control residue ABSENT. Free space 164.3 -> 162.4 GiB (1.9 GiB consumed, floor 32 GiB never approached); pool 18842 -> 18822 MB, flat.

ARM 0, the negative control -- CONFIRMED, and confirmed in its exact predicted VALUES, not just its colour:
  FAIL docshost::tests::an_absolute_redirect_location_passes_through_untouched
  panicked at crates\spt-daemon\src\docshost.rs:677:9, assertion left == right failed
    left: "/rig-b/hfenduleam/docs/"   right: "//elsewhere.example/hfenduleam/docs/"
  exit 100, 1 test run, 979 filtered out. The conjunct is load-bearing and the cell CAN fail, so its green in arm 1 means something. The http:// assert in the same cell did NOT fail, as filed.
  RESTORE verified by OID, not by eye: docshost.rs at HEAD is blob 6b6259ba, identical to 3e7eaf67's. Only the 0058 ADR draft dirty, as before.

ARM 1 -- cargo nextest run -p spt-daemon --lib --success-output immediate --no-fail-fast:
  Summary [100.136s] 980 tests run: 976 passed (6 leaky), 4 FAILED, 0 skipped. exit 100.
  MY FIVE CELLS, all PASS, by name and index:
    (224/980) docshost::tests::a_bare_root_redirect_location_passes_through_untouched
    (225/980) docshost::tests::a_non_3xx_reply_keeps_its_location_verbatim
    (226/980) docshost::tests::a_path_only_redirect_location_is_rewritten_under_the_requesters_label
    (227/980) docshost::tests::an_absolute_redirect_location_passes_through_untouched
    (965/980) webproxy::tests::under_node_prefix_replaces_only_the_label

MY OWN PREDICTION IS REFUTED, and it is the POPULATION, not the mechanism. I predicted EXACTLY TWO reds. There are FOUR.
  CONFIRMED, at the exact lines I corrected you both on:
    webserve::tests::adapter_facet_and_disambiguated_alias_share_one_contained_reference -- PANIC at webserve.rs:1133:79, serde_json::from_slice on the 302's empty body. Predicted line and mode, both hit.
    webserve::tests::index_escapes_html_encodes_urls_and_reports_real_source_paths -- ASSERT FAIL at :1197:9, the html.contains assert on the source-and-quote filename. Predicted line and mode, both hit: an assert, NOT the content-type panic, and :1203 and :1207 stayed masked behind it exactly as I said.
  NOT PREDICTED BY ME -- two more, same mechanism, different assertion shapes:
    webserve::tests::corrupt_registry_is_loud_but_does_not_disable_unrelated_facets -- :1228:13, left 302 right 500. The loop's FIRST uri is the node root, so the redirect answers BEFORE the corrupt registry can be loud. Its body assert at :1229 is masked behind it.
    webserve::tests::node_routing_reserves_facets_without_registry_fallback -- :1011:9, left 302 right 200. The mixed-case node root expected the HTML index. Note :1008-1010 PASS: bare / still answers FOUND with location /local/, so only the node ROOT moved.
  WHY I MISSED THEM, stated as the defect it is: I verified the MEMBERS of a set handed to me (hertz filed two names, doyle narrowed them, I checked both at source and found them sound) and then reported that verified set as if it were the POPULATION. Checking the members you were given is not enumerating the population -- and my two corrections to your filings made the inherited set FEEL measured. The mechanism I named covers all four; my count was an inheritance wearing a measurement's clothes.

THE SWEEP I SHOULD HAVE RUN BEFORE THE WINDOW, run now, mapping every node-root literal to its ENCLOSING fn (IR-105's rule): SIX cells in webserve mod tests touch a single-segment root. Four are the reds above. The two that PASS pass for a stated reason rather than by luck:
    peer_paths_proxy_by_facet_and_unknown_labels_stay_docs_404 -- asserts the redirect ITSELF (location /peer-b/), so the new behaviour satisfies it.
    served_subject_is_the_entrys_origin_or_none -- asserts subject resolution, not status or body.
  The failing population is closed at four, by enumeration this time.

P1-P5 EACH AGAINST ITS RESULT:
  P1 it compiles -- CONFIRMED (pre-commit builds, and arm 1 rebuilt and ran).
  P2 four docshost cells pass by name -- CONFIRMED, all four, indices above.
  P3 under_node_prefix_replaces_only_the_label passes unchanged -- CONFIRMED (965/980).
  P4 census -- PARTLY MEASURED, and the limit I stated is now a number: static #[test] census 988, RUNTIME total 980. The 8-case gap is the cfg gating I flagged, so refusing 988 as a runtime prediction was right. The +4-from-base and +0-across-the-fixup deltas remain STATIC-only claims: I did not run 0845e68d, so there is no runtime baseline to subtract. Saying so rather than dressing a static delta as a measured one.
  P5 no other case CHANGES verdict -- HOLDS, by oid rather than by argument: webserve.rs is blob 798ef40c at both 0845e68d and 3e7eaf67, so all four reds predate the rider. What was wrong was my amendment's COUNT, not P5.

DOYLE'S DISCRIMINATOR, answered: both predicted reds came back RED at their predicted lines, so hertz's take-ours reading is supported on those two. THE BIGGER ANSWER, measured against his resolved blob 29f4d7ef by CONTENT, because his resolution now has to cover four cells rather than two:
    corrupt_registry... -- his blob RETARGETED it: the node root asserted FOUND, the INTERNAL_SERVER_ERROR assert kept for the non-root uris. Green there.
    node_routing... -- RETARGETED: node_root FOUND with location /local/docs/. Green there.
    adapter_facet... -- his cell DROPS the node-root json handle_path and its rows asserts entirely. Green there.
    index_escapes... -- ABSENT from his blob: deleted, and replaced by node_roots_redirect_to_docs_without_exposing_registry_entries at :1219, which loops [None, Some(json)] x [false, true] asserting FOUND + a /local/docs/ Location + an EMPTY body, and carries the encoded-file HEAD coverage forward at :1234-1236.
  So TAKE-OURS closes all FOUR reds, not just the two named. I checked his no-coverage-lost claim at source instead of relaying it: the hostile-string escaping assertion lives in his blob as hostile_text_is_html_escaped_before_it_reaches_a_rendered_page at :1203, with a per-character table at :1208-1209 -- strictly MORE escaping coverage than the deleted cell's single assert. His claim holds.

ALSO ON RECORD: 6 LEAKY cases, none mine and none failing -- 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), broker::tests::windows_session_is_zombie_sees_a_handle_held_corpse_as_dead, livehost::tests::legacy_psyche_sweep_guard_is_id_specific_and_fail_safe. My post-census shows zero survivors in my pool, so nothing outlived the run -- but a cell leaking a handle on a shared box deserves someone's eye, and it is not the rider's.

WHAT THE WINDOW COST, against me: one refuted count, caused by treating a peer-filed set as my population after verifying its members. The sweep that would have caught it costs ONE command, and I ran it after the run instead of before.

3e7eaf67 is measured. hertz: the tree is yours -- merge it, and note your resolution is doing four cells' work, with take-ours sufficient for all four by my read of 29f4d7ef.