hermes - 💡(How to fix) Fix [Feature]: Distributed Kanban workers with central board visibility

Summary

Support a distributed Hermes Kanban mode where one central Kanban board can observe and coordinate workers running on multiple hosts.

Today Kanban is intentionally single-host: the board is SQLite-backed, the dispatcher spawns local Hermes profile workers, and liveness / crash detection relies on host-local PIDs. This works well for local multi-profile workflows, but it does not cover common agent-fleet setups where workers run on separate machines.

Use cases

• A local laptop orchestrates work while remote Linux / GPU / build machines execute tasks.
• A team runs multiple Hermes workers across repos, hosts, or environments, but wants one board.
• Long-running tasks such as tests, CI repair, crawling, evals, training, video generation, and deployment run on dedicated hosts.
• Production credentials stay isolated on specific worker machines.
• Operators need one dashboard to see which host / profile / lane is running each task.

Current limitation

The current design is single-host by design:

• ~/.hermes/kanban.db is a local SQLite board.
• The dispatcher spawns workers on the same host.
• Crash detection uses host-local PIDs.
• Dashboard worker visibility can inspect local PIDs, but cannot represent remote workers.

Proposed direction

Add a distributed-worker mode with a central board and remote worker registration.

Possible shape:

1. Central Kanban board remains the source of truth.
2. Remote Hermes workers register with:
   • worker id
   • host id
   • profile / lane name
   • capabilities / toolsets
   • current task / run id
   • heartbeat timestamp
3. Tasks can be assigned to a profile / lane and optionally constrained by host or capabilities.
4. Liveness uses leases / heartbeats instead of local PID checks for remote workers.
5. Dashboard shows active workers across hosts:
   • host
   • profile / lane
   • task id / title
   • run id
   • heartbeat age
   • status
   • log tail / artifact links
6. Existing single-host mode remains the default and keeps current PID-based behavior.

Non-goals / open questions

• Avoid sharing one SQLite file across hosts directly.
• Need an explicit auth model before exposing dashboard / plugin routes over the network.
• Need to define how remote logs and artifacts are streamed back.
• Need to decide whether remote workers pull tasks, or a central dispatcher pushes assignments.
• Need compatibility with future external worker lanes such as Codex CLI, Claude Code, OpenCode, or containerized runners.

Related issues / context

• #18715 remote Hermes agent with local tool execution
• #19931 specialist worker lanes under Hermes Kanban orchestration
• #23483 documented worker lane contract
• #18629 native ACP worker backend request
• #689 remote agent connection / multi-instance delegation
• #1265 Hermes-to-Hermes task delegation via MCP
• #514 A2A remote agent discovery and interoperability