fix(bin): fail loudly for queued-unsubmitted steers - #6
Merged
Conversation
Parked lanes (especially grok on herdr) can accept typed text into a numbered composer queue without submitting it. The composer row then reads empty, so fm-send exited 0 while the steer never landed. After each Enter that would report delivery, scan the pane for a numbered `#N [fm-from-firstmate]` item. Retry Enter only within the existing budget; if the item remains, report queued-unsubmitted so fm-send exits non-zero. Preserve the opencode busy-queue exception.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Intent
Make bin/fm-send.sh fail loudly (or deliver) when a steer lands QUEUED-UNSUBMITTED in a parked lane, instead of exiting 0.
Bug (observed 2026-08-02/03, grok on herdr): a parked worker holds a foregrounded wait so its turn never ends. fm-send types the message into a numbered composer queue item (#N [fm-from-firstmate]...) that is never submitted, yet exits 0 with no output - firstmate believes the steer was delivered. Real cost: instructions sat undelivered for tens of minutes while reported delivered. Manual workaround was a follow-up Enter per queued item. Upstream kunchenguid#1474 describes this class of defect; ship to the fork sparkus/firstmate.
Required behavior in the submit-verification path (fm-send and backend submit primitives in fm-backend.sh / herdr.sh / fm-tmux-lib.sh as needed):
Acceptance: both outcomes covered by tests (retry-succeeds and retry-exhausted-fails-loud); normal idle submits stay green; opencode busy-queue still reports delivered (empty). Stay inside fm-send and the submit-verification path - do not redesign supervision, the watcher, or the composer classifier.
Implemented as: shared fm_composer_has_queued_unsubmitted detector; herdr and tmux submit cores scan after would-be empty, retry Enter, return queued-unsubmitted on exhaust; fm-send fails loud with a named diagnostic.
What Changed
[fm-from-firstmate]items that remain queued after tmux or Herdr submission, and verify the queue is readable and clear before reporting delivery.queued-unsubmittedfailure on exhaustion while preserving the OpenCode busy-queue exception.Risk Assessment
✅ Low: Captain, the change is well-bounded and now satisfies the durable queue-verification invariant on both tmux and Herdr, including unreadable probes and final-attempt clear races, without disturbing the OpenCode exception.
Testing
At the exact target SHA, focused composer, tmux, fm-send, and Herdr tests passed; end-to-end CLI evidence confirmed Enter-only retry without retyping, non-zero named reporting after exhaustion, unchanged normal idle delivery, and preserved OpenCode busy-queue delivery. No UI artifact was applicable because this is a CLI behavior change.
Evidence: fm-send end-to-end CLI transcript
retry-succeeds: exit 0, typed once, Enter twice; retry-exhausted: exit 1 with queued-unsubmitted diagnostic, typed once, Enter twice; normal-idle: exit 0 on first Enter; opencode-busy: exit 0 after bounded Enter retries.Pipeline
Updates from git push no-mistakes
✅ **intent** - passed
✅ No issues found.
✅ **Rebase** - passed
✅ No issues found.
🔧 **Review** - 2 issues found → auto-fixed ✅
bin/fm-tmux-lib.sh:407- Required criterion 1 says “After normal submit, VERIFY the message left the composer queue,” but this helper maps a failedcapture-paneto return 1—the same result as a readable pane with no marker. The new empty branch can therefore returnemptyafter a transient verification-read failure while#N [fm-from-firstmate]remains; Herdr repeats this fail-open behavior atbin/backends/herdr.sh:2699. Make the probe tri-state (queued/clear/unknown) and permit success only after a readable clear scan.bin/backends/herdr.sh:2741- Acceptance requires “retry-succeeds,” but on the final Enter an empty candidate whose first queue scan still sees the marker becomespending; if the exhaustion rescan then successfully observes that the queue cleared, thiselsestill emitspending. The tmux sibling has the same final-attempt race at lines 439–478. Preserve the candidate-empty proof and returnemptywhen the final readable scan is clear, or classify both states from one final snapshot.🔧 Fix: Captain, fail closed on unreadable queue verification
✅ Re-checked - no issues remain.
✅ **Test** - passed
✅ No issues found.
git status --short --branchandgit rev-parse HEADInspectedgit diff a5dd0059a97c4bf38e3843db0eb900350cac6016..5c42df5fa573c42e8e1e41c7d33de9d8f42d7c9afor the submit-verification pathtests/fm-composer-lib.test.shtests/fm-tmux-submit-busy.test.shtests/fm-send-strict.test.shtests/fm-backend-herdr.test.shfm-send-e2e-evidence.sh "$PWD"exercising retry success, retry exhaustion, normal idle submission, and the OpenCode busy-queue exception through the realbin/fm-send.shentry point✅ **Document** - passed
✅ No issues found.
✅ **Lint** - passed
✅ No issues found.
✅ **Push** - passed
✅ No issues found.