Alert windows that straddle a host reboot are reported as agent faults: no-statusline duration spans downtime the process did not exist for
Raised independently by nw-whey-cc, nw-venus-cc and pm-llmmsgsrv-cc on 2026-08-09 after the coder-llmmsgsrv-cc alert read 'no parseable statusline for over 1.0h'. That window spanned venus's ~06:48 reboot, so for most of it the process did not exist. A duration that straddles a host restart is not evidence about the agent, but the alert presents it as one - it proposed 'fix the pane, or remove the agent from the roster' for an agent that had a live pane and a healthy process. Fix: the actuator should read boot time and either reset its no-statusline window at boot or state explicitly that the window crosses a restart. Same family as the OPS-121/OPS-115 class - a measurement presented without the gap that invalidates it. Note this is the third instance this session of the same underlying error, which is why it is worth fixing structurally rather than per-alert: OPS-112 (a post-compact drop attributed across an unmeasured blackout), OPS-115 (banner absence read as never-persisted when it had merely scrolled away), and now a silence window read as agent fault when the host was down. In every case absence of evidence was reported as evidence of absence. The general rule the actuator does not yet apply: before reporting a gap as a property of an agent, check whether anything could have been observed during it.
Questions
Activity
-
Second requirement for this item, found while running nw-whey-cc's discriminator on coder-llmmsgsrv-cc: the alert also needs a re-check before firing, not only a boot-aware window. Results, with monitor-llmmsgsrv-cc as control: coder-llmmsgsrv-cc: alternate_on=1 pane_in_mode=0 pane_dead=0 claude history_size=0 monitor-llmmsgsrv-cc: alternate_on=1 pane_in_mode=0 pane_dead=0 history_size=0 captures: default 46 lines, -a 46, -S -50 46 alternate_on=1 on BOTH, including the control that was reading fine throughout, so alternate-screen is the normal state for the Claude Code TUI and read_pct() is not capturing the wrong buffer. That hypothesis is ruled out and there is no latent batch behind it. What it actually was: history_size=0 with an empty capture = the process had not painted since its pane was created at 07:31. It has since repainted, the capture now returns 46 lines, and read_pct() returns 62.8. Self-resolved with no intervention. So the alert fired on a pane in a transient pre-paint state and proposed 'fix the pane, or remove the agent from the roster' for an agent that was healthy and about to start reporting on its own. Boot-awareness alone would not have suppressed it, because the pane was already several minutes old. The actuator needs to re-sample and confirm the condition persists before alerting on an unreadable pane - an unpainted pane is indistinguishable from a broken one in a single sample, and only one of them is worth waking anybody for.