todlando — WINDOW CLOSED. END 2026-09-11T10:18Z. Open 10:12Z -> 10:18Z, ~360 s against a 2400 s cap. Box FREE. Two producers, one attempt each, no retry. Free space 167.22 GiB at P2 admission; pool growth negligible (P1 compiled in 10.42 s, P2 rebuilt nothing).

P1 inventory+compile: EXIT 0. THE FIX COMPILES — first build of it, 10.42 s, no errors, no warnings surfaced. Both-directions diff on the WHOLE target: population 16, selected 1, named_but_absent EMPTY, present_but_unnamed 15 (INVENTORY for this allocation, not coverage).
P2 run: EXIT 100. 1 run, 0 passed, 1 FAILED in 10.205 s. NOT a timeout.

AGAINST MY FILED PREDICTION (prediction-fixed-cell.txt), every structural falsifier, measured:
  - distinct serve_stream per arm: HELD. arm 1 = 1, arm 2 = 3. Fix (a) took; the replay is gone.
  - NO timeout, red inside the bound naming its arm: HELD. Panic at attach.rs:1940, `operator read event: Custom { kind: TimedOut, error: "brain IPC read deadline elapsed" }`. Fix (b) took.
  - no session-detach before an arm's own echo: HELD. Arm 2 is seated (SUBSCRIBE_DECISION decision=controller) and STAYS seated. The unseating that looked like a lease defect is gone with the replay.
  - DISTINCT gen per arm: HELD — arm 1 gen=1789121605194, arm 2 gen=1789121605224, 30 ms apart and different. THIS WAS MY FALSIFIER FOR THE MECHANISM I WITHDREW, and it did not fire: the coarse-clock collision stays dead, and the identical gens really were one Request replayed. I am reporting this because I said I would say so if it came back, not because it helps me.
  - five ARM_OPEN/ARM_DONE pairs: FAILED. One pair. Arm 2 unpaired.
  - arm 1 GREEN: HELD (policies=-1, as asserted).
  - arms 2-5, no colour predicted: arm 2 now DRIVES THE WIRE for the first time and reds in its read loop BEFORE reaching its policy assertion. Precisely: arm 2 executed, arm 2's ASSERTION did not, and arms 3-5 still have never run. The advisory is still unmeasured on every identity-bearing arm.

CLASSIFICATION OF THE NEW RED — mine, test-side, and it is the SAME CLASS A FOURTH TIME:
The broker dedups a PTY write on `EffectKey { class: session_id, minter, op }` (effect.rs:299-303, applied at broker.rs:8797-8820 via `journal.apply_once(key, EffectKind::PtyWrite, ..)`). The helper sent EVERY arm's keystroke with a literal op id of 1 (attach.rs:1922). Same session, same minter, same op ⇒ arm 1 typed and was applied; arm 2's identical key hit the applied-set, the closure NEVER RAN, the PTY was never written, so the echo the loop waits for could not exist, and the arm correctly burned its 10 s bound. Arm 2 is seated and healthy the whole time — nothing about the seat, the stream or the policy is wrong here.
AND THE LESSON IS MINE TO OWN: when you classified #230 as "one Rc op seq reused across arms" I fixed the REQUEST op (2..6) and left the INPUT op at 1, one function away in the same helper. I fixed the INSTANCE the failure pointed at, not the CLASS the verdict named. Four re-entries of a retired/deduped id in one cell — op seq, spectator seat, served stream, now input op — and three of them were mine.
Note also `EffectKind` is NOT part of the key: a Request op and an Input op sharing an integer on one session collide with each other. That is why the fix below uses a disjoint range rather than reusing op_seq directly.

FIX WRITTEN, UNCOMPILED, UNRUN: `const INPUT_OP_BASE: u64 = 100; send_attach_input(.., INPUT_OP_BASE + op_seq)` ⇒ arms get 102..106, disjoint from Requests 2..6. The mechanism is recorded at the call site so the next reader meets it before re-deriving it.

PREDICTION FOR THE NEXT PRODUCER, filed now, before any build:
Arm 1 GREEN. Arms 2 and 3 reach their POLICY assertions for the first time — still NO COLOUR predicted, they have never been measured. Structural: five ARM_OPEN/ARM_DONE pairs, five distinct serve_streams, five distinct gens, no timeout, no session-detach before an arm's own echo. If arm 2 still reds on the read with distinct input ops, my dedup reading is WRONG and classification reopens — I do not get to assume the fourth fix is the last one.
A policy-assertion red on arms 3-5 is the first real measurement of REQ-ATTACH-CLIENT-STALE's advisory and classification starts there.

REQ-ATTACH-CLIENT-STALE int: still UNTESTED beyond arm 1. Unchanged by this window, and I am not claiming progress on the requirement — what advanced is the rig, not the evidence.

CENSUS CORRECTION, hertz's measurement over my declaration: my ~180 unreadable is MY READER (CIM ExecutablePath refuses protected processes), not the box — he measured 553 of 556 readable via psutil, 3 genuinely blind. My declared hole was real but I attributed it to the wrong subject. His own filter under-declared for a different reason and he fixed it. Nothing in my census verdict changes: both my controls read TRUE and the name-keyed arm covers the axis.

Asking for ONE more window for the fixed cell when the box frees — hertz has window 3 queued ahead of me, and doyle's producer-5 rider is mine after that. I will not re-run anything before then.