This was generated by AI.
An armed Lavish review source never got a runner, so the captain answered five decisions on the board and the page told him "Your agent is not listening". No answer was lost - Lavish holds queued feedback until something collects it - but nothing in the fleet was going to collect it, and nothing said so.
What happened, in order
bin/fm-procevent-lavish.sh arm <artifact> succeeded: registered: lavish-3c3d3e5874696a65 / armed: lavish-3c3d3e5874696a65, and state/procevent/lavish-3c3d3e5874696a65.source was written.bin/fm-procevent.sh list showed the source with OWNER none. The two pre-existing lavish sources in this home also showed OWNER none, so this is not specific to the new one.bin/fm-procevent.sh reconcile printed reconciled: published=0 started=3 stopped=0 uncertain=0, but no runner survived: no .runner record appeared for the new source, no lavish-axi poll process for it existed afterwards, and list still showed OWNER none.bin/fm-procevent.sh start lavish-3c3d3e5874696a65 failed with error: cannot claim source: lavish-3c3d3e5874696a65, twice, once with FM_HOME set explicitly.- At the time of that failure the machine-wide claim root
~/.local/state/firstmate/procevent-claims/ was empty - no .claim, no .lock. So the refusal was not a live owner and not a stale claim left behind.
The captain's answers were eventually recovered by running lavish-axi poll directly and redirecting to a file, then recording them through bin/fm-captain-hold.sh answer. That recovery path crosses the documented destructive-clear window, which is exactly the window the runner exists to remove.
Two distinct problems
A. reconcile reports started for runners that do not survive. detach_runner backgrounds perl ... & from the calling shell. When reconcile is invoked from a short-lived process whose process group is torn down on exit - a tool-call shell, a hook, a wrapper - the detached child dies with it, while the count still reports it started. The count is therefore not evidence that a runner exists, and nothing else reports the discrepancy.
B. start refused to claim a registered source with an empty claim root. Not diagnosed. An in-repo reproduction attempt was invalid (the harness did not load the sibling libs, so fm_task_id_path_safe and fm_lock_release were undefined) and is not offered as evidence. What is established is only the observed behaviour in steps 4 and 5.
Why it is worth fixing rather than working around
The failure is silent on the side that matters. arm succeeds, list shows the source, and the only signal that answers are going nowhere is a message in the artifact's own UI that the agent reading the artifact cannot see. A captain who answers a decision board and is told the agent is not listening reasonably concludes his answers are lost.
Suggested direction, not a specification
- Make
started mean a runner was observed alive, or report it as attempted and surface the gap.
- Give
list a way to distinguish "registered, no owner, and nothing is going to start one" from "registered and owned".
- Diagnose B before changing A: if
start cannot claim a source with an empty claim root, reconcile starting a runner would not have helped either.
An armed Lavish review source never got a runner, so the captain answered five decisions on the board and the page told him "Your agent is not listening". No answer was lost - Lavish holds queued feedback until something collects it - but nothing in the fleet was going to collect it, and nothing said so.
What happened, in order
bin/fm-procevent-lavish.sh arm <artifact>succeeded:registered: lavish-3c3d3e5874696a65/armed: lavish-3c3d3e5874696a65, andstate/procevent/lavish-3c3d3e5874696a65.sourcewas written.bin/fm-procevent.sh listshowed the source withOWNER none. The two pre-existing lavish sources in this home also showedOWNER none, so this is not specific to the new one.bin/fm-procevent.sh reconcileprintedreconciled: published=0 started=3 stopped=0 uncertain=0, but no runner survived: no.runnerrecord appeared for the new source, nolavish-axi pollprocess for it existed afterwards, andliststill showedOWNER none.bin/fm-procevent.sh start lavish-3c3d3e5874696a65failed witherror: cannot claim source: lavish-3c3d3e5874696a65, twice, once withFM_HOMEset explicitly.~/.local/state/firstmate/procevent-claims/was empty - no.claim, no.lock. So the refusal was not a live owner and not a stale claim left behind.The captain's answers were eventually recovered by running
lavish-axi polldirectly and redirecting to a file, then recording them throughbin/fm-captain-hold.sh answer. That recovery path crosses the documented destructive-clear window, which is exactly the window the runner exists to remove.Two distinct problems
A.
reconcilereportsstartedfor runners that do not survive.detach_runnerbackgroundsperl ... &from the calling shell. Whenreconcileis invoked from a short-lived process whose process group is torn down on exit - a tool-call shell, a hook, a wrapper - the detached child dies with it, while the count still reports it started. The count is therefore not evidence that a runner exists, and nothing else reports the discrepancy.B.
startrefused to claim a registered source with an empty claim root. Not diagnosed. An in-repo reproduction attempt was invalid (the harness did not load the sibling libs, sofm_task_id_path_safeandfm_lock_releasewere undefined) and is not offered as evidence. What is established is only the observed behaviour in steps 4 and 5.Why it is worth fixing rather than working around
The failure is silent on the side that matters.
armsucceeds,listshows the source, and the only signal that answers are going nowhere is a message in the artifact's own UI that the agent reading the artifact cannot see. A captain who answers a decision board and is told the agent is not listening reasonably concludes his answers are lost.Suggested direction, not a specification
startedmean a runner was observed alive, or report it as attempted and surface the gap.lista way to distinguish "registered, no owner, and nothing is going to start one" from "registered and owned".startcannot claim a source with an empty claim root,reconcilestarting a runner would not have helped either.