Away mode: recognize parked usage-limit and update menus, clear them safely, and audit every clear #33
Loading…
Reference in a new issue
No description provided.
Delete branch "fm/fm-modal-aware-recovery"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What was wrong
Workers that hit a harness menu sat there indefinitely while looking alive. A Claude usage-limit modal ("1. Stop and wait for limit to reset / 2. Upgrade your plan …") or Codex's self-update prompt parks the worker until someone presses a key. On 2026-08-16 two Claude workers sat on that menu for about 15 hours, through two window resets, and endpoint liveness reported them healthy the whole time.
What changed
quota-axiread confirms the five-hour window has actually reset below the threshold. It never selects an upgrade or purchase option. A test proves it.state/<task>.recovery-log, never in the task's status log, per the captain's decision A (09/23). A worker whose last state was done, paused or waiting on a decision keeps exactly that last line, and a test proves it. Each clear is still surfaced through the normal escalation digest, so it is never silent.Validation
The no-mistakes pipeline passed at
3044be5. Its review round anchored the detector, fixed C-locale matching and shared the quota reads. There are fixtures for the Claude modal, the Codex update prompt and a clean busy pane, plus new daemon tests. An earlier pushed head wrote the recovery event into the status log (option C). It was sent back before any PR was opened, and this head is the corrected one.Open
Nothing. This is the firstmate repo, so there is no Plane story. It overlaps
bin/fm-supervise-daemon.shwith #32 (away-mode watcher handoff); whichever lands second rebases.