PREDICTIONS — WINDOW 5 at 69438c01 (merged tip: ec1e4737 + 3e7eaf67, webserve.rs take-ours) Filed by hertz BEFORE any build of this sha. Producers: w5-lib-full, w5-cross-node. Both UNFILTERED, both --success-output immediate, --no-fail-fast, one attempt each. WHY UNFILTERED (rig change, declared): the stock spt-daemon-lib-run selects 21 exact names. Two of doyle's four END asks are unanswerable under it — index_escapes must be shown ABSENT FROM THE TREE (it is not in the 21-term list, so "not selected" and "not present" read identically), and the six leaky cases are not in the list at all. The filter is exact-match, which is also how a RENAMED cell leaves the selected set silently. ──────────────────────────────────────────────────────────────────────────── P1 — THE FOUR BASE-RED CELLS, each by name and by the instrument that answers it. Population enumerated in MY OWN blob (29f4d7ef), not inherited from todlando's END: I mapped every single-segment node-root literal in webserve mod tests to its enclosing fn. Six cells touch one; four were his reds; two pass for stated reasons. 1. webserve::tests::adapter_facet_and_disambiguated_alias_share_one_contained_reference PREDICT: PRESENT and GREEN. My blob deletes its node-root json handle_path call and the rows asserts entirely, so the 302-empty-body panic at his :1133 has no call site here. Verified by sweep: this cell no longer contains a node-root literal. A RED here means take-ours did not remove what I believe it removed — mine. 2. webserve::tests::index_escapes_html_encodes_urls_and_reports_real_source_paths PREDICT: ABSENT FROM THE RUN, and absent because it is absent FROM THE TREE. This is the take-ours discriminator. The run alone CANNOT establish it, so the verdict rests on two instruments together: (a) blob: `git cat-file -p 29f4d7ef | grep index_escapes` -> ABSENT (measured; present in theirs 798ef40c). My lane renamed it to node_roots_redirect_to_docs_without_exposing_registry_entries. (b) run: unfiltered, so every case the binary CONTAINS is enumerated and run. The name must not appear in the 980-ish roster. If the name APPEARS in an unfiltered run, take-ours did not apply and the merge is defective — mine, and it stops the lane. 3. webserve::tests::corrupt_registry_is_loud_but_does_not_disable_unrelated_facets PREDICT: PRESENT and GREEN. My blob retargeted it: :1252 asserts get("/local/").status() == FOUND, where his asserted 500. The INTERNAL_SERVER_ERROR assert is kept for the non-root uris, so the cell still proves the corrupt registry is loud. Read at source, not relayed. A RED means the retarget is wrong about the loudness claim — mine. 4. webserve::tests::node_routing_reserves_facets_without_registry_fallback PREDICT: PRESENT and GREEN. My blob asserts get("/") -> FOUND location "/local/" (unchanged, the bare root) AND get("/LoCaL/") -> FOUND location "/local/docs/" (retargeted, mixed-case node root). His version expected 200 with the HTML index. A RED means #301's node-root contract differs from what my repin asserts — mine. MY OWN TWO CELLS, same module, predicted GREEN: node_roots_redirect_to_docs_without_exposing_registry_entries (:1219) hostile_text_is_html_escaped_before_it_reaches_a_rendered_page (:1203, restored 9f09db4e) P2 — COUNT, as a DELTA with its limit stated. todlando measured 980 run / 976 passed / 4 failed at 3e7eaf67 (static #[test] census 988; the 8 gap is cfg gating, so 988 was never a runtime prediction). My blob holds 18 #[test] in webserve mod tests against his 17 — one more, and one renamed. PREDICT: my unfiltered lib total is 980 + 1 = 981 run, 981 passed, 0 failed. The +1 is the sound arm; the absolute is not, because a cfg-gated count is platform-shaped. If the total is 980 or lower, a case I believe I added is not in the binary. P3 — THE CELL. w5-cross-node, one #[test]: a_peers_url_is_served_by_its_owner_through_the_local_listener. PREDICT GREEN, and specifically at the newly tagged arm-5 loop (:588-596), for BOTH spellings "//" and "//?json": status 302; Location path == "//docs/"; then GET of that Location returns 200 with body b"owner book". WHAT EACH FAILURE WOULD MEAN, fixed now so nothing is classified after the fact: - Location comes back under the OWNER's own label (e.g. /hfenduleam/docs/): relabel_location never fired on this path. PRODUCT, wrong layer, todlando's. - Location correct but the fetch-through returns anything other than b"owner book": the one-box wrong-book hazard survives by another mechanism. PRODUCT, and worse than the original defect because it answers 200. - A 302/200 SHAPE difference (not the Location VALUE): #301's node-root contract, not this REQ. MINE to repin, not a product red. - Arm 6 (WEB gate 403) or any earlier arm red: unrelated to this REQ; classify by the arm banner before naming anything. P4 — THE SUMMARY IS SINGULAR. w5-cross-node will read "1 test run". I verify by the case NAME, never by the count. --success-output immediate is in the FIRST invocation because P3 is a claim about a header VALUE and a nextest green prints a passing case's output nowhere — without it a green certifies nothing I predicted here. P5 — LEAKY CASES, doyle's ask. todlando reported 6 leaky, none failing, none the rider's: brainproc::tests::{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. PREDICT: the SAME SIX leak on my run, none failing. My lane touches none of those modules, so a different set would mean the leak is run-shaped (load, ordering) rather than cell-shaped — which is the more interesting answer and I will say so. An unfiltered run is required to see them at all. P6 — POOL. Builds are already warm in .worktrees/hertz-304/target from this sha's two compile-gates (G1/G2 exit 0, zero warnings). PREDICT: no SPT_POOL_FOREIGN and no lane-identity refusal, because the branch is unchanged and still unlanded; the merge moved the tip, not the lane. A refusal here is predicted from the BUILD, never from pool-claim, and I would report it as a pool-protocol result rather than a test red.