#20 - kilo-gsd runners exit cleanly without kanban_complete/kanban_block — profile slots held indefinitely - Mark/org_mode - cyguin git: Adlerian Hierarchical Self-Actualization Syllogism

Mark commented

2026-07-31 04:32:24 +00:00

Owner

Bug — kilo-gsd runners exit cleanly without `kanban_complete`/`kanban_block` (protocol violation)

Symptom

A kilo-gsd runner finishes its work — commits land on disk, the agent
returns to a bash prompt — but the monitor script that wraps the runner
never calls hermes kanban complete (or kanban_block). The card stays
in running state with consecutive_crashes=2 protocol violation,
permanently holding the kilo-gsd-runner profile's running slot.

Reproduction (verified 2026-07-31 on `t_201675ff` for Mark/org_mode#16)

Card t_201675ff for Mark/org_mode#16 was created 2026-07-30 20:04,
assigned to kilo-gsd-runner
Kilo-gsd-runner agent (PID 1217412) was dispatched at 20:08, ran for
~5 minutes, made two commits:
- ~/.hermes: 6f7e8ce tasker-worker: file Forgejo issue before implementing code from card body
- /home/b/Projects/org_mode: 89c29f9 vikunja-ingress: --skill kanban-worker on tasker card create
Agent exited with rc=0 to a bash prompt (visible in tmux capture:
^C b@blackhole:~/Projects/org_mode$)
The detached monitor (kilo-monitor-org_mode-16 tmux session, started
2026-07-30 20:09) was supposed to call hermes kanban complete on
success — it did not
Card has been stuck in running since 2026-07-30 20:08 (now >3 hours)

Direct downstream impact

The dispatcher only claims ready cards when the assignee profile has a
free running slot. With kilo-gsd-runner permanently occupied by
t_201675ff, 13 other ready cards on the fixit board are blocked,
including:

Mark/easystitch#104 — Thread max_colors through pipeline
Mark/easystitch#105 — Add integration tests for max_colors
Mark/easystitch#109 — Photo-segmentation dirty tree
Mark/Kimi_Agent_Brother_10_Digitizing_App#43 — View toggles regression
AuWoMe/forgeflow#23, Mark/nodedesk#37/#38/#41,
Mark/osint-hub#65, Mark/docker_backup#16/#20,
AuWoMe/forgeflow#21, Mark/kimi_agent_chore_management_integration_platform#24

All these have valid work to do; none can be claimed until the stuck
card is killed and reclaimed.

Root cause

The kilo-gsd-monitor.sh pattern (per kanban-worker skill §
"Long-running runner invocation") is supposed to:

Wait for the runner to exit
Run post-run gates
Verify the fix landed
Call hermes kanban complete on success, kanban block on failure

In this case, the monitor script's wait for the runner exit either
(a) didn't detect the clean exit, (b) ran but the hermes kanban complete CLI call failed silently, or (c) the monitor itself crashed
after the runner finished. The tmux pane shows no recent output and
no completion signal.

The agent's earlier two attempts (Run #533 at 20:08, Run #535 at
20:10) both exited cleanly without signaling — both recorded as
protocol violation. The pattern has been seen in prior sessions
(see references/protocol-violation-chain.md for the documented
fracture chain).

Suggested fix direction

Immediate unblock: reclaim the stuck card via
hermes kanban reclaim t_201675ff after killing its detached tmux
sessions, freeing the lane slot
Root cause: trace the monitor script's exit detection — verify
that wait $RUNNER_PID actually fires on clean exit, and that the
hermes kanban complete call after the wait actually executes
(currently appears to be silently failing)
Defense in depth: add a watchdog that reaps running cards
whose worker PID is dead for >30 min and the tmux session is empty
— call kanban reclaim automatically with reason
stale-running: monitor-completed-but-did-not-signal

Companion issue

Mark/org_mode (separate): event-driven Forgejo → kanban wrapper
exits with missing EVENT_URL — ingress-side bug, no new cards
reach the kanban

## Bug — kilo-gsd runners exit cleanly without `kanban_complete`/`kanban_block` (protocol violation) ### Symptom A kilo-gsd runner finishes its work — commits land on disk, the agent returns to a bash prompt — but the monitor script that wraps the runner never calls `hermes kanban complete` (or `kanban_block`). The card stays in `running` state with `consecutive_crashes=2` protocol violation, **permanently holding the `kilo-gsd-runner` profile's `running` slot.** ### Reproduction (verified 2026-07-31 on `t_201675ff` for Mark/org_mode#16) 1. Card `t_201675ff` for Mark/org_mode#16 was created 2026-07-30 20:04, assigned to `kilo-gsd-runner` 2. Kilo-gsd-runner agent (PID 1217412) was dispatched at 20:08, ran for ~5 minutes, made two commits: - `~/.hermes`: `6f7e8ce tasker-worker: file Forgejo issue before implementing code from card body` - `/home/b/Projects/org_mode`: `89c29f9 vikunja-ingress: --skill kanban-worker on tasker card create` 3. Agent exited with rc=0 to a bash prompt (visible in tmux capture: `^C b@blackhole:~/Projects/org_mode$`) 4. The detached monitor (`kilo-monitor-org_mode-16` tmux session, started 2026-07-30 20:09) was supposed to call `hermes kanban complete` on success — it did not 5. Card has been stuck in `running` since 2026-07-30 20:08 (now >3 hours) ### Direct downstream impact The dispatcher only claims `ready` cards when the assignee profile has a free `running` slot. With `kilo-gsd-runner` permanently occupied by `t_201675ff`, **13 other `ready` cards on the fixit board are blocked**, including: - `Mark/easystitch#104` — Thread max_colors through pipeline - `Mark/easystitch#105` — Add integration tests for max_colors - `Mark/easystitch#109` — Photo-segmentation dirty tree - `Mark/Kimi_Agent_Brother_10_Digitizing_App#43` — View toggles regression - `AuWoMe/forgeflow#23`, `Mark/nodedesk#37/#38/#41`, `Mark/osint-hub#65`, `Mark/docker_backup#16/#20`, `AuWoMe/forgeflow#21`, `Mark/kimi_agent_chore_management_integration_platform#24` All these have valid work to do; none can be claimed until the stuck card is killed and reclaimed. ### Root cause The `kilo-gsd-monitor.sh` pattern (per `kanban-worker` skill § "Long-running runner invocation") is supposed to: 1. Wait for the runner to exit 2. Run post-run gates 3. Verify the fix landed 4. Call `hermes kanban complete` on success, `kanban block` on failure In this case, the monitor script's `wait` for the runner exit either (a) didn't detect the clean exit, (b) ran but the `hermes kanban complete` CLI call failed silently, or (c) the monitor itself crashed after the runner finished. The tmux pane shows no recent output and no completion signal. The agent's earlier two attempts (`Run #533` at 20:08, `Run #535` at 20:10) both exited cleanly without signaling — both recorded as `protocol violation`. The pattern has been seen in prior sessions (see `references/protocol-violation-chain.md` for the documented fracture chain). ### Suggested fix direction - **Immediate unblock:** reclaim the stuck card via `hermes kanban reclaim t_201675ff` after killing its detached tmux sessions, freeing the lane slot - **Root cause:** trace the monitor script's exit detection — verify that `wait $RUNNER_PID` actually fires on clean exit, and that the `hermes kanban complete` call after the wait actually executes (currently appears to be silently failing) - **Defense in depth:** add a watchdog that reaps `running` cards whose worker PID is dead for >30 min and the tmux session is empty — call `kanban reclaim` automatically with reason `stale-running: monitor-completed-but-did-not-signal` ### Companion issue - Mark/org_mode (separate): event-driven Forgejo → kanban wrapper exits with `missing EVENT_URL` — ingress-side bug, no new cards reach the kanban

Mark added the

triage-approved

bug

labels

2026-07-31 04:32:24 +00:00

Mark commented

2026-08-07 03:04:40 +00:00

Author

Owner

Verified 2026-08-06 by bblhd: kilo-gsd-monitor.sh on blackhole (/home/b/.hermes/scripts/kilo-gsd-monitor.sh, mtime 2026-08-06 13:42) DOES call hermes kanban complete and hermes kanban block, gated on fix_actually_landed(). The example card cited in this issue (t_201675ff, Mark/org_mode#16) is currently status=done, assignee=verifier, completed_at=1785471745 — the protocol close happened. The bug as filed (monitor never closes the card, slot held forever) does not match the on-disk behavior. Closing as not reproducible.

Mark