hertz — EXCLUSIVE EXECUTION WINDOW CLOSED. END 2026-09-11T09:03:30Z, 6m04s, well inside the 09:18Z bound. All three producers ran; nothing of mine is executing. todlando, your #230 integration cell is unblocked — go. doyle, the push hold can lift as far as I am concerned.

END census: C: free 195,463,700,480; my pool 16,751,858,441 bytes / 17,025 files, 0 unreadable; ZERO builders on the box at close; zero survivors from every producer.

RESULTS at a17dbfbd — 1 GREEN, 2 RED, and I am not dressing either red up:

1. spt-daemon --lib, exit 0, 14.39s wall / 0.225s nextest. 21 TESTS RUN, 21 PASSED, 961 skipped. The 1011 fix holds and node_routing_reserves_facets_without_registry_fallback now passes on status AND Location. All six #297 cases green again. This one is done.

2. spt --bins (rc detach), exit 100. 4 of 5 run: 3 passed, 1 FAILED, 1 NOT RUN (nextest fail-fast, so that fifth is an absence, not a pass). FAIL rc::tests::viewer_byte_detach_keeps_controller_and_child at rc.rs:4299, 10.179s: `client wire event: Custom { kind: TimedOut, error: "brain IPC read deadline elapsed" }`. That line is a 10s wait for NetStreamEof on the observer's peer stream after the viewer detaches.
   NOT LOAD, and here is the discriminator rather than a hunch: every earlier phase in that cell completed in milliseconds — session-detach at mono_ms=65, writer-exit same millisecond, row_inserted at t_ms=18. A box too slow to finish in 10s would have been slow in those phases too. It was not slow; ONE await never completed while everything around it was fast.
   WORKING HYPOTHESIS, stated as a hypothesis: the broker log shows STREAM_CONNBOUND_RETIRE for stream 2 only. The viewer rode conn=5 on stream 1, and stream 1 also has conn=4 attached. If EOF is bound to the OPENER conn's exit rather than to the viewer's detach, then stream 1 never FINs while conn=4 lives, and my "protocol barrier, not a timing window" comment at 4293 is simply wrong about the direction EOF travels. That would make this MY test-design defect, not a product bug. I have NOT confirmed it — confirming means reading the stream-retire path, which is source work and needs no window.

3. spt-daemon docs_server_e2e, exit 100, 0.050s. FAIL serves_published_surface_and_refuses_escapes_and_writes at docs_server_e2e.rs:88: `left: InvalidData, right: Other`, message "listener unavailability must not permit offline fallback: SERVE_UNEXPECTED_REPLY: error".
   This one is fast and deterministic, and it may be a PRODUCT finding rather than my expectation being wrong. I asserted ErrorKind::Other because every arm of servehost::docs_port builds its error with io::Error::other — DOCS_LISTENER_UNAVAILABLE, the Refused passthrough, and DOCS_LISTENER_UNREPORTED alike. What actually came back is InvalidData carrying "SERVE_UNEXPECTED_REPLY: error", which is raised INSIDE call() before docs_port's match is ever reached. If a live broker with no docs listener answers with an error envelope rather than DocsStatus{port:None}, then the UNAVAILABLE-versus-UNREPORTED distinction that REQ-WEB-URL-BOUND-PORT turns on never gets made, and the caller is handed a generic transport complaint instead. That is worth more than a test edit. I am diagnosing before I touch either side.

NO RETRIES TAKEN, no test edited, no product touched since a17dbfbd. Both reds keep their real exits, raw output and observations under .spt/preserved/hertz-304-w1-c468e9df/. Next from me is the classification of each red, and I will not propose a fix for either until I can say which side is wrong and why.