hertz -> doyle, todlando. CONFLICT RESOLVED ON PAPER FROM THE BYTES + A PREDICTION FILED AGAINST TODLANDO'S STEP-2 RUN. Git reads only, no build, no checkout touched, box untouched.

0. MERGE TARGET AND STABILITY, asserted by BLOB not by reasoning. merge-tree HEAD(ec1e4737) x 3e7eaf67 gives the same three conflict stages as against 023de52a, byte-identical oids: base bcc0eaf3, ours 29f4d7ef, theirs 798ef40c. One conflicted file, webserve.rs, content; windows.rs and rc.rs auto-merge. So todlando's fixup does not touch this conflict and the resolution below is valid at 3e7eaf67. Both hunks sit inside mod tests, consistent with his own measurement.

1. THE RULING'S FRAMING NEEDS ONE CORRECTION, and it changes the resolution. Doyle described hunk A as "his added JSON-facet assertions against your deletion" and hunk B as carrying "new JSON entry asserts". Read with diff3: THEIRS IS BASE, character for character, except the port argument dropped from handle_path. todlando authored no JSON assertions in either hunk. They are base's, and they have been stale since a4017a15 -- his commit only repaired their arity, which is exactly the IR-101 mechanical fix and says nothing about whether their subject still exists.

2. YOUR INSTRUCTION WAS "CARRY HIS JSON ASSERTIONS THAT DO NOT DEPEND ON THE RETIRED INDEX". THAT SET IS EMPTY, and both hunks resolve to OURS. Every JSON assertion in both hunks calls handle_path(..., "/local/", Some("json"), ...) -- the registry index's json twin, which a4017a15 retired. Traced the router at 3e7eaf67 rather than trusting the retirement note: for "/local/" both reachable arms (bare_node, and the empty-remainder arm) return redirect(...), and redirect() at webserve.rs:253 sets ONLY a location header, status FOUND, EMPTY body, with the query appended to the Location. So against current product those cells do not fail an assert, they PANIC: from_slice(&body).unwrap() on an empty body, and headers()["content-type"] indexing a header a 302 never carries.
   Nothing is lost by taking ours. My hunk-B repin already loops [None, Some("json")] x [false, true] and asserts FOUND + a /local/docs/ Location + an empty body -- the json query's live behaviour is asserted, not dropped. And the escaping coverage in theirs runs through the retired node-root HTML index; the live escaper is the message facet, which is where 9f09db4e already put that coverage. Taking theirs would re-introduce a dead-subject assertion -- IR-101's drop-coverage mechanism running backwards.

3. PREDICTION, FILED BEFORE THE RUN, FOR STEP 2 (todlando's spt-daemon --lib at 3e7eaf67). Three cells in webserve.rs mod tests will FAIL, and NONE of them is the rider:
   - adapter_facet_and_disambiguated_alias_share_one_contained_reference -- panics at serde_json::from_slice(&body(response)).unwrap(), "EOF while parsing a value", on the 302's empty body.
   - index_escapes_html_encodes_urls_and_reports_real_source_paths -- panics indexing headers()["content-type"] on a 302.
   - node_roots_redirect_to_docs_without_exposing_registry_entries -- fails earliest on the retired HTML index body assert (html.contains("source & quote.txt")); behind it the node-root OK-vs-FOUND assert and the same content-type panic.
   Mechanism, stated so a red does not get re-diagnosed: these have been red since a4017a15 retired the index, in HIS lane only. They are green in mine because my #304 rewrite retargeted them, which is why producer 1 read 22/22 at 9f09db4e. Per-lane green is silent about the other lane -- IR-101, now in the reverse direction. If they come back green, my resolution above is WRONG and I want to know before I merge, so this is a real discriminator and not a courtesy.
   What should be GREEN in that run: the four new docshost cells, the renamed webproxy cell, and everything else that was green at HEAD~1. todlando's arm-0 deliberate red is separate and his.

4. MY OWN NEAR-MISS, since it is the same defect I just registered. My first read grepped "json" in webserve.rs, saw a live json branch at :476-488 still emitting entries, and I was one step from telling you the index twin SURVIVED and my deletion had dropped live coverage. It had not: mapping function boundaries put :476 inside fn message (453-522) -- the MESSAGE facet's json twin, which is live and which neither hunk touches. A grep hands you a line; only the enclosing function says what the line means. That is IR-105's rule catching IR-105's defect one hunk after I wrote it down.

5. TODLANDO'S ITEM-4 UPGRADE IS BETTER THAN MY NIT AND I WANT THAT ON RECORD. I offered the protocol-relative case as unreachable-because-redirect_directory-collapses-slashes. He hardened the guard instead and gave the reason: that protection lives in the PEER's function, in a separate build on a separate machine, so a relay depending on it is lucky rather than guarded. Correct, and it retires the weakest sentence in my review.

6. WHAT I WILL DO AT STEP 3, no surprises: merge 3e7eaf67 into test/304-remote-friction; resolve webserve.rs by taking OURS at both hunks (not "keep-both" -- the carry set is empty, per item 2), which makes the resolved blob equal my current blob 29f4d7ef and I will assert that by oid rather than by eye; add [int->REQ-WEB-PROXY-LOCATION-NAMESPACE] at webserve_cross_node_e2e.rs:592 as one line; then compile-gate --lib --no-run and the cross-node cell --no-run in my own pool. Predictions for step 4 filed against the merged sha before that build, never before the merge exists.
   Doyle: item 2 changes your resolution from keep-both to take-ours. Say if you want it otherwise and I will follow your word, but I am not merging on my own reading of a ruling I think needs amending.

Nothing running. Box still CI's. Standing by for your word.