What
`.afk-return-catchup` (session state) records a lifecycle blocker per live task at the moment a
return catch-up opens: "status file unreadable: state/.status; catch-up stays gated". If that
task later finishes normally and is torn down (`bin/fm-teardown.sh`, which removes its `.status`
and `.meta`), the stale evidence line for it is never cleared - `fm-afk-return.sh check` keeps
reporting the same "status file unreadable" line for a task that no longer exists anywhere in the
backlog or state dir, forever, blocking every future away-mode re-entry.
Reproduced 2026-09-14 (jpc-wsl)
- Away-mode return opened a catch-up gate that included `fm-image-cutouts-deliver` (in-flight at
the time) among its lifecycle blockers.
- `fm-image-cutouts-deliver` finished normally minutes later (PR merged, task torn down - no
`.status`/`.meta` file left anywhere).
- Roughly 40 minutes and many ordinary wakes later, attempting to re-enter away mode
(`fm-afk-launch.sh propose`) refused with "return catch-up is still pending". `fm-afk-return.sh
check` still listed the exact same stale line for the long-gone task, alongside a fresh, correct
one for a task that was genuinely still starting up.
- Workaround used: deleted `state/.afk-return-catchup` entirely (private session-scoped state, safe
to discard) and re-ran `check`, which rebuilt clean evidence from the currently-live task set and
cleared immediately.
Suggested fix
`fm-afk-return.sh check` (or whatever owns `.afk-return-catchup`'s evidence lines) should drop a
lifecycle blocker for a task id that no longer has a `state/.meta` at all, rather than treating
"status file unreadable" as permanently unresolved. A torn-down task cannot ever produce a readable
status file again, so the current behavior makes the gate un-clearable without a manual file deletion
every time this sequence occurs (any away-mode session where a task finishes and tears down while
its return catch-up is still open).
Impact
Not destructive, but blocks all away-mode re-entry until manually worked around - would have kept
Julius from going properly afk tonight if the workaround hadn't been found.
What
`.afk-return-catchup` (session state) records a lifecycle blocker per live task at the moment a
return catch-up opens: "status file unreadable: state/.status; catch-up stays gated". If that
task later finishes normally and is torn down (`bin/fm-teardown.sh`, which removes its `.status`
and `.meta`), the stale evidence line for it is never cleared - `fm-afk-return.sh check` keeps
reporting the same "status file unreadable" line for a task that no longer exists anywhere in the
backlog or state dir, forever, blocking every future away-mode re-entry.
Reproduced 2026-09-14 (jpc-wsl)
the time) among its lifecycle blockers.
`.status`/`.meta` file left anywhere).
(`fm-afk-launch.sh propose`) refused with "return catch-up is still pending". `fm-afk-return.sh
check` still listed the exact same stale line for the long-gone task, alongside a fresh, correct
one for a task that was genuinely still starting up.
to discard) and re-ran `check`, which rebuilt clean evidence from the currently-live task set and
cleared immediately.
Suggested fix
`fm-afk-return.sh check` (or whatever owns `.afk-return-catchup`'s evidence lines) should drop a
lifecycle blocker for a task id that no longer has a `state/.meta` at all, rather than treating
"status file unreadable" as permanently unresolved. A torn-down task cannot ever produce a readable
status file again, so the current behavior makes the gate un-clearable without a manual file deletion
every time this sequence occurs (any away-mode session where a task finishes and tears down while
its return catch-up is still open).
Impact
Not destructive, but blocks all away-mode re-entry until manually worked around - would have kept
Julius from going properly afk tonight if the workaround hadn't been found.