What happens
A lane parked at a no-mistakes validation gate is correctly waiting on a human decision, but the watcher reads its silence as a wedge and escalates. The escalation repeats indefinitely, and each one costs the supervising firstmate a full turn.
Observed counts on a single home: one correctly-parked lane reached 671 consecutive wedge escalations, and another reached 70 before it was noticed.
Why the existing mitigations do not cover it
- A declared
paused: status does nothing for a live ordinary crewmate. pause_state_class falls through to none for a non-secondmate live agent, so the declaration is inert exactly where it is needed.
bin/fm-control.sh <id> exit on a finished lane does not reduce alerts either: the watcher treats a stopped agent like an idle one.
- Upstream b57c4d6 fixed the BUSY-pane sibling case only. The parked-at-gate case is still live as of
4179c50.
Current workaround
FM_STALE_ESCALATE_SECS and FM_PAUSE_RESURFACE_SECS are read by both the watcher and the away daemon, so raising them widens the window. This is confirmed in the daemon's stale_escalate= startup log. It is a blunt instrument: it delays genuine wedge detection by exactly the same amount.
Suggested direction
The watcher already has enough information to tell the two cases apart: a lane whose current run-step is a parked gate awaiting a human decision is not silent-because-wedged, it is silent-because-waiting. Treating a verified parked-at-gate state as a declared wait, on a long recheck cadence rather than a wedge escalation, would remove the noise without weakening real wedge detection.
Related: bin/fm-captain-hold.sh complete can write a captain-held [key=...] status line that the classifier does treat as a declared wait, which works well when it succeeds. That path is currently blocked in one common case, filed separately.
Environment
firstmate at 4179c50, tmux backend, claude harness.
What happens
A lane parked at a
no-mistakesvalidation gate is correctly waiting on a human decision, but the watcher reads its silence as a wedge and escalates. The escalation repeats indefinitely, and each one costs the supervising firstmate a full turn.Observed counts on a single home: one correctly-parked lane reached 671 consecutive wedge escalations, and another reached 70 before it was noticed.
Why the existing mitigations do not cover it
paused:status does nothing for a live ordinary crewmate.pause_state_classfalls through tononefor a non-secondmate live agent, so the declaration is inert exactly where it is needed.bin/fm-control.sh <id> exiton a finished lane does not reduce alerts either: the watcher treats a stopped agent like an idle one.4179c50.Current workaround
FM_STALE_ESCALATE_SECSandFM_PAUSE_RESURFACE_SECSare read by both the watcher and the away daemon, so raising them widens the window. This is confirmed in the daemon'sstale_escalate=startup log. It is a blunt instrument: it delays genuine wedge detection by exactly the same amount.Suggested direction
The watcher already has enough information to tell the two cases apart: a lane whose current run-step is a parked gate awaiting a human decision is not silent-because-wedged, it is silent-because-waiting. Treating a verified parked-at-gate state as a declared wait, on a long recheck cadence rather than a wedge escalation, would remove the noise without weakening real wedge detection.
Related:
bin/fm-captain-hold.sh completecan write acaptain-held [key=...]status line that the classifier does treat as a declared wait, which works well when it succeeds. That path is currently blocked in one common case, filed separately.Environment
firstmate at
4179c50, tmux backend, claude harness.