doyle 08:13Z — W2 GATE FINDINGS, batch 2 (reader C: audience, helper, F1, twohost cells; blocking item verified by my own read). This is the last batch; push once when both are in.

BLOCKING
F9. THE HELPER CELL NEVER SERVES THE WAN FAMILY — and it explains attempt 5. twohost_web.rs:577-581 names the cell's BROKER `seed_socket_name()` (right, request_quoted_paths dials it), but the DISPATCH LOOP started in the same cell at :782 still uses `format!("spt-twohost-web-a{HELPER_OFFSET}-{pid}")`; `run_dispatch_loop_observed` connects to that name first thing (dispatch.rs:698), nothing binds it, the error is swallowed by `let _ =` in the spawned thread (:790-799). So the WanMsg family is never served, receive_wan never runs, the helper request is never fired — B's six "peer unresponsive" dials and the silent seventh are the symptom, and attempt 4 (old name on BOTH) reached ADMITTED for exactly this reason. Fix = one line: :782 uses the same `broker_name` the cell bound. RULING REVISED: after the fix, re-run the local pair ONCE (arm none, ~5 min); attempt 4 proved the round trip happens on one box in the seeded-gateway shape, so if the helper cell goes green here it is WITNESSED on one box and the PR body says so; if it still times out at (vi) with the loop served, the "unwitnessed by construction" sentence stands and I climb it cross-box. Either way the record says which.
F10. `audience_admits` (spt-store serving.rs:599) has NO production caller — the shipped narrowing is `node_hosting_endpoint` at webproxy.rs:195-201/:423. Its unit cell (:1164) therefore covers no shipped path, including its loopback assertion (:1181), which is the ONLY "loopback admits regardless of audience" cell in the tree. Fix: delete the dead predicate + its cell (one path, like the spool trio), and add a loopback cell on the SHIPPED path — webserve.rs handle_path serving an audience-scoped entry on loopback → 200. Doc sentence (serving/overview.md:168-171) then has evidence.

TEST GAPS (same push)
F11. Deny-body BYTES: ARM 6 and 6b both assert the prefix "ACCESS_DENIED: WEB: "; the REQ says compare the bytes so the registry is not an oracle. Capture both bodies, assert equal (one `deny_message()` makes it true structurally; measure it anyway, one assert).
F12. Guards bundled: exists+anchored+dedup+cap live in ONE cell (nowsignal.rs:1470) and anchored+cap+dedup in one (helperline.rs:202). Split to one cell per guard (four small cells), and add the DIRECTORY case through the helper path (`AddScoped` has zero tests: a quoted dir → dir entry with the 24h/audience/origin).
F13. `spt serve list` human rendering of audience beside ttl/origin (serveverb.rs:85-96) has no cell — one unit cell on print_entry.

ACCEPTED as read: enforcement keyed on the broker table's remote_id_hex (dispatch.rs:749, "handshake-proven, never payload"), same deny_message() as the WEB rule; loopback path carries no audience check + docs state it; trigger (a) verbatim envelope URL (nowsignal.rs:715); trigger (b) AddScoped → add_reference + scope_entry in one locked pass, 24h/origin=short-id/audience=target (wan.rs:1077-1113); same-node registers nothing; delta keys via seen.take_new; ONE writer of the attachments attr (cli.rs:11507), helperline carrier in the perch (helper-fetch.jsonl, KEEP_LINES 256, torn tail closed :72-79) — note there is NO time-based expiry on helper lines, only line-count trimming: state that in the docs sentence or add at_ms expiry, your call, say which; ingress caller unconditional after deliver_admitted on its own thread (wan.rs:1038, cells :2313/:2358/:2390); serve_for refusals in order (a)(b)(c)(d) with deny_message() on the first three; F1 predicate pure, takes the row's own envelope type, called at :458 not bypassed, FIVE conjunct cells + two lookup cells by name; F1_ARM=iii present in cross_node (:714-770) asserting helperline empty AND registry unchanged; (vi)/(vii) in twohost_web :436-482/:842-852 — label them F1_ARM=vi / vii in their breadcrumbs so the raw reads the same across binaries; api.md delegates to frames.md, which carries FILE_ACCESS_HELPER — not a docs finding, my plan item was mis-targeted.