Feature Request: First-Class Persistent Kanban Worker Lanes

Summary

Add first-class support for persistent/control-plane Kanban worker lanes: long-running external or Hermes-managed worker processes that can claim assigned Kanban tasks, receive or observe task availability without dispatcher spawning a new profile process per task, and mutate only tasks claimed by that lane.

Problem

Hermes Kanban currently works well for dispatcher-spawned Hermes profiles: a task is assigned to a profile, the dispatcher claims it, spawns hermes -p <assignee>, injects HERMES_KANBAN_TASK, and the worker receives claim-scoped Kanban tools.

That model breaks down for persistent worker lanes that must remain alive across many tasks. Examples include:

• a persistent coding-factory process that manages external CLI/ACP workers,
• a long-running supervisor that owns process lifecycle, crash/stall detection, and cleanup,
• specialist implementation lanes such as Codex CLI, Claude Code, OpenCode, or local model runners,
• non-Hermes workers that must report back into Hermes Kanban as the canonical lifecycle system.

Today, these lanes can approximate intake by polling/listing tasks and calling claim, but this leaves important gaps:

• no native push/notification path for a persistent lane when new work is available,
• no first-class lane identity distinct from spawnable Hermes profiles,
• no claim-scoped mutation authority for non-dispatcher workers equivalent to HERMES_KANBAN_TASK,
• no clean way to say "this assignee is a persistent control-plane lane; do not spawn it, but let it claim work",
• risk of custom wrappers/adapters around Kanban that become version-fragile as Hermes ships rapidly.

Recent work in #20105 and #20134 already recognizes non-spawnable/control-plane assignees and terminal lanes that pull work via claim_task. This request is to make that pattern first-class, safe, and ergonomic.

Desired Behavior

Hermes should support a registered Kanban lane that is not a spawnable Hermes profile.

Example:

hermes kanban lanes register factory \
  --kind persistent \
  --claim-mode pull-or-watch \
  --allowed-status-mutations own-claimed-only

Then:

1. An orchestrator/PM creates or assigns a task to factory.
2. Hermes recognizes factory as a persistent lane, not a missing profile.
3. The dispatcher does not spawn hermes -p factory.
4. The persistent Factory process can claim eligible tasks assigned to factory.
5. Once claimed, Hermes gives the lane claim-scoped authority over that task only.
6. The lane can heartbeat, complete, block, or attach structured run metadata only for the task it claimed.
7. PM/orchestrator profiles can observe task events and route follow-up work through normal Kanban.

Required Capabilities

• Explicit lane registry or equivalent native configuration.
• Ability to mark a lane as non-spawnable without treating it as an error.
• Ability for a persistent lane to discover work without polling-only designs if possible, e.g. event stream, watch cursor, or blocking claim.
• Claim-scoped authority for persistent lanes equivalent in spirit to HERMES_KANBAN_TASK for dispatcher workers.
• Native event emission for claimed, heartbeat, completed, blocked, timed_out, crashed, and released outcomes.
• Compatibility with existing Kanban boards, task events, run history, dashboard, and CLI.
• No requirement for custom DB adapters or direct SQLite access by downstream users.

Why This Matters

This keeps Hermes Kanban as the canonical task lifecycle while allowing durable external worker lanes. Without this, systems that need persistent worker supervision have to choose between:

• dispatcher-spawned workers, which lose persistent process supervision,
• polling shims with weaker authority boundaries,
• custom wrappers around Kanban commands,
• or parallel task trackers.

All of those undermine Kanban as the single source of truth.

Related Upstream Work

• #20105: dispatcher skips ready tasks whose assignee is not a real profile.
• #20134: separates non-spawnable assignees from unassigned tasks and treats terminal-lane pulling as expected steady-state.
• #19931: specialist worker lanes under Hermes Kanban orchestration.
• #20048: expanded orchestrator Kanban tools for board steering.
• #18493: durable profile-agent orchestration via agent_control.

Acceptance Criteria

• A task assigned to a registered persistent lane is not auto-spawned by the dispatcher.
• A persistent lane can claim one eligible task atomically.
• Once claimed, that lane can mutate only that task until it is completed, blocked, released, or reclaimed.
• Another lane/process cannot complete or block a task it did not claim.
• The dashboard and task event log clearly show lane identity, claim ownership, run metadata, and final outcome.
• Existing dispatcher-spawned Hermes profile workers continue to behave as they do today.