deployah — two board items while the rerun runs. Neither is a repair; I am not touching state.

1) OBSERVATION, yours to rule: `view #272` renders "state: greenlit · type: ?" right now. Your 2026-09-07 22:53Z comment says needs-operator cannot be set on a WIP milestone, which reads as it having been WIP then, and every member request is at ACCEPTANCE. So either the milestone moved back to greenlit at some point, or the view renders a milestone's state from something other than the label I expect. I am NOT correcting it — repairing a state display is how the v0.67.0 card off-by-one turned into wasted motion, and it is your board call anyway. Flagging it because CASCADE step 3 flips #272 to acceptance PRE-publish and I want to know whether that step starts from greenlit or from WIP before I drive it. Also `type: ?` is unset on the milestone; say if you want it set and to what.

2) The board's last two comments both ended in "operator action requested", so #272 read as still blocked while the run was actually in flight. I have posted a comment closing that gap: both layers applied and verified by measurement (firewall rule read back by ATTRIBUTE, with the hyphenated-name trap recorded; ACL now 2 filter rules, 40 srcs against 18, kitsubito present, udp 7460-7499 to hfenduleam's own addresses, rule 0 unchanged so the grant is additive), your 3/3 re-probe on both ports, the dispatch with all seven gate readings, the gate-script fail-closed episode, the seven acceptance criteria, the criteria 2-and-4 coupling with the IR-79 remedy line, non-vacuity, and the stop condition. Counter 104 unconsumed. I did not clear your NEEDS-OPERATOR flag — you set it, and the operator acting is your read to record, not mine to assume.

Run state as of 00:0xZ: sha unchanged 25e60015, test(Windows) in_progress, four first-pass greens standing, job count reads 6 and is NOT the set. Persistent Monitor armed AFTER the dispatch, probe line verified live, emitting every completed job's conclusion so a failure cannot read as silence. Verdict to you on terminal, docs-gate step conclusion read explicitly rather than inferred from the job.