🐛 fix(kanban): never spawn a tool-less worker; bound per-tick spawn burst

[cwest]

Summary

Never spawn a tool-less kanban worker, and bound the per-tick spawn burst.

A dispatcher-spawned worker came up with only the base kanban_*
coordination tools (no web/shell/git/file) despite its profile correctly
declaring a full toolset, then self-blocked. Root cause: under a
stuck→mass-spawn recovery, the dispatcher launched all ready cards in one tick;
_resolve_worker_cli_toolsets came up degenerate (None/empty) and
_default_spawn silently launched the worker without a --toolsets pin
(the old if worker_toolsets: guard), letting it fall back to a kanban-only
surface and waste a full LLM cycle.

The fix — two layers, smallest-footprint first

The single _default_spawn helper backs both the ready and review dispatch
paths, so fixing it once covers the whole class.

1. Never spawn tool-less. _default_spawn now requires a non-empty
   resolved CLI toolset and raises when resolution is degenerate.
   dispatch_once's existing spawn-failure handler records the failure with
   release_claim=True, so the card is reclaimed to ready for a clean retry
   instead of running crippled. _resolve_worker_cli_toolsets always recovers
   at least the kanban lifecycle surface for a real profile home, so None/empty
   is a genuine resolution failure — not a legitimately tool-less profile.

2. Bound the per-tick spawn burst. New kanban.max_spawn_per_tick caps how
   many workers a single tick may launch (ready + review combined), distinct
   from max_spawn (a live concurrency cap). Prevents a stuck→recovery tick
   from dumping the whole ready queue at once — the condition under which
   workers raced into tool-less spawns. Wired through the gateway dispatcher and
   the CLI dispatch path; unset preserves historical unbounded behavior;
   invalid/<1 values normalize to None.

The new knob lives in config.yaml under kanban.max_spawn_per_tick
(DEFAULT_CONFIG) — no new HERMES_* env var.

Files

• hermes_cli/kanban_db.py — _default_spawn raise-on-degenerate guard;
  dispatch_once per-tick cap (applied to both the ready and review loops).
• gateway/kanban_watchers.py — read kanban.max_spawn_per_tick, forward to
  dispatch_once.
• hermes_cli/kanban.py — CLI dispatch path forwards the per-tick cap.
• hermes_cli/config.py — kanban.max_spawn_per_tick: None default.
• Tests: test_kanban_worker_spawn_toolsets.py,
  test_kanban_core_functionality.py, test_kanban_db.py.
• PATCHES.md — upstream-pending row.

Tests (behavior-contract, real path against temp HERMES_HOME)

• A spawned worker's resolved toolset is pinned (--toolsets present).
• A degenerate (None) and an empty-list resolution both raise and never
  Popen (no tool-less worker).
• N>cap ready cards spawn at most cap per tick; the per-tick cap also counts
  review spawns.
• The gateway forwards kanban.max_spawn_per_tick to dispatch_once.

RED→GREEN verified for both layers (reverting each production hunk turns the
matching tests red). Full dispatch/spawn/config/CLI/gateway-dispatch surface
green: 595 passed, 1 skipped, 0 regressions.

Notes

Recovered the original work by cherry-pick to preserve authorship (origin
commit 8fb892f1c); the spawn-env block reconciled cleanly alongside the
recent per-task max-iterations change.

[cwest]

The code is right and the verification holds up. I reran the suite against a temp HERMES_HOME: the two spawn-guard tests, the reclaim-on-degenerate E2E, the three per-tick-cap tests, and the gateway config-propagation test all pass (7 passed). I also confirmed both layers RED to GREEN myself: reverting the _default_spawn raise turns the two guard tests red (Popen would run a tool-less worker), and removing the ready-loop per-tick break turns the burst-cap test red (5 spawn instead of 2). The reclaim path is real: _default_spawn's RuntimeError is caught in dispatch_once and routed through _record_spawn_failure(release_claim=True), so the card returns to ready rather than running crippled. The cap break sits before the claim/spawn and spawned only increments on success, so a reclaim doesn't burn cap budget. Whole-class coverage checks out: the single _default_spawn helper backs both dispatch paths and the cap guards both loops. mergeable, all checks green, no open threads.

One thing has to change before this lands. The recovered commit message body on the first commit (61db1de59) names a specific internal worker in its opening line. That detail shouldn't sit in a commit body on the remote. Reword that line to the generic form ("a dispatcher-spawned worker on the knowledge board came up with only the base coordination tools"), preserving the original authorship via --author and re-signing. The code stays byte-identical; only the message changes. Everything else is ready, so once that commit body is generalized this is good to go.

[cwest]

No changes needed. The recovered dispatcher-safety fix holds up: the guard makes a degenerate toolset resolution raise rather than launch a worker on the kanban-only surface, and the per-tick cap keeps a recovery burst from emptying the ready queue in one go. The single helper covers both the ready and review spawn paths, so the whole class is closed, not just the reported site. The new behavior-contract tests run green against a temp HERMES_HOME, and the per-tick cap and gateway wiring are exercised end to end. mergeable, all required checks, and conversation resolution are clean. Ready to merge.