doyle → todlando. FORKPTY RE-RUN VERDICT: KEYSTONE WORKS. a_journaled ✅ (attach_received_pty_output=TRUE, was FALSE) + p0_paste ✅ (attach_received_output=TRUE). Phase B 87 pass / 3 fail (was 5). The viewer trio is GREEN. Remaining 3:

1. wedged_viewer_does_not_stall_controller (attach.rs:1071) — NOT a viewer issue. It's a CONTROLLER-path b4 SIDE-EFFECT. The test: ctrl drives a 200KB burst, a wedged viewer never reads; line 1071 `ctrl.read_event()` (the CONTROLLER) fatals on `output gap got 6134 want 4643`. MECHANISM: b4 made the controller a non-blocking try_send that DROPS frames on a full channel (within CONTROLLER_WRITE_DEADLINE). Pre-b4 the inline sleep-poll BLOCKED the drain to the controller's rate → no drops → no gaps. Post-b4 a controller that falls behind its own echo drops frames → forward gap → the controller brain's STRICT reject-gap (B2) FATALS. CONFIRM vs a pre-b4 run (repro-first) but the mechanism is clear: b4's drop-don't-block introduced controller gaps.
   - Controller CANNOT snap-above (B2: it advances delivered_through; skipping rolled frames = not-exactly-once). So the viewer-snap fix does NOT apply.
   - DESIGN DIRECTION (gate, not committed): the controller on an output-gap must RESUME-FROM-FLOOR — re-subscribe from delivered_through (the FROZEN contiguous cursor, b4's contiguous_advance) so the broker RE-FETCHES the dropped frames from the ring. EXACTLY-ONCE preserved IF the ring still holds them (it should — the controller dropped them recently, delivered_through froze at last-contiguous, the ring floor is below that). This is b4's OWN stated "slow controller falls behind the ring → resume-from-floor reconnect" case, made to work mid-stream instead of fataling. RE-FETCH (resume), NOT skip (snap) — that's the B2 distinction from the viewer.
   - OPEN B2 QUESTION I must gate: can delivered_through-resume ALWAYS re-fetch the dropped frames, or is there a ring-roll window where they're gone (then it IS a B2 violation / unrecoverable)? Need the ring-floor vs delivered_through invariant. If the ring can roll past delivered_through, we have a harder problem (controller too slow + ring too small). Repro-first: capture delivered_through vs ring-floor at the gap.
   - Also: the TEST uses a raw ctrl.read_event(); production controllers run serve_attach. Does serve_attach's controller path resume on a gap or propagate the fatal? Read that too — the fix may be serve_attach-side (resume on gap) + the test updated to model it.

2. w5_a2 — STILL Some(None) (conn-close-evict, as predicted). RULING CONFIRMED: flip the test to assert clears-on-conn-close = CORRECT self-heal; defer true no-FIN half-open to REQ-HAZARD-DRIVEN-BY-IDLE-REMOTE-EVICT (presence oracle, unstageable on loopback). You cut the flip.

3. g2 — op_flushed=false + raw_fallback=false, delivered=TRUE. SEPARATE subsystem (REQ-MSG-IDLE-TRANSLATION-BINARY, W2 commit-deadline floor), NOT the viewer-drain. The floor isn't releasing/flushing buffered keystrokes under the forkpty echo timing, OR output_contains_within (a raw legacy-reject-gap brain.attach) gaps. Separate reconcile — does NOT gate the viewer-drain fold.

PRIORITY: wedged_viewer is the real remaining viewer-drain-MILESTONE blocker (b4 caused it). Repro-first the controller-gap (delivered_through vs ring-floor at the gap, serve_attach controller resume-vs-fatal) before designing. w5_a2 flip you can cut now. g2 is separable. I'm reporting scope to the operator. Ping with the wedged_viewer repro data.