hertz — predictions filed BEFORE the run, tip 61bfd85c, 2026-09-11.
One line per case, each with the reason it rests on, so a wrong one is diagnostic.

== crates/spt-daemon/tests/webserve_e2e.rs (producer 3) ==

1. production_listener_routes_nodes_docs_and_live_registry_references  -> GREEN
   Repinned at 4823ae5d. Node roots (bare, cased, ?json) assert 302 to /local/docs/
   and follow to the book bytes; the corrupt-registry 500 moved onto a file URL.
   Rests on: node root with empty remainder redirects to /<node>/docs/ carrying the
   query (webserve.rs resolve_path, remainder.is_empty() arm).

2. subnet_node_labels_shadow_only_the_docs_compat_alias_while_members  -> GREEN
   Read line by line. It never touches the index or the ?json twin. Its redirects are
   BARE-NODE ones — "/LoCaL" and "/ClI" without a trailing slash -> 302 to "/local/"
   and "/cli/" — which is the redirect_node arm, NOT the node-root-to-docs arm, and
   #301 did not change it. Everything else is peer 502s, alias bytes and content-type
   equality on surviving surfaces.
   Rests on: bare_node (no '/' in the path) still redirects to /<node>/ .

3. production_listener_exposes_only_the_adapter_web_root_through_both_urls -> GREEN
   Repinned at 4823ae5d. Was red by construction before that: it asserted GET
   /local/?json == 200 and then parsed entries[0].url and alias_url out of a body that
   is now a 302. This is the case doyle marked UNKNOWN; it was answerable from source.
   Rests on: removing the single registry entry kills BOTH prefixes, which is the
   one-exposure-two-URLs claim the index row was standing in for.

4. production_listener_redirects_directory_roots_before_serving_relative_links -> GREEN
   Read line by line. Directory-root redirects with ?view=Full preserved, then the
   relative child fetch. redirect_directory is untouched by #301, and query
   preservation is the same helper the node-root redirect uses.

5. the_adapter_docs_facet_serves_over_the_production_listener -> GREEN
   Read line by line. Only /local/a/cc/docs/... and /local/a/cc/report.txt — the
   adapter docs facet and the core-owned web root beside it. No node root, no index.

== crates/spt/tests/attach_link_push_e2e.rs (producer 4) ==

6. attachment_frames_reach_a_linked_shell_through_the_real_daemon -> GREEN, LOWEST
   CONFIDENCE OF THE SET, and I would rather name the doubt than post a clean guess.
   The clause now ends a REAL `spt rc` viewer by piping ordinary keys plus the ctrl-b d
   chord into its stdin and asserting exit 0 then removal, instead of killing the
   process. The load-bearing assumption is that a piped (non-console) stdin reaches
   rc's BYTE reader rather than its Windows key-event path. rc supports both — the unit
   set has viewer_byte_detach and viewer_event_detach as separate cases — but which one
   a pipe lands on is not something I have measured end to end.
   IF IT REDS: expect a timeout or a non-zero exit with the viewer still present, and
   the first thing to check is whether the real binary took the console-event path on a
   pipe. That would be a test-side defect (wrong input channel), not a product one.

== crates/spt/tests/webserve_cross_node_e2e.rs (producer 5) ==

7. a_peers_url_is_served_by_its_owner_through_the_local_listener -> GREEN
   Two real daemons, one SPT_HOME each, relay disabled and peer_pump false, rig-owned
   subnet seed. The remote root and its ?json twin follow a 302 to the OWNER's docs; a
   WEB-denied root refuses 403 with no Location; a local root still redirects.
   Rests on: the peer arm proxies to the owner, which authorizes and redirects to its
   own docs — the arm the unit case peer_paths_proxy_by_facet... covers and which ran
   green in the 22/22.

8. the serve_add helper's bound-port arm (same binary) -> GREEN, SECOND-LOWEST
   CONFIDENCE. The helper now takes the bound port AND the other node's port, points
   the client's DOCS_PORT_ENV at the OTHER owned port, parses the URL the command
   actually emitted, and fetches its own bound port byte-equal. That is the whole point
   — a URL minted from configuration would fetch the wrong node's bytes and still look
   plausible — but it means the case fails if discovery resolves to the wrong node
   rather than merely returning a wrong number, and the failure would read as a byte
   mismatch rather than as a port bug.
   IF IT REDS: compare the emitted URL's port against both owned ports before assuming
   the fetch is at fault.

== NOT PREDICTED ==

crates/spt-daemon/tests/twohost_web.rs — env-gated on SPT_TWO_HOST=1, a two-machine
rig. Compile-gated only in this window. LABELLED HOLE, closed by the #297 two-machine
leg in W2. No prediction is possible from one box and none is offered.

== ADDENDUM, filed 2026-09-11T09:58Z, still BEFORE any build or run ==
== crates/spt/src/rc.rs (producer 2, -p spt --bins) ==

The main filing covered producers 3-5 and left producer 2 unpredicted. That was a
hole in my own filing and I am closing it before the window, not after, from source
at 61bfd85c. All five rest on the same helper, viewer_detach_preserves_session
(rc.rs:4177), which the observer deletion at 1fa4858e rewrote.

9.  rc::tests::viewer_byte_detach_keeps_controller_and_child   -> GREEN
    This is the case that was RED for three shas. Root cause settled: a StreamLog
    holds ONE subscriber seat, so the spectator subscription both barriers waited
    on could never be served. 1fa4858e deleted the observer and asserts absence BY
    CONSEQUENCE. What remains in the helper has no unserved channel in it: every
    read is read_event_until(Some(deadline)) with a 10 s bound, and connect() is
    Brain::cold_start_pump (rc.rs:4199), which SETS io_timeout - so the unbounded
    cold_start read that hung todlando's arms (brain.rs:459/542 vs :497) is not
    reachable here. Predicted GREEN at ~10 s, not a timeout.
    IF IT REDS: the discriminator is WHICH assertion. A panic at the Displaced /
    Exit arm (rc.rs:4344) means the viewer really did move the controller and the
    product claim is wrong. A panic at "viewer never rendered live output" means
    admission, not detach, and is a rig fault. A 240 s terminate-after means I am
    wrong about cold_start_pump and the unbounded-read class reaches this file too.
10. rc::tests::viewer_event_detach_keeps_controller_and_child  -> GREEN
    Same helper, windows-gated, different producer of the message vector
    (key_event_step, not parse_stdin_chunk). It shares every risk above and adds
    none: it synthesizes KeyEvents directly and never touches crossterm's reader.
11. rc::tests::detach_keybind_semantics                        -> GREEN
12. rc::tests::detach_prefix_spans_chunks                      -> GREEN
13. rc::tests::key_event_step_detach_sm                        -> GREEN
    Three pure parser cases, no broker, no PTY, no attach. 1fa4858e touched the
    helper, not the parsers. They were already passing inside the 3-passed-1-failed
    of the 9f09db4e run; fail-fast cancelled the fifth, which is why this run adds
    --no-fail-fast (disclosed in the START).

INSTRUMENT CHANGES THIS WINDOW, disclosed before the run:
 a. run producers now pass --no-fail-fast. At 9f09db4e a red in case 4 CANCELLED
    case 5, and a cancelled case is a labelled hole, not a pass.
 b. inventories now enumerate the WHOLE target (no -E) and are discharged by a
    both-directions diff. A filter-matched count cannot see a case the filter does
    not name; that miss cost me twice today.
 c. producers 4 and 5 run under profile `default`, not ci-windows, because both
    binaries are in this repo's <HEAVY> kind(test) set which ci-windows
    deliberately does not carry (.config/nextest.toml:423-437). Each producer runs
    one case, so the group's serialization is moot either way; the profile is
    matched to CI's for those binaries rather than to convenience.