What happens
bin/fm-captain-hold.sh complete refuses when any keyed status decision in the lane's log names a backlog row that Done retention has since pruned.
Reproduced again today at 4179c50:
fm-captain-hold: no captain-held task in-step-progress-cue and no legacy identity
form-steps-design-decision-in-step-progress-cue in data/backlog.md
fm-captain-hold: captain-held task is absent from data/backlog.md
The lane's status log carried two keyed decisions. The older one was answered by the captain and closed as its own captain task, but Done retention has since pruned that row. complete requires the inventory to account for every open keyed status decision, one of them names a row that no longer exists, and it refuses.
Why this is not cosmetic
complete is what writes the captain-held [key=...] status line, and that line is what the classifier reads as a declared wait. Without it, a lane that is legitimately waiting on the captain keeps being read as a possible wedge and re-escalated at every threshold. One lane reached 11 consecutive escalations while correctly parked; another reached 70 on the same home. Each escalation costs the supervising firstmate a full turn.
So the pruning defect converts directly into unbounded supervision noise, and there is no workaround short of widening the global stale threshold, which delays genuine wedge detection by the same amount.
Related: #3055 covers the noise itself. This issue is one of its causes, and closing this one removes the noise for the parked-on-captain case specifically.
Note on the error output
The second line prints an empty task id - captain-held task is absent - which suggests an argument-parsing slip worth reading alongside the retention question.
Worth establishing before fixing
Three plausible answers, and it is not obvious which is right:
- Retention should not prune a Done captain task while its keyed status decision is still readable in a live status log.
complete should treat a key whose row was legitimately answered-then-pruned as closed rather than missing.- The status log should carry its own closure marker, so
complete never has to consult a row that may not exist.
What it should not do is fabricate a closure for a decision nobody can now read. A captain call closed wrongly leaves review entirely, which the captain-hold policy itself calls worse than the noise.
Environment
firstmate at 4179c50, tasks-axi markdown backend, default Done retention.
What happens
bin/fm-captain-hold.sh completerefuses when any keyed status decision in the lane's log names a backlog row that Done retention has since pruned.Reproduced again today at
4179c50:The lane's status log carried two keyed decisions. The older one was answered by the captain and closed as its own captain task, but Done retention has since pruned that row.
completerequires the inventory to account for every open keyed status decision, one of them names a row that no longer exists, and it refuses.Why this is not cosmetic
completeis what writes thecaptain-held [key=...]status line, and that line is what the classifier reads as a declared wait. Without it, a lane that is legitimately waiting on the captain keeps being read as a possible wedge and re-escalated at every threshold. One lane reached 11 consecutive escalations while correctly parked; another reached 70 on the same home. Each escalation costs the supervising firstmate a full turn.So the pruning defect converts directly into unbounded supervision noise, and there is no workaround short of widening the global stale threshold, which delays genuine wedge detection by the same amount.
Related: #3055 covers the noise itself. This issue is one of its causes, and closing this one removes the noise for the parked-on-captain case specifically.
Note on the error output
The second line prints an empty task id -
captain-held task is absent- which suggests an argument-parsing slip worth reading alongside the retention question.Worth establishing before fixing
Three plausible answers, and it is not obvious which is right:
completeshould treat a key whose row was legitimately answered-then-pruned as closed rather than missing.completenever has to consult a row that may not exist.What it should not do is fabricate a closure for a decision nobody can now read. A captain call closed wrongly leaves review entirely, which the captain-hold policy itself calls worse than the noise.
Environment
firstmate at
4179c50, tasks-axi markdown backend, default Done retention.