Hermes Kanban – Multi-Agent Profile Collaboration

Hermes Kanban, a durable task board for multi-agent profile collaboration, is now available, allowing multiple named agents to work on tasks via a shared SQLite database and a dedicated kanban_* toolset. The board supports completion checkpoints, circuit breakers, and CLI/dashboard interfaces, with features for research triage, scheduled ops, digital twins, engineering pipelines, and fleet work.

Kanban — Multi-Agent Profile Collaboration Want a walkthrough? Read the Kanban tutorial /docs/user-guide/features/kanban-tutorial — four user stories solo dev, fleet farming, role pipeline with retry, circuit breaker with dashboard screenshots of each. This page is the reference; the tutorial is the narrative. Hermes Kanban is a durable task board, shared across all your Hermes profiles, that lets multiple named agents collaborate on work without fragile in-process subagent swarms. Every task is a row in ~/.hermes/kanban.db ; every handoff is a row anyone can read and write; every worker is a full OS process with its own identity. Completion checkpoints before the iteration cap Dispatcher-owned workers get one checkpoint notice near 90% of their finite iteration budget, attached to a fresh tool result while another tool-capable call remains. Use agent.budget warning ratio to choose an earlier threshold. Tiny budgets warn no later than their penultimate iteration; a one-iteration run has no pre-cap checkpoint window. The notice is saved in the session transcript before the next request. Workers should call kanban complete only after verifying the task contract, or persist a progress comment and continue. A commit or diff alone never automatically completes a task. The hard cap, toolless final summary, and consecutive-failure circuit breaker are unchanged: workers that still exhaust their budget remain subject to bounded retries. This is a reporting opportunity, not a guarantee that a model will heed the notice. Ordinary conversations and delegated children do not inherit the automatic Kanban checkpoint; their iteration warning remains opt-in. Two surfaces: the model talks through tools, you talk through the CLI The board has two front doors, both backed by the same ~/.hermes/kanban.db : - Agents drive the board through a dedicated kanban toolset — kanban show , kanban list , kanban complete , kanban request review , kanban request changes , kanban block , kanban heartbeat , kanban comment , kanban attach , kanban attach url , kanban attachments , kanban create , kanban link , kanban unblock . The dispatcher spawns each worker with these tools already in its schema; orchestrator profiles can also enable the kanban toolset explicitly. The model reads and routes tasks by calling tools directly, not by shelling out to hermes kanban . See How workers interact with the board how-workers-interact-with-the-board below. - You and scripts, and cron drive the board through hermes kanban … on the CLI, /kanban … as a slash command, or the dashboard. These are for humans and automation — the places without a tool-calling model behind them. Both surfaces route through the same kanban db layer, so reads see a consistent view and writes can't drift. The rest of this page shows CLI examples because they're easy to copy-paste, but every CLI verb has a tool-call equivalent the model uses. This is the shape that covers the workloads delegate task can't: - Research triage — parallel researchers + analyst + writer, human-in-the-loop. - Scheduled ops — recurring daily briefs that build a journal over weeks. - Digital twins — persistent named assistants inbox-triage , ops-review that accumulate memory over time. - Engineering pipelines — decompose → implement in parallel worktrees → review → iterate → PR. - Fleet work — one specialist managing N subjects 50 social accounts, 12 monitored services . For the full design rationale, comparative analysis against Cline Kanban / Paperclip / NanoClaw / Google Gemini Enterprise, and the eight canonical collaboration patterns, see docs/hermes-kanban-v1-spec.pdf in the repository. PR completion contracts Declare PR work at creation with --completion-contract OWNER/REPO or an exact https://github.com/OWNER/REPO/pull/123 URL for existing work . kanban create accepts the same completion contract . Use local-only for intentionally local work; existing and undeclared cards retain that default. Prose URLs are not policy. After publishing, pass metadata.published pr to completion. The first matching URL binds the card permanently; retries cannot substitute a green sibling PR. CLI show --json and kanban show expose the persisted contract. The shared complete task boundary covers worker tools, CLI, review approval and dashboard completion. It reads classic branch protection and active ruleset required contexts, paginates exact-head check runs and legacy statuses, then re-reads the PR head/base. Optional failed/skipped telemetry does not veto accepted required checks. Missing, pending, failed, cancelled, timed-out, stale, skipped or neutral required evidence cannot complete the card. Neither can zero-run acceptance, unreadable policy or GitHub API failures. A repository without required checks needs a local-only contract. gh must be authenticated with read access to the repository's checks and rules; no remote writes are performed by this gate. Rejection retains the active card and workspace. Durable pr acceptance events store PR URL, SHA, required contexts, check IDs/URLs, classifications and recovery instructions; last failure error surfaces the next step. Fix failures, rerun infrastructure checks or wait, then retry completion. Use kanban block when human action is needed. Generic GitHub failure cannot establish whether a test or artifact upload failed; inspect its retained URL. Explicit infrastructure conclusions and API failures are classified separately. No extra worker is spawned. Receipt persistence and the terminal write recheck run/status/contract ownership under one SQLite lock: a reclaimed worker cannot complete or attach acceptance to the new run. The final GitHub read is a completion-time snapshot, not a distributed transaction or a continuous post-completion monitor. This is a single-user lifecycle guard, not OS isolation against arbitrary direct database writes. GitHub Enterprise is not covered. Related publication/lifecycle work: 91230, 84254, 52311; local verification and publication alone are not remote acceptance. Kanban vs. delegate task They look similar; they are not the same primitive. | | delegate task | Kanban | |---|---|---| | Shape | RPC call fork → join | Durable message queue + state machine | | Parent | Blocks until child returns | Fire-and-forget after create | | Child identity | Anonymous subagent | Named profile with persistent memory | | Resumability | None — failed = failed | Block → unblock → re-run; crash → reclaim | | Human in the loop | Not supported | Comment / unblock at any point | | Agents per task | One call = one subagent | N agents over task's life retry, review, follow-up | | Audit trail | Lost on context compression | Durable rows in SQLite forever | | Coordination | Hierarchical caller → callee | Peer — any profile reads/writes any task | One-sentence distinction: delegate task is a function call; Kanban is a work queue where every handoff is a row any profile or human can see and edit. Use delegate task when the parent agent needs a short reasoning answer before continuing, no humans involved, result goes back into the parent's context. Use Kanban when work crosses agent boundaries, needs to survive restarts, might need human input, might be picked up by a different role, or needs to be discoverable after the fact. They coexist: a kanban worker may call delegate task internally during its run. Core concepts - Board — a standalone queue of tasks with its own SQLite DB, workspaces directory, and dispatcher loop. A single install can have many boards e.g. one per project, repo, or domain ; see Boards multi-project boards-multi-project below. Single-project users stay on the default board and never see the word "board" outside this docs section. - Task — a row with title, optional body, one assignee a profile name , status triage | todo | ready | running | blocked | review | done | archived , optional tenant namespace, optional idempotency key dedup for retried automation . - Link — task links row recording a parent → child dependency. The dispatcher promotes todo → ready when all parents are done . - Comment — the inter-agent protocol. Agents and humans append comments; when a worker is re- spawned it reads the full comment thread as part of its context. - Workspace — the directory a worker operates in. Three kinds: - scratch default — fresh tmp dir under ~/.hermes/kanban/workspaces/<id / or ~/.hermes/kanban/boards/<slug /workspaces/<id / on non-default boards . Deleted when the task completes — scratch is ephemeral by design. Files explicitly declared through kanban complete artifacts= ... are copied into durable per-task attachment storage before cleanup; existing deliverable paths in legacy completion summaries receive the same treatment. Other scratch files are removed. A missing declared scratch artifact keeps the task in-flight so the worker can correct the path and retry. Use worktree: or dir:<path when the whole workspace should remain available. The first time a scratch workspace is created on an install, the dispatcher logs a warning and emits a tip scratch workspace event on the task visible via hermes kanban show <id . - dir:<path — an existing shared directory Obsidian vault, mail ops dir, per-account folder . Must be an absolute path. Relative paths like dir:../tenants/foo/ are rejected at dispatch because they'd resolve against whatever CWD the dispatcher happens to be in, which is ambiguous and a confused-deputy escape vector. The path is otherwise trusted — it's your box, your filesystem, the worker runs with your uid. This is the trusted-local-user threat model; kanban is single-host by design. Preserved on completion. - worktree — a git worktree under .worktrees/<id / for coding tasks. Use worktree:<path to pin the exact target path. Worker-side git worktree add creates it, using --branch when provided. Preserved on completion. - Dispatcher — a long-lived loop that, every N seconds default 60 : reclaims stale claims, reclaims crashed workers PID gone but TTL not yet expired , promotes ready tasks, atomically claims, spawns assigned profiles. Runs inside the gateway by default kanban.dispatch in gateway: true . One dispatcher sweeps all boards per tick; workers are spawned with HERMES KANBAN BOARD pinned so they can't see other boards. After kanban.failure limit consecutive spawn failures on the same task default: 2 the dispatcher auto-blocks it with the last error as the reason — prevents thrashing on tasks whose profile doesn't exist, workspace can't mount, etc. - Tenant — optional string namespace within a board. One specialist fleet can serve multiple businesses --tenant business-a with data isolation by workspace path and memory key prefix. Tenants are a soft filter; boards are the hard isolation boundary. Boards multi-project Boards let you separate unrelated streams of work — one per project, repo, or domain — into isolated queues. A new install has exactly one board called default DB at ~/.hermes/kanban.db for back-compat . Users who only want one stream of work never need to know about boards; the feature is opt-in. Per-board isolation is absolute: - Separate SQLite DB per board ~/.hermes/kanban/boards/<slug /kanban.db . - Separate workspaces/ and logs/ directories. - Workers spawned for a task see only their board's tasks — the dispatcher sets HERMES KANBAN BOARD in the child env and every kanban tool the worker has access to reads it. - Linking tasks across boards is not allowed keeps the schema simple; if you really need cross-project refs, use free-text mentions and look them up by id manually . Managing boards from the CLI See what's on disk. Fresh installs show only "default".hermes kanban boards list Create a new board.hermes kanban boards create atm10-server \ --name "ATM10 Server" \ --description "Minecraft modded server ops" \ --icon 🎮 \ --switch optional: make it the active board Operate on a specific board without switching.hermes kanban --board atm10-server listhermes kanban --board atm10-server create "Restart ATM server" --assignee ops Change which board is "current" for subsequent calls.hermes kanban boards switch atm10-serverhermes kanban boards show who's active right now? Rename the display name the slug is immutable — it's the directory name .hermes kanban boards rename atm10-server "ATM10 Prod " Archive default — moves the board's dir to boards/ archived/<slug -<ts /. Recoverable by moving the dir back.hermes kanban boards rm atm10-server Hard delete — rm -rf the board dir. No recovery.hermes kanban boards rm atm10-server --delete Board resolution order highest precedence first : 1. Explicit --board <slug on the CLI call. 2. HERMES KANBAN BOARD env var set by the dispatcher when spawning a worker, so workers can't see other boards . 3. ~/.hermes/kanban/current — the slug persisted by hermes kanban boards switch . 4. default . Slugs are validated: lowercase alphanumerics + hyphens + underscores, 1-64 chars, must start with alphanumeric. Uppercase input is auto-downcased. Anything else slashes, spaces, dots, .. is rejected at the CLI layer so path-traversal tricks can't name a board. Managing boards from the dashboard hermes dashboard → Kanban tab shows a board switcher at the top as soon as more than one board exists or any board has tasks . Single-board users see only a small + New board button; the switcher is hidden until it matters. - Board dropdown — pick the active board. Your selection is saved to the browser's localStorage so it persists across reloads without shifting the CLI's current pointer out from under a terminal you left open. - + New board — opens a modal asking for slug, display name, description, and icon. Option to auto-switch to the new board. - Settings — opens a modal for editing the current board's display name, description, and project directory default workdir . The project directory is the board-level workspace default every new task inherits git repo → preserved worktree, plain dir → preserved directory ; each task can still override it at creation time. Clearing the field reverts new tasks to disposable scratch workspaces. - Archive — only shown on non- default boards. Confirms, then moves the board dir to boards/ archived/ . All dashboard API endpoints accept ?board=<slug for board scoping. The events WebSocket is pinned to a board at connection time; switching in the UI opens a fresh WS against the new board. File attachments Tasks can carry file attachments — PDFs, images, source documents — so a worker has the source material it needs without you pasting paths into the body and hoping it finds them. - Upload — open a task in the dashboard drawer and use the Attachments section's Upload file button multiple files at once are fine . Each upload is capped at 25 MB. - Storage — files land under <hermes-home /kanban/attachments/<task id / for the default board, or <hermes-home /kanban/boards/<slug /attachments/<task id / for a named board. Set HERMES KANBAN ATTACHMENTS ROOT to pin a custom location. - What the worker sees — when the dispatcher hands a task to a worker, the worker's context includes an Attachments section listing each file's name and its absolute path . The worker has full file/terminal tool access, so it reads attachments directly read file , or shell tools like pdftotext . - Download / remove — the drawer lists each attachment with a download link and a remove × control. Removing an attachment deletes both the metadata row and the on-disk file. Attachment paths resolve directly on the local terminal backend, which is the default for Kanban workers. If you run workers on a remote backend Docker, Modal , mount the board's attachments/ directory into the sandbox so the absolute paths in the worker context are reachable. Quick start The commands below are you the human setting up the board and creating tasks. Once a task is assigned, the dispatcher spawns the assigned profile as a worker, and from there the model drives the task through kanban tool calls, not CLI commands — see How workers interact with the board how-workers-interact-with-the-board . 1. Create the board you hermes kanban init 2. Start the gateway hosts the embedded dispatcher hermes gateway start 3. Create a task you — or an orchestrator agent via kanban create hermes kanban create "research AI funding landscape" --assignee researcher 4. Watch activity live you hermes kanban watch 5. See the board you hermes kanban listhermes kanban stats When the dispatcher picks up t abcd and spawns the researcher profile, the very first thing that worker's model does is call kanban show to read its task. It doesn't run hermes kanban show t abcd . Gateway-embedded dispatcher default The dispatcher runs inside the gateway process. Nothing to install, no separate service to manage — if the gateway is up, ready tasks get picked up on the next tick 60s by default . config.yamlkanban: dispatch in gateway: true default dispatch interval seconds: 60 default review dispatch: true default: spawn the assigned profile with the bundled sdlc-review skill. Set false for human-only review boards. Override the config flag at runtime via HERMES KANBAN DISPATCH IN GATEWAY=0 for debugging. Standard gateway supervision applies: run hermes gateway start directly, or wire the gateway up as a systemd user unit see the gateway docs . Without a running gateway, ready tasks stay where they are until one comes up — hermes kanban create warns about this at creation time. Running hermes kanban daemon as a separate process is deprecated ; use the gateway. If you truly cannot run the gateway headless host policy forbids long-lived services, etc. a --force escape hatch keeps the old standalone daemon alive for one release cycle, but running both a gateway-embedded dispatcher AND a standalone daemon against the same kanban.db causes claim races and is not supported. Idempotent create for automation / webhooks First call creates the task. Any subsequent call with the same key returns the existing task id instead of duplicating.hermes kanban create "nightly ops review" \ --assignee ops \ --idempotency-key "nightly-ops-$ date -u +%Y-%m-%d " \ --json Bulk CLI verbs All the lifecycle verbs accept multiple ids so you can clean up a batch in one command: hermes kanban complete t abc t def t hij --result "batch wrap"hermes kanban archive t abc t def t hijhermes kanban unblock t abc t defhermes kanban block t abc "need input" --ids t def t hij unblock restores the safe source phase: review for reviewer-origin work whose parents are complete, ready for implementation work whose parents are complete, or todo while any parent remains open. A todo task keeps its source-phase provenance and returns to review or ready automatically when the dependency gate clears. unblock never routes directly to triage . If you unblock a task and it later shows up in triage , the unblock is not what put it there. A subsequent re-block for the same reason did: after a task is blocked → unblocked → re-blocked for the same cause BLOCK RECURRENCE LIMIT times default 2 , the unblock-loop breaker stops sending it back to blocked — where a cron would just keep unblocking it — and routes it to triage for a human decision. This is a deterministic DB guard, not an LLM judgment call, and a task's body text cannot opt out of it: the recurrence counter deliberately survives each unblock it resets only on a successful complete . To keep an unblocked task in the work pool, resolve why it keeps re-blocking unfinished parent, missing input, unmet capability before unblocking, or raise BLOCK RECURRENCE LIMIT if the loop is expected. How workers interact with the board Workers do not shell out to hermes kanban . When the dispatcher spawns a worker it sets HERMES KANBAN TASK=t abcd in the child's env, and that env var flips on a dedicated kanban toolset in the model's schema. The same toolset is also available to orchestrator profiles that enable kanban in their toolsets config. These tools read and mutate the board directly via the Python kanban db layer, same as the CLI does. A running worker calls these like any other tool; it never sees or needs the hermes kanban CLI. | Tool | Purpose | Required params | |---|---|---| | kanban show | Read the current task title, body, prior attempts, parent handoffs, comments, full pre-formatted worker context . Defaults to the env's task id. | — | | kanban list | List task summaries with filters for assignee , status , tenant , archived visibility, and limit. Intended for orchestrators discovering board work. | — | | kanban complete | Finish with summary + metadata structured handoff. | at least one of summary / result | | kanban request review | Start same-card review with a durable summary , optional metadata , and optional reviewer profile. The task moves to review ; this is not a block. | summary | | kanban request changes | Reviewer verdict from an active review run. Closes that run, reapplies parent gating, and routes the task to its original implementer without block-loop accounting. | reason | | kanban block | Stop work and route by why: kind=dependency waits in todo , auto-resumes , needs input / capability / transient surface to a human . Repeated same-kind re-blocks auto-escalate to triage . | reason | | kanban heartbeat | Signal liveness during long operations. Pure side-effect. | — | | kanban comment | Append a durable note to the task thread. | task id , body | | kanban attach | Attach a file to a task by passing its bytes inline base64 ; stored under the task's attachments dir 25 MB cap . | file bytes + name | | kanban attach url | Attach a file to a task by URL. | url | | kanban attachments | List a task's attachments. | — | | kanban create | Orchestrators fan out into child tasks with an assignee , optional parents , skills , etc. | title , assignee | | kanban link | Orchestrators add a parent id → child id dependency edge after the fact. | parent id , child id | | kanban unblock | Orchestrators restore a blocked task to its source phase review or ready , or todo while a parent remains open. | task id | A typical worker turn looks like: Model's tool calls, in order:kanban show no args — uses HERMES KANBAN TASK model reads the returned worker context, does the work via terminal/file tools kanban heartbeat note="halfway through — 4 of 8 files transformed" more work kanban complete summary="migrated limiter.py to token-bucket; added 14 tests, all pass", metadata={"changed files": "limiter.py", "tests/test limiter.py" , "tests run": 14}, An orchestrator worker fans out instead: kanban show kanban create title="research ICP funding 2024-2026", assignee="researcher-a", body="focus on seed + series A, North America, AI-adjacent", → returns {"task id": "t r1", ...}kanban create title="research ICP funding — EU angle", assignee="researcher-b", body="…" → returns {"task id": "t r2", ...}kanban create title="synthesize findings into launch brief", assignee="writer", parents= "t r1", "t r2" , promotes to ready when both complete body="one-pager, 300 words, neutral tone", kanban complete summary="decomposed into 2 research tasks + 1 writer; linked dependencies" The " Orchestrators " tools — kanban list , kanban create , kanban link , kanban unblock , and kanban comment on foreign tasks — are available through the same toolset; the convention encoded in the auto-injected kanban guidance is that worker profiles don't fan out or route unrelated work, and orchestrator profiles don't execute implementation work. Dispatcher-spawned workers are still task-scoped for destructive lifecycle operations and cannot mutate unrelated tasks. Why tools instead of shelling to hermes kanban Three reasons: 1. Backend portability. Workers whose terminal tool points at a remote backend Docker / Modal / Singularity / SSH would run hermes kanban complete inside the container, where hermes isn't installed and ~/.hermes/kanban.db isn't mounted. The kanban tools run in the agent's own Python process and always reach ~/.hermes/kanban.db regardless of terminal backend. 2. No shell-quoting fragility. Passing --metadata '{"files": ... }' through shlex + argparse is a latent footgun. Structured tool args skip it entirely. 3. Better errors. Tool results are structured JSON the model can reason about, not stderr strings it has to parse. Zero schema footprint on normal sessions. A regular hermes chat session has zero kanban tools in its schema unless the active profile explicitly enables the kanban toolset for orchestrator work. Dispatcher-spawned task workers get task-scoped tools because HERMES KANBAN TASK is set; orchestrator profiles get the broader routing surface through config. No tool bloat for users who never touch kanban. The auto-injected kanban guidance teaches the model which tool to call when and in what order. Recommended handoff evidence kanban complete summary=..., metadata={...} is intentionally flexible: the summary is the human-readable closeout, and metadata is the machine-readable handoff that downstream agents, reviewers, or dashboards can reuse without scraping prose. For engineering and review tasks, prefer this optional metadata shape: { "changed files": "path/to/file.py" , "verification": "pytest tests/hermes cli/test kanban db.py -q" , "dependencies": "parent task id or external issue, if any" , "blocked reason": null, "retry notes": "what failed before, if this was a retry", "residual risk": "what was not tested or still needs human review" } These keys are a convention, not a schema requirement. The useful property is that every worker leaves enough evidence for the next reader to answer four questions quickly: 1. What changed? 2. How was it verified? 3. What can unblock or retry this if it fails? 4. What risk is still deliberately left open? Keep secrets, raw logs, tokens, OAuth material, and unrelated transcripts out of metadata . Store pointers and summaries instead. If a task has no files or tests, say so explicitly in summary and use metadata for the evidence that does exist, such as source URLs, issue ids, or manual review steps. The worker lifecycle Every profile that works kanban tasks automatically gets the worker lifecycle — it's injected into the worker's system prompt at spawn the KANBAN GUIDANCE block , so there is nothing to install or configure . It teaches the worker the full lifecycle in tool calls , not CLI commands: 1. On spawn, call kanban show to read title + body + parent handoffs + prior attempts + full comment thread. 2. cd $HERMES KANBAN WORKSPACE via the terminal tool and do the work there. 3. Call kanban heartbeat note="..." every few minutes during long operations. If your work may run longer than 1 hour, call kanban heartbeat at least once an hour — the dispatcher reclaims tasks that have been running past kanban.dispatch stale timeout seconds default 4 h with no heartbeat in the last hour, on the assumption the worker crashed without cleanup. A reclaim is benign the task goes back to ready for re-dispatch without a failure-counter tick but you lose your current run's progress. 4. Complete with kanban complete summary="...", metadata={...} , or kanban block reason="..." if stuck. That final kanban complete / kanban block call is part of the worker protocol. If the worker process exits with status 0 while the task is still running , the dispatcher treats that as a protocol violation and emits a protocol violation event. Agent-side prevention: Before the worker exits, Hermes injects up to two synthetic nudges when it detects the model is about to stop without a terminal board tool call. This catches the common case where the model narrates the next step "Let me write the report" and stops with finish reason=stop . The nudge reminds the model to call kanban complete or kanban block immediately. This guard is active only for dispatcher-spawned workers HERMES KANBAN TASK is set and can be disabled with HERMES KANBAN STOP NUDGE=0 . Dispatcher-side recovery: If the nudges are exhausted or the worker crashes before reaching the nudge, the dispatcher gives the violation a bounded retry up to PROTOCOL VIOLATION FAILURE LIMIT consecutive violations, default 3 before auto-blocking the task instead of respawning it into the same loop. The budget counts only consecutive clean-exit protocol violations — interleaved rate-limited requeues are neutral, and any other failure kind resets the streak — and a per-task max retries overrides the bound. This usually means the model wrote a plain-text answer and exited without using the Kanban tool surface. The lifecycle plus the load-bearing reference details workspace kinds, deliverable artifacts , claiming created cards ship in that system-prompt block, so every worker has them regardless of which profile it runs under — no per-profile skill setup required. Pinning extra skills to a specific task Sometimes a single task needs specialist context the assignee profile doesn't carry by default — a translation job that needs the translation skill, a review task that needs github-code-review , a security audit that needs security-pr-audit . Rather than editing the assignee's profile every time, attach the skills directly to the task. From an orchestrator agent the usual case — one agent routing work to another , use the kanban create tool's skills array: kanban create title="translate README to Japanese", assignee="linguist", skills= "translation" , kanban create title="audit auth flow", assignee="reviewer", skills= "security-pr-audit", "github-code-review" , From a human CLI / slash command , repeat --skill for each one: hermes kanban create "translate README to Japanese" \ --assignee linguist \ --skill translationhermes kanban create "audit auth flow" \ --assignee reviewer \ --skill security-pr-audit \ --skill github-code-review From the dashboard , type the skills comma-separated into the skills field of the create-task dialog. The dispatcher emits one --skills <name flag per skill listed, so the worker spawns with all of them loaded on top of the auto-injected kanban guidance. The skill names must match skills that are actually installed on the assignee's profile run hermes skills list to see what's available ; there's no runtime install. Per-task model override Pin a task's worker to a specific model and optionally provider , independent of the assignee profile's default: At creationhermes kanban create "hard refactor" --assignee coder \ --model claude-opus-4.6 --provider anthropic Or later — takes effect on the next dispatchhermes kanban set-model t abcd claude-opus-4.6 --provider anthropichermes kanban set-model t abcd none clear the override The dispatcher spawns the worker with the pinned model --provider <name is passed when set; --provider requires a model . The dashboard's per-task model dropdown drives the same model override field. With no override, the worker uses its profile's configured model. Cost strategy: frontier orchestrator, inexpensive workers Kanban's per-profile configs make the planner/worker cost split natural. Decomposing a project into well-scoped cards takes frontier-level judgment; executing a card that already carries a clear goal, context, and handoff evidence usually doesn't — and the workers are where the vast majority of tokens are spent, so the worker model is where the cost lives. Run your orchestrator/dispatcher profile on a frontier model and point worker profiles at inexpensive models. Each profile has its own config.yaml under ~/.hermes/profiles/<name / , and the dispatcher injects the profile-scoped HERMES HOME when it spawns hermes -p <assignee , so each worker reads its own profile's model settings: ~/.hermes/config.yaml orchestrator / dispatcher profile model: default: "your-frontier-model" ~/.hermes/profiles/coder/config.yaml worker profile model: default: "your-inexpensive-model" ~/.hermes/profiles/researcher/config.yaml another worker profile model: default: "your-inexpensive-model" For the occasional quality-sensitive card, pin just that task back to a stronger model with the per-task model override per-task-model-override --model / --provider at create time, hermes kanban set-model later, or the dashboard's model dropdown — no profile edits needed. Lifecycle plugin hooks Board transitions fire plugin hooks /docs/user-guide/features/hooks plugin-hooks : kanban task claimed , kanban task completed , and kanban task blocked , each carrying task id and profile name . Hooks fire after the board DB change commits, so callbacks always see durable state. Note the process split: kanban task claimed fires in the dispatcher process, while kanban task completed / kanban task blocked fire in the worker process — register the hook in the dispatcher profile to observe every transition centrally. python def register ctx : def on blocked task id=None, profile name=None, kw : ctx.dispatch tool "terminal", {"command": f"notify-send 'kanban blocked: {task id}'"} ctx.register hook "kanban task blocked", on blocked Goal-mode cards --goal By default each worker gets one shot at its card — do the work, call kanban complete / kanban block , exit. Pass --goal CLI or goal mode=True the kanban create tool / dashboard to instead run that worker in a goal loop , the same Ralph-style engine behind the /goal slash command: after every turn an auxiliary judge checks the worker's output against the card's title + body treated as the acceptance criteria , and if the work isn't done — and the turn budget remains — the worker keeps going in the same session until the judge agrees, the worker terminates the task itself, or the budget runs out which blocks the card for human review rather than exiting silently . If the judge rules the goal unachievable as written, the card is blocked immediately with the judge's reason — an impossible card is never marked done, and kanban complete / kanban request-review on such a card are rejected with a pointer to kanban block or re-scoping. hermes kanban create "Translate the docs site to French" \ --body "Acceptance: every page translated, no English left, links intact." \ --assignee linguist \ --goal \ --goal-max-turns 15 optional; default 20 Use it for open-ended, multi-step, or "keep going until X is true" cards. Skip it for cheap one-shot work — the per-turn judge overhead isn't worth it, and the dispatcher's existing retry/circuit-breaker already handles transient worker failures. The judge is only as good as your goal text, so write the body as explicit acceptance criteria . /goal engine — they don't connect to it --goal runs the continuation loop inside that one card's worker session . It shares the engine with the /goal slash command /docs/user-guide/features/goals , not the state: setting a /goal in a chat session never creates, claims, or moves a kanban card, and a goal-mode card's loop is invisible to any chat session's /goal status . If you want this conversation to keep iterating, use /goal /docs/user-guide/features/goals ; if you want work on the board, create a card. How the orchestrator behaves A well-behaved orchestrator does not do the work itself. It decomposes the user's goal into tasks, links them, assigns each to one of the profiles you've set up, and steps back. The orchestrator guidance — anti-temptation rules, a Step-0 profile-discovery prompt the dispatcher silently fails on unknown assignee names, so the orchestrator must ground every card in profiles that actually exist on your machine , and a decomposition playbook keyed on kanban create / kanban link / kanban comment — is injected into the worker's system prompt automatically; there is nothing to install. A canonical orchestrator turn two parallel researchers handing off to a writer : Goal from user: "draft a launch post on the ICP funding landscape"kanban create title="research ICP funding, NA angle", assignee="researcher-a", body="…" → t r1kanban create title="research ICP funding, EU angle", assignee="researcher-b", body="…" → t r2kanban create title="synthesize ICP funding research into launch post draft", assignee="writer", parents= "t r1", "t r2" , promoted to 'ready' when both researchers complete body="one-pager, neutral tone, cite sources inline", → t w1 Optional: add cross-cutting deps discovered later without re-creating taskskanban link parent id="t r1", child id="t followup" kanban complete summary="decomposed into 2 parallel research tasks → 1 synthesis task; writer starts when both researchers finish", The orchestrator guidance ships in the worker's system prompt automatically — there is nothing to install or sync per profile. Decide before you fan out. Design decisions belong to the orchestrator, not to the workers. If two parallel cards would each have to pick the same thing — a naming scheme, a schema, a file format, an API shape — the orchestrator decides it once and stamps the decision into both card bodies. Workers cannot see sibling cards, so every child card body must carry every decision it depends on. Example: for the parallel cards "build the exporter" and "build the importer", don't let each worker invent its own file format — pick one up front say, newline-delimited JSON with a version field and write it into both bodies, or the two halves will never round-trip. For best results, pair it with a profile whose toolsets are restricted to board operations kanban , gateway , memory so the orchestrator literally cannot execute implementation tasks even if it tries. Dashboard GUI The /kanban CLI and slash command are enough to run the board headlessly, but a visual board is often the right interface for humans-in-the-loop: triage, cross-profile supervision, reading comment threads, and dragging cards between columns. Hermes ships this as a bundled dashboard plugin at plugins/kanban/ — not a core feature, not a separate service — following the model laid out in Extending the Dashboard /docs/user-guide/features/extending-the-dashboard . Open it with: hermes kanban init one-time: create kanban.db if not already presenthermes dashboard "Kanban" tab appears in the nav, after "Skills" What the plugin gives you - A Kanban tab showing one column per status: triage , todo , ready , running , blocked , done plus archived when the toggle is on . - triage is the parking column for rough ideas. By default kanban.auto decompose: true , the dispatcher auto-runs the decomposer on tasks that land here. The built-in decomposer uses the auxiliary.kanban decomposer model path, reads your profile roster with descriptions , and fans the task out into a small graph of child tasks routed to the best-fit specialists. The original task stays alive as the parent of every child so its assignee kanban.orchestrator profile , or the active default profile when unset wakes back up to judge completion when everything finishes. Flip the Orchestration: Auto/Manual pill at the top of the page emerald = Auto, muted gray = Manual , or by editing config.yaml directly. Both modes coexist with hermes kanban specify - that's still available as a single-task spec rewrite when you don't want fan-out. - Cards show the task id, title, priority badge, tenant tag, assigned profile, comment/link counts, a progress pill N/M children done when the task has dependents , and "created N ago". A per-card checkbox enables multi-select. - Per-profile lanes inside Running — toolbar checkbox toggles sub-grouping of the Running column by assignee. - Live updates via WebSocket — the plugin tails the append-only task events table on a short poll interval; the board reflects changes the instant any profile CLI, gateway, or another dashboard tab acts. Reloads are debounced so a burst of events triggers a single refetch. - Drag-drop cards between columns to change status. The drop sends PATCH /api/plugins/kanban/tasks/:id which routes through the same kanban db code the CLI uses — the three surfaces can never drift. Moves into destructive statuses done , archived , blocked prompt for confirmation. Touch devices use a pointer-based fallback so the board is usable from a tablet. - Create-task dialog — click + on any column header to open a modal with labeled fields: title, assignee, priority, skills, workspace kind/path seeded from the board's project directory; per-task override , goal mode, and optionally a parent task from a dropdown over every existing task. Press Enter to create the task, Shift+Enter to insert a newline in the title field, or Escape to cancel. Creating from the Triage column automatically parks the new task in triage. - Multi-select with bulk actions — shift/ctrl-click a card or tick its checkbox to add it to the selection. A bulk action bar appears at the top with batch status transitions, archive, and reassign by profile dropdown, or " unassign " . Destructive batches confirm first. Per-id partial failures are reported without aborting the rest. - Click a card without shift/ctrl to open a side drawer Escape or click-outside closes with: - Editable title — click the heading to rename. - Editable assignee / priority — click the meta row to rewrite. - Editable description — markdown-rendered by default headings, bold, italic, inline code, fenced code, http s / mailto: links, bullet lists , with an "edit" button that swaps in a textarea. Markdown rendering is a tiny, XSS-safe renderer — every substitution runs on HTML-escaped input, only http s / mailto: links pass through, and target=" blank" + rel="noopener noreferrer" are always set. - Dependency editor — chip list of parents and children, each with an × to unlink, plus dropdowns over every other task to add a new parent or child. Cycle attempts are rejected server-side with a clear message. - Status action row → triage / → ready / → running / block / unblock / complete / archive with confirm prompts for destructive transitions. For cards in the Triage column the row also exposes two LLM-driven actions: ⚗ Decompose fans the task out into a graph of child tasks routed to specialist profiles by description, and ✨ Specify does a single-task spec rewrite. Decompose falls back to specify-style promotion when the LLM decides the task doesn't benefit from fan-out, so it's a strict superset. Both are reachable from the CLI hermes kanban decompose <id / specify <id / --all , from any gateway platform /kanban decompose <id , and programmatically via POST /api/plugins/kanban/tasks/:id/decompose and …/specify . Configure the models under auxiliary.kanban decomposer and auxiliary.triage specifier in config.yaml . - Result section also markdown-rendered , comment thread with Enter-to-submit, the last 20 events. - Toolbar filters — free-text search, tenant dropdown defaults to dashboard.kanban.default tenant from config.yaml , assignee dropdown, "show archived" toggle, "lanes by profile" toggle, and a Nudge dispatcher button so you don't have to wait for the next 60 s tick. Visually the target is the familiar Linear / Fusion layout: dark theme, column headers with counts, coloured status dots, pill chips for priority and tenant. The plugin reads only theme CSS vars --color- , --radius , --font-mono , ... , so it reskins automatically with whichever dashboard theme is active. Auto vs Manual orchestration The kanban board has two ways to handle a task you drop into the Triage column: Auto default — kanban.auto decompose: true . The gateway-embedded dispatcher runs the decomposer on each tick, capped by kanban.auto decompose per tick default 3 tasks per tick so a bulk-load of triage tasks doesn't burst-spend the auxiliary LLM. The decomposer uses the built-in decomposition prompt plus the auxiliary.kanban decomposer model path, reads your installed profiles + their descriptions, and asks the LLM to produce a JSON task graph: which tasks to spawn, who they go to, and which depend on which. The original triage task becomes the parent of every leaf in the graph, so it stays alive until the whole graph completes - and then promotes back to ready so its assignee kanban.orchestrator profile , or the active default profile when unset can judge completion and add more tasks if the work isn't done. This is the "drop a one-liner, walk away" flow. A completed built-in fan-out is recorded atomically with its child graph. Moving that root back to Triage does not create another graph; ordinary prerequisite links do not prevent a task's first decomposition. The completion marker survives event retention until the task is deleted. This is not semantic deduplication of independently created manual graphs, nor a repair for previously pruned history. When a new task omits its tenant, creation inherits the first nonempty tenant among its parents, in supplied order. An explicit tenant including the worker's active tenant passed by tools wins. Boards remain the hard isolation boundary. Manual — kanban.auto decompose: false . Triage tasks stay in triage until you act. Click the ⚗ Decompose button on a card, run hermes kanban decompose <id or --all , or use /kanban decompose <id from a chat. This matches the pre-decomposer behavior of the board, useful when you want full control over what runs when. Important boundary: Manual mode disables only the built-in Triage decomposer. It does not prevent a profile from calling kanban create , and it does not disable creator-session wake-ups. With kanban.auto subscribe on create: true , a task's terminal event resumes the originating agent with a synthetic status turn so it can inspect the handoff and decide whether genuinely new follow-up work is needed. Set auto subscribe on create: false when task completion should remain passive. For provenance, built-in decomposer children use created by=auto-decomposer ; tasks created by a resumed profile carry that profile name instead. Flip between the two modes from the Orchestration: Auto/Manual pill at the top of the kanban page emerald = Auto, muted gray = Manual , or by editing config.yaml directly. Both modes coexist with hermes kanban specify — that's still available as a single-task spec rewrite when you don't want fan-out. The decomposer's routing decisions depend on profile descriptions, which is a per-profile labeling primitive you set with hermes profile create --description "..." , hermes profile describe <name --text "..." , hermes profile describe <name --auto LLM-generates from the profile's installed skills + model , or the dashboard's per-profile editor in the expanded Orchestration settings panel. Profiles without a description still appear in the roster — they're routable by name, just less precisely. The decomposer NEVER lands a child task with assignee=None : when the LLM picks an unknown profile, the child gets routed to kanban.default assignee or the active default profile if that's unset . kanban.orchestrator profile does not load that profile's prompt, skills, or custom logic into the decomposition call. It controls who owns the root/orchestration task after fan-out. To change the decomposer's model/provider, configure auxiliary.kanban decomposer . To use a profile's custom task-splitting logic instead of the built-in decomposer, switch to Manual mode and have that profile create or decompose tasks explicitly. Config knobs all under kanban: in ~/.hermes/config.yaml : | Key | Default | Purpose | |---|---|---| | auto decompose | true | Dispatcher auto-runs the built-in decomposer for Triage tasks every tick. It does not gate profile-driven kanban create calls or creator wake turns. | | auto decompose per tick | 3 | Cap on decompositions per dispatcher tick. Excess defers to the next tick. | | orchestrator profile | "" | Profile assigned to the root/orchestration task after decomposition. Empty = fall back to active default profile. | | default assignee | "" | Where a child task lands when the LLM picks an unknown profile. Empty = fall back to active default. | | auto subscribe on create | true | When kanban create runs inside a persistent gateway/TUI session, terminal events resume that originating agent with a synthetic status turn. Set to false for passive completion or to require explicit kanban notify-subscribe calls. Independent of auto decompose . | | done sub retention days | 30 | Notify subscriptions survive done reopen-safe and are removed on archived . The notifier GC purges subscriptions whose task has been done or blocked with no new events for this many days, bounding sub-table growth on boards that never archive. 0 disables the sweep. | And the two auxiliary LLM slots: | Key | Purpose | |---|---| | auxiliary.kanban decomposer | Model that produces the task graph called by Decompose . Set provider / model to override the main chat model. | | auxiliary.profile describer | Model that auto-generates profile descriptions called by hermes profile describe --auto . | Architecture The GUI is strictly a read-through-the-DB + write-through-kanban db layer with no domain logic of its own: ┌────────────────────────┐ WebSocket tails task events │ React SPA plugin │ ◀──────────────────────────────────┐│ HTML5 drag-and-drop │ │└──────────┬─────────────┘ │ │ REST over fetchJSON │ ▼ │┌────────────────────────┐ writes call kanban db. ││ FastAPI router │ directly — same code path ││ plugins/kanban/ │ the CLI /kanban verbs use ││ dashboard/plugin api.py │└──────────┬─────────────┘ │ │ │ ▼ │┌────────────────────────┐ ││ ~/.hermes/kanban.db │ ───── append task events ──────────┘│ WAL, shared │└────────────────────────┘ REST surface All routes are mounted under /api/plugins/kanban/ and protected by the dashboard's ephemeral session token: | Method | Path | Purpose | |---|---|---| | GET | /board?tenant=<name &include archived=… | Full board grouped by status column, plus tenants + assignees for filter dropdowns | | GET | /tasks/:id | Task + comments + events + links | | POST | /tasks | Create wraps kanban db.create task , accepts triage: bool and parents: id, … | | PATCH | /tasks/:id | Status / assignee / priority / title / body / result | | POST | /tasks/bulk | Apply the same patch status / archive / assignee / priority to every id in ids . Per-id failures reported without aborting siblings | | POST | /tasks/:id/comments | Append a comment | | POST | /tasks/:id/specify | Run the triage specifier — auxiliary LLM fleshes out the task body and promotes it from triage to todo . Returns {ok, task id, reason, new title} ; ok=false with a human-readable reason on "not in triage" / no aux client / LLM error is a 200, not a 4xx | | POST | /tasks/:id/decompose | Run the kanban decomposer — auxiliary LLM produces a task graph and the helper atomically creates the children + links the root + flips triage → todo . Returns {ok, task id, reason, fanout, child ids, new title} . Same 200-on-LLM-error convention as /specify . | | GET | /profiles | List installed profiles with their descriptions consumed by the dashboard's profile-description editor and the orchestrator picker . | | PATCH | /profiles/:name | Set or clear a profile's description user-authored — description auto: false . Returns {ok, profile, description} . | | POST | /profiles/:name/describe-auto | Generate a description for a profile via auxiliary.profile describer . Persists with description auto: true so the dashboard can surface a "review" badge. | | GET | /orchestration | Read the kanban orchestration settings orchestrator profile , default assignee , auto decompose plus the resolved effective values after fallbacks. | | PUT | /orchestration | Update one or more of the three orchestration keys in config.yaml . Validates that non-empty profile names actually exist. | | POST | /links | Add a dependency parent id → child id | | DELETE | /links?parent id=…&child id=… | Remove a dependency | | POST | /dispatch?max=…&dry run=… | Nudge the dispatcher — skip the 60 s wait | | GET | /config | Read dashboard.kanban preferences from config.yaml — default tenant , lane by profile , include archived by default , render markdown | | WS | /events?since=<event id | Live stream of task events rows | Every handler is a thin wrapper — the plugin is ~700 lines of Python router + WebSocket tail + bulk batcher + config reader and adds no new business logic. A tiny conn helper auto-initializes kanban.db on every read and write, so a fresh install works whether the user opened the dashboard first, hit the REST API directly, or ran hermes kanban init . Dashboard config Any of these keys under dashboard.kanban in ~/.hermes/config.yaml changes the tab's defaults — the plugin reads them at load time via GET /config : dashboard: kanban: default tenant: acme preselects the tenant filter lane by profile: true default for the "lanes by profile" toggle include archived by default: false render markdown: true set false for plain <pre rendering Each key is optional and falls back to the shown default. Security model The dashboard's HTTP auth middleware explicitly skips /api/plugins/ /docs/user-guide/features/extending-the-dashboard backend-api-routes — plugin routes are unauthenticated by design because the dashboard binds to localhost by default. That means the kanban REST surface is reachable from any process on the host. The WebSocket takes one additional step: it requires the dashboard's ephemeral session token as a ?token=… query parameter browsers can't set Authorization on an upgrade request , matching the pattern used by the in-browser PTY bridge. If you run hermes dashboard --host 0.0.0.0 , every plugin route — kanban included — becomes reachable from the network. Don't do that on a shared host. The board contains task bodies, comments, and workspace paths; an attacker reaching these routes gets read access to your entire collaboration surface and can also create / reassign / archive tasks. Tasks in ~/.hermes/kanban.db are profile-agnostic on purpose that's the coordination primitive . If you open the dashboard with hermes -p <profile dashboard , the board still shows tasks created by any other profile on the host. Same user owns all profiles, but this is worth knowing if multiple personas coexist. Live updates task events is an append-only SQLite table with a monotonic id . The WebSocket endpoint holds each client's last-seen event id and pushes new rows as they land. When a burst of events arrives, the frontend reloads the very cheap board endpoint — simpler and more correct than trying to patch local state from every event kind. WAL mode means the read loop never blocks the dispatcher's BEGIN IMMEDIATE claim transactions. Extending it The plugin uses the standard Hermes dashboard plugin contract — see Extending the Dashboard /docs/user-guide/features/extending-the-dashboard for the full manifest reference, shell slots, page-scoped slots, and the Plugin SDK. Extra columns, custom card chrome, tenant-filtered layouts, or full tab.override replacements are all expressible without forking this plugin. To disable without removing: add dashboard.plugins.kanban.enabled: false to config.yaml or delete plugins/kanban/dashboard/manifest.json . Scope boundary The GUI is deliberately thin. Everything the plugin does is reachable from the CLI; the plugin just makes it comfortable for humans. Auto-assignment, budgets, governance gates, and org-chart views remain user-space — a router profile, another plugin, or a reuse of tools/approval.py — exactly as listed in the out-of-scope section of the design spec. CLI command reference This is the surface you or scripts, cron, the dashboard use to drive the board. Workers running inside the dispatcher use the kanban tool surface how-workers-interact-with-the-board for the same operations — the CLI here and the tools there both route through kanban db , so the two surfaces agree by construction. hermes kanban init create kanban.db + print daemon hinthermes kanban create "<title " --body ... --assignee <profile --parent <id ... --tenant <name --workspace scratch|worktree|worktree:<path |dir:<path --branch <name --priority N --triage --idempotency-key KEY --max-runtime 30m|2h|1d|<seconds --max-retries N --goal --goal-max-turns N --skill <name ... --json hermes kanban list --mine --assignee P --status S --tenant T --archived --workflow-template-id <id --current-step-key <key --sort created|created-desc|priority|priority-desc|status|assignee|title|updated --json hermes kanban show <id --json hermes kanban assign <id <profile or 'none' to unassignhermes kanban reassign <id ... <profile bulk re-assign tasks to a profilehermes kanban edit <id --title ... --body ... edit task title / body / priority in place --priority N hermes kanban promote <id ... move todo/blocked tasks to ready recovery hermes kanban schedule <id --at <ISO8601 set/clear a task's scheduled at start timehermes kanban diagnostics --json board health snapshot alias: diag hermes kanban link <parent id <child id hermes kanban unlink <parent id <child id hermes kanban claim <id --ttl SECONDS hermes kanban comment <id "<text " --author NAME Bulk verbs — accept multiple ids:hermes kanban complete <id ... --result "..." hermes kanban block <id "<reason " --ids <id ... hermes kanban unblock <id ...hermes kanban archive <id ...hermes kanban request-review <id --summary "..." --metadata JSON --reviewer PROFILE hermes kanban request-changes <id "<required changes " active reviewer - implementerhermes kanban reopen-review <id ... --reason "..." changes requested: 'review' - ready/todohermes kanban tail <id follow a single task's event streamhermes kanban watch --assignee P --tenant T live stream ALL events to the terminal --kinds completed,blocked,… --interval SECS hermes kanban heartbeat <id --note "..." worker liveness signal for long opshermes kanban runs <id --json attempt history one row per run hermes kanban assignees --json profiles on disk + per-assignee task countshermes kanban dispatch --dry-run --max N one-shot pass --failure-limit N --json hermes kanban daemon --force DEPRECATED — standalone dispatcher use hermes gateway start instead --failure-limit N --pidfile PATH -v hermes kanban stats --json per-status + per-assignee countshermes kanban log <id --tail BYTES worker log from ~/.hermes/kanban/logs/hermes kanban notify-subscribe <id gateway bridge hook used by /kanban in the gateway --platform <name --chat-id <id --thread-id <id --user-id <id --chat-type dm|group|channel|thread --delivery-mode notify|notify+wake|wake hermes kanban notify-list <id --json hermes kanban notify-unsubscribe <id --platform <name --chat-id <id --thread-id <id hermes kanban context <id what a worker seeshermes kanban specify <id | --all --tenant T flesh out a triage-column idea --author NAME --json into a full spec and promote to todohermes kanban gc --event-retention-days N workspaces + old events + old logs --log-retention-days N All commands are also available as a slash command in the interactive CLI and in the messaging gateway see /kanban slash command kanban-slash-command below . --max-retries is a per-task circuit-breaker override for the dispatcher. --max-retries 1 blocks the task on the first non-successful attempt, while --max-retries 3 allows two retries and blocks on the third failure. Omit it to use kanban.failure limit from config.yaml , then the built-in default. Concurrency, scheduling, and child promotion config | Config key | Default | What it does | |---|---|---| | kanban.max in progress | unset unlimited | Caps the number of simultaneously running tasks. When the board already has N running, the dispatcher skips spawning more — useful for slow workers local LLMs, resource-constrained hosts so they finish what they have before more pile up and time out. Invalid or below-1 values log a warning and behave as unlimited. | | kanban.max in progress per profile | unset unlimited | Per-profile variant of max in progress — caps how many tasks any single assignee profile may run concurrently. Useful when one profile is slow or rate-limited but others should keep flowing. Applies alongside the board-wide max in progress ; both must allow a spawn for it to proceed. | | kanban.auto promote children | true | After decompose triage task produces children with no parent-blocker dependencies, they're automatically promoted to ready so the dispatcher can pick them up. Set to false to require manual review — children stay in todo until you promote them. | | kanban.default workdir | unset | Board-level default working directory applied to new tasks when neither --workspace nor the task itself overrides it. Per-task workspace: still wins. | kanban: max in progress: 2 auto promote children: false default workdir: ~/work/active-project Scheduled task starts scheduled at Set scheduled at on a task to delay dispatch until a specific time. The dispatcher skips ready tasks whose scheduled at is in the future and picks them up on the first tick after that timestamp. hermes kanban create "nightly backup audit" \ --assignee ops --scheduled-at "2026-06-01T03:00:00Z" Respawn guard The dispatcher refuses to re-spawn a ready task when it hit a quota/auth/429 error on the previous run blocker auth , or completed a run successfully within the guard window recent success , or a recent task comment links to a GitHub PR active pr . This prevents repeat worker storms on the same bug or task while a human catches up. See the respawn guarded row in the event reference event-reference . Drag-to-delete and bulk delete dashboard The dashboard exposes a trash drop zone on the kanban page — drag any card into it to delete the task cascades through task events , child links, and subscriptions . A confirmation prompt protects against accidents. Bulk delete is also reachable via DELETE /api/plugins/kanban/tasks with a JSON body {"ids": "t abc", "t def", ... } . Worker visibility endpoints The dashboard plugin API now exposes these read-only endpoints plus a run-control verb for external monitors: | Endpoint | Returns | |---|---| | GET /api/plugins/kanban/workers/active | Currently spawned workers with PID, profile, task id, started-at, last heartbeat | | GET /api/plugins/kanban/runs/{id} | Single-run detail — task id, status, started/ended, exit code, log path | | POST /api/plugins/kanban/runs/{run id}/terminate | Terminate a reclaimable run — stops the worker and frees the task for re-dispatch | | GET /api/plugins/kanban/inspect | Combined dispatcher snapshot — backlog, in-progress count vs. max in progress , recent events | All of these are gated by the same dashboard plugin auth as the rest of the kanban plugin API. Kanban Swarm topology helper hermes kanban swarm creates a durable Kanban Swarm v1 graph in one shot: a completed root/blackboard card, N parallel worker cards, a verifier card gated on all workers, and a synthesizer card gated on the verifier. Shared swarm context the "blackboard" is stored as structured JSON comments on the root card so any worker can read it. hermes kanban swarm "Design a multi-region failover plan" \ --workers researcher,architect,sre \ --verifier reviewer --synthesizer writer The resulting graph is committed atomically: dispatchers and dashboard readers see either no new swarm or the complete topology, never a partially linked root/worker/verifier graph. It then dispatches normally — workers run in parallel, the verifier wakes after they all finish, and the synthesizer wakes after the verifier marks the work clean. /kanban slash command Every hermes kanban <action verb is also reachable as /kanban <action — from inside an interactive hermes chat session and from any gateway platform Telegram, Discord, Slack, WhatsApp, Signal, Matrix, Mattermost, email, SMS . Both surfaces call the exact same hermes cli.kanban.run slash entry point that reuses the hermes kanban argparse tree, so the argument surface, flags, and output format are identical across CLI, /kanban , and hermes kanban . You don't have to leave the chat to drive the board. /kanban list/kanban show t abcd/kanban create "write launch post" --assignee writer --parent t research/kanban comment t abcd "looks good, ship it"/kanban unblock t abcd/kanban dispatch --max 3/kanban specify t abcd flesh out a triage one-liner into a real spec/kanban specify --all --tenant engineering sweep every triage task in one tenant Quote multi-word arguments the same way you would on a shell — run slash parses the rest of the line with shlex.split , so "..." and '...' both work. Mid-run usage: /kanban bypasses the running-agent guard The gateway normally queues slash commands and user messages while an agent is still thinking — that's what stops you from accidentally starting a second turn while the first is in flight. /kanban is explicitly exempted from this guard. The board lives in ~/.hermes/kanban.db , not in the running agent's state, so reads list , show , context , tail , watch , stats , runs and writes comment , unblock , block , assign , archive , create , link , … all go through immediately, even mid-turn. This is the whole point of the separation: - A worker blocks waiting on a peer → you send /kanban unblock t abcd from your phone and the dispatcher picks the peer up on its next tick. The blocked worker isn't interrupted — it just stops being blocked. - You spot a card that needs human context → /kanban comment t xyz "use the 2026 schema, not 2025" lands on the task thread and the next run of that task will read it in kanban show . - You want to know what your fleet is doing without stopping the orchestrator → /kanban list --mine or /kanban stats inspects the board without touching your main conversation. Auto-subscribe on /kanban create gateway only When you create a task from the gateway with /kanban create "…" , the originating chat platform + chat id + thread id is automatically subscribed to that task's terminal events completed , blocked , gave up , crashed , timed out . You'll get one message back per terminal event — including the first line of the worker's result summary on completed — without having to poll or remember the task id. you /kanban create "transcribe today's podcast" --assignee transcriberbot Created t 9fc1a3 ready, assignee=transcriber subscribed — you'll be notified when t 9fc1a3 completes or blocks … ~8 minutes later …bot ✓ t 9fc1a3 completed by transcriber transcribed 42 minutes, saved to podcast/2026-05-04.md Subscriptions survive a task reaching done — completion is reversible a reviewer or controller can reopen a done task , so the origin session keeps getting notified through reopen cycles. They auto-remove on archived the irreversible end state . On boards that never archive, a GC sweep purges subscriptions for tasks that have sat in done or blocked with no new activity for kanban.done sub retention days days default 30; set 0 to disable , so stale rows don't accumulate forever. If you script a create with --json machine output the auto-subscribe is skipped — the assumption is that scripted callers want to manage subscriptions explicitly via /kanban notify-subscribe . Dispatcher workers creating tasks through kanban create or hermes kanban create copy the owning task's durable notification subscriptions even without parents dependency links. Destinations, route anchors, and delivery modes are preserved; a passive subscription is not upgraded to a wake by auto-subscribe. This copies existing subscriptions independently of auto subscribe on create , which controls adding the current conversation as a new destination. No destination is invented for a bare CLI session or a worker whose owning task has no subscriptions. For kanban create , session lineage resolves in this order: explicit session id , the owning worker task's durable session, request-scoped API origin, then the current process session. Built-in decomposition also inherits its root's durable session. Session lineage is not itself a notification destination: changing session id does not replace existing subscriptions; use notify-subscribe and notify-unsubscribe to change where events are delivered. A chat-originated auto-subscribe is created in notify+wake mode: on a terminal event the destination agent both receives the passive message and takes a real turn, so it can read the board context and reply in its own voice. See Delivery modes delivery-modes below. Output truncation in messaging Gateway platforms have practical message-length caps. If /kanban list , /kanban show , or /kanban tail produce more than ~3800 characters of output, the response is truncated with a … truncated; use \ hermes kanban … in your terminal for full output footer. The CLI surface has no such cap. Autocomplete In the interactive CLI, typing /kanban and hitting Tab cycles through the built-in subcommand list list , ls , show , create , assign , link , unlink , claim , comment , complete , block , unblock , archive , tail , dispatch , context , init , gc . The remaining verbs listed in the CLI reference above watch , stats , runs , log , assignees , heartbeat , notify-subscribe , notify-list , notify-unsubscribe , daemon also work — they're just not in the autocomplete hint list yet. Collaboration patterns The board supports these eight patterns without any new primitives: | Pattern | Shape | Example | |---|---|---| | P1 Fan-out | N siblings, same role | "research 5 angles in parallel" | | P2 Pipeline | role chain: scout → editor → writer | daily brief assembly | | P3 Voting / quorum | N siblings + 1 aggregator | 3 researchers → 1 reviewer picks | | P4 Long-running journal | same profile + shared dir + cron | Obsidian vault | | P5 Human-in-the-loop | worker blocks → user comments → unblock | ambiguous decisions | | P6 @mention | inline routing from prose | @reviewer look at this | | P7 Thread-scoped workspace | /kanban here in a thread | per-project gateway threads | | P8 Fleet farming | one profile, N subjects | 50 social accounts | | P9 Triage specifier | rough idea → triage → hermes kanban specify expands body → todo | "turn this one-liner into a spec'd task" | For worked examples of each, see docs/hermes-kanban-v1-spec.pdf . Handing context to follow-up cards the parent link A parent link is not just a scheduling gate — it is the context handoff channel from a completed card to a new one. When you create a card with --parent <done-card-id , two things happen: 1. It's immediately eligible. create task sets status by parent state: a child whose parents are all done is created directly in ready — no waiting, no manual promotion. Children of still-open parents sit in todo until recompute ready promotes them when the last parent finishes. 2. The parent's handoff rides along. The worker context assembled for the child build worker context , what kanban show returns contains a Parent task results section with each parent's completion summary and metadata , verbatim: Parent task results t 77c26979 completed just now Added exponential backoff with jitter to the retry helper. metadata : {"changed files": "hermes cli/retry.py", "tests/test retry.py" , "decisions": "capped backoff at 60s", "jitter = full" } This is why the pattern for follow-up work on a finished card is a new child card, not reopening the done card . Completed cards are immutable history — their context flows forward through the parent link. Same-card rework retry loops on a failing card is a different mechanism: prior attempts on the same card surface as "prior attempts" in that card's own context. A worktree or branch alone is not a substitute: repo state tells the follow-up worker what the code looks like, but not why — the decisions, tests run, and files touched live in the parent's structured handoff, not in git. Evidence that didn't exist when the parent completed e.g. a CI log that failed later belongs in the new card's body . Implementation card t impl is done. CI fails two hours later.hermes kanban create "Fix CI failure from t impl: test retry flakes on 3.11" \ --assignee coder \ --parent t impl \ --body "$ cat <<'EOF'CI run 4812 failed after t impl merged.Log excerpt: FAILED tests/test retry.py::test backoff jitter - TimeoutErrorAcceptance: tests/test retry.py green on 3.11 and 3.12 in CI.Use a fresh worktree/branch; do not force-push the original branch.EOF " The remediation worker spawns with the original card's summary and metadata changed files, decisions already in context, plus the fresh evidence you put in the body. Reconciling colliding worker branches In engineering pipelines P1/P2 with worktrees , two workers' branches can conflict when merged. Don't let either worker self-adjudicate — the colliding agent lacks its peer's context and reliably overwrites the other side or abandons its own. Instead, create a reconciliation card assigned to a third, neutral profile with both conflicted cards linked as parents: the parent links carry both sides' completion summaries into the reconciler's context, so it receives both diffs and both intents. The bundled agent-merge-conflict-arbiter optional skill https://github.com/NousResearch/hermes-agent/blob/main/optional-skills/autonomous-ai-agents/agent-merge-conflict-arbiter/SKILL.md gives that worker the full procedure: classify each conflicted hunk, resolve impartially, verify, and hand back a summary naming every decision. Collision hotspots in parallel campaigns In wide campaigns some files become collision magnets: many workers each add a little to the same file, nobody owns keeping it small, and it turns into the site of constant merge conflicts. The mitigation is a comment convention, not a new primitive. A worker that notices its diff keeps colliding with siblings in one file — or that a file it touches keeps appearing in other cards' recent comments — should not silently pile on. Instead it leaves a comment on its own card with a recognizable prefix: hotspot: hermes cli/kanban db.py — third conflicting edit to the dispatch loop this wave and repeats the flag in its completion metadata . Orchestrators or humans reviewing the board who see two or more hotspot: comments naming the same path should create a dedicated refactor/decomposition card for that file before queuing more work that touches it — splitting the magnet file is cheaper than reconciling every future collision it would cause. For conflicts that have already happened, use the reconciliation-card pattern above with the agent-merge-conflict-arbiter optional skill; hotspot flagging is the upstream fix that keeps the reconciler from becoming a standing lane. Multi-tenant usage When one specialist fleet serves multiple businesses, tag each task with a tenant: hermes kanban create "monthly report" \ --assignee researcher \ --tenant business-a \ --workspace dir:~/tenants/business-a/data/ Workers receive $HERMES TENANT and namespace their memory writes by prefix. The board, the dispatcher, and the profile definitions are all shared; only the data is scoped. Desktop notifications The Desktop app's Kanban plugin surfaces the same terminal events natively — no gateway platform required. While the Kanban board's live event socket is connected, each completed , blocked , gave up , crashed , timed out , or routed-to-triage block loop detected event raises an in-app toast with the worker's handoff summary, block reason, or error and an "Open Kanban" action. When you're away from the Hermes window, the same event also fires a native OS notification gated by Settings ▸ Notifications ▸ Plugin notifications , so a task hitting a blocker while you're in another app still reaches you. Coverage window: desktop notifications ride the live event stream, so they fire only while the app is running with the Kanban plugin enabled. Events that land while the app is closed are not replayed as notifications on next launch — use a gateway subscription below for delivery that must survive the app being closed. Gateway notifications When you run /kanban create … from the gateway Telegram, Discord, Slack, etc. , the originating chat is automatically subscribed to the new task. The gateway's background notifier polls task events every few seconds and delivers one message per terminal event completed , blocked , gave up , crashed , timed out to that chat. Completed tasks also send the first line of the worker's --result so you see the outcome without having to /kanban show . You can manage subscriptions explicitly from the CLI — useful when a script / cron job wants to notify a chat it didn't originate from: hermes kanban notify-subscribe t abcd \ --platform telegram --chat-id 12345678 --thread-id 7 \ --chat-type group --delivery-mode notify+wakehermes kanban notify-listhermes kanban notify-unsubscribe t abcd \ --platform telegram --chat-id 12345678 --thread-id 7 A subscription removes itself automatically once the task reaches done or archived ; no cleanup needed. Delivery modes --delivery-mode controls how the notifier reacts to a terminal event. Every subscription is in one of three modes notify is the default and the original behavior : | Mode | Passive message | Wakes the agent | Use it when | |---|---|---|---| | notify | yes | no | You just want a heads-up message in the chat default . | | notify+wake | yes | yes | You also want the destination agent to take a real turn — read the board context and reply in its own voice. Chat-originated auto-subscribes use this. | | wake | no | yes | You only want the agent to act on the event, with no separate ping. | For notify+wake , delivery completes only once the wake is admitted to the adapter's turn queue as well as the passive ping being sent. Missing handlers, rejected routes, and full queues are retried on later notifier ticks without expiring the subscription. Sent pings are checkpointed separately in SQLite, so a rejected wake does not repeat an already checkpointed ping. notify remains passive and never starts a turn. Admission is not a guarantee of model execution or a successful reply; normal turn gates still apply. This is not exactly-once delivery: a process crash between a send and its checkpoint can repeat the ping, and the existing claim-before-delivery cursor is not a crash-recoverable queue. A "wake" forges a synthetic inbound message to the destination gateway agent so it takes a normal turn reads the comment + result, reasons, replies instead of getting a one-line passive notification. It only fires when the notifier runs inside a live gateway process; otherwise a notify+wake subscription still delivers its passive message, while a wake -only subscription does nothing in that process. Which events wake. The ones that hand a decision back to the origin: completed , blocked , gave up , crashed , timed out , review requested a worker finished the implementation and handed off via kanban request review and block loop detected the task was routed to triage after repeated blocks . status , archived and unblocked are delivered but never wake — they are bookkeeping transitions, not decisions. When a completed or review requested event carries a summary, that handoff rides the wake turn, so the woken agent sees what the worker actually did. --chat-type dm | group | channel | thread records the originating chat's type so a woken turn resolves the operator's real session: build session key keys groups, channels, and threads differently from DMs, so an inaccurate chat type would route the wake into a separate, context-less session. The /kanban auto-subscribe and slash-command paths capture this automatically — you only set it by hand when subscribing a chat from a script or cron. Omit it to leave an existing subscription unchanged new subscriptions default to dm . Multi-profile setups: delivery is profile-owned In a one-gateway-per-profile deployment one dispatcher, separate gateway processes for writer , admin , etc. — see the multi-gateway guide https://github.com/NousResearch/hermes-agent/blob/main/docs/kanban/multi-gateway.md , dispatch and delivery have separate owners: - Dispatch stays single-owner. Exactly one gateway keeps kanban.dispatch in gateway: true and runs the dispatcher; every other gateway sets it to false . - Notification delivery is profile-owned. Every gateway — including non-dispatch ones — runs the notifier and polls only subscriptions stamped with a profile whose platform adapters it hosts. A task created from the writer profile's Telegram gets its completed / blocked message delivered by the writer gateway, even though the default gateway did the dispatching. - Route-only multiplex profiles can use the primary adapter when the subscription's persisted platform, chat, thread, scope and parent-channel anchors resolve to that exact served profile through gateway.profile routes . A connected secondary adapter remains authoritative; a partial secondary adapter registry never falls back to the primary bot. Unmatched, reassigned, disabled or ambiguous routes remain undelivered and retryable. Old rows missing required routing anchors are not guessed into a profile. Wake turns keep the destination profile's runtime scope and the authorized transport. - Legacy subscriptions created before profile stamping no notifier profile on the row are delivered only by the gateway that holds the actual dispatcher singleton lock, so two gateways never race for them. Duplicate delivery across gateways is prevented by the atomic per-event claim in the board DB. No relays, credential sharing, or extra dispatchers are needed — each profile gateway simply delivers through its own adapters. Runs — one row per attempt A task is a logical unit of work; a run is one attempt to execute it. When the dispatcher claims a ready task it creates a row in task runs and points tasks.current run id at it. When that attempt ends — completed, blocked, crashed, timed out, spawn-failed, reclaimed — the run row closes with an outcome and the task's pointer clears. A task that's been attempted three times has three task runs rows. Why two tables instead of just mutating the task: you need full attempt history for real-world postmortems "the second reviewer attempt got to approve, the third merged" , and you need a clean place to hang per-attempt metadata — which files changed, which tests ran, which findings a reviewer noted. Those are run facts, not task facts. Runs are also where structured handoff lives. When a worker completes a task via kanban complete ... it can pass: - summary tool param / --summary CLI — human handoff; goes on the run; downstream children see it in their build worker context . - metadata tool param / --metadata CLI — free-form JSON dict on the run; children see it serialized alongside the summary. - result tool param / --result CLI — short log line that goes on the task row legacy field, kept for back-compat . Downstream children read the most recent completed run's summary + metadata for each parent. Retrying workers read the prior attempts on their own task outcome, summary, error so they don't repeat a path that already failed. What a worker actually does — a tool call, from inside the agent loop:kanban complete summary="implemented token bucket, keys on user id with IP fallback, all tests pass", metadata={"changed files": "limiter.py", "tests/test limiter.py" , "tests run": 14}, result="rate limiter shipped", The same handoff is reachable from the CLI when you the human need to close out a task a worker can't — e.g. a task that was abandoned, or one you marked done manually from the dashboard: hermes kanban complete t abcd \ --result "rate limiter shipped" \ --summary "implemented token bucket, keys on user id with IP fallback, all tests pass" \ --metadata '{"changed files": "limiter.py", "tests/test limiter.py" , "tests run": 14}' Review the attempt history on a retried task:hermes kanban runs t abcd OUTCOME PROFILE ELAPSED STARTED 1 blocked worker 12s 2026-04-27 14:02 → BLOCKED: need decision on rate-limit key 2 completed worker 8m 2026-04-27 15:18 → implemented token bucket, keys on user id with IP fallback Runs are exposed on the dashboard Run History section in the drawer, one coloured row per attempt and on the REST API GET /api/plugins/kanban/tasks/:id returns a runs array . PATCH /api/plugins/kanban/tasks/:id with {status: "done", summary, metadata} forwards both to the kernel, so the dashboard's "mark done" button is CLI-equivalent. task events rows carry the run id they belong to so the UI can group them by attempt, and the completed event embeds the first-line summary in its payload capped at 400 chars so gateway notifiers can render structured handoffs without a second SQL round-trip. Bulk close caveat. hermes kanban complete a b c --summary X is refused — structured handoff is per-run, so copy-pasting the same summary to N tasks is almost always wrong. Bulk close without --summary / --metadata still works for the common "I finished a pile of admin tasks" case. Reclaimed runs from status changes. If you drag a running task off running in the dashboard back to ready , or straight to todo , or archive a task that was still running, the in-flight run closes with outcome='reclaimed' rather than being orphaned. The task runs row is always in a terminal state when tasks.current run id is NULL , and vice versa — that invariant holds across CLI, dashboard, dispatcher, and notifier. Synthetic runs for never-claimed completions. Completing or blocking a task that was never claimed e.g. a human closes a ready task from the dashboard with a summary, or a CLI user runs hermes kanban complete <ready-task --summary X would otherwise drop the handoff. Instead the kernel inserts a zero-duration run row started at == ended at carrying the summary / metadata / reason so attempt history stays complete. The completed / blocked event's run id points at that row. Live drawer refresh. When the dashboard's WebSocket event stream reports new events for the task the user is currently viewing, the drawer reloads itself via a per-task event counter threaded into its useEffect dependency list . Closing and reopening is no longer required to see a run's new row or updated outcome. Forward compatibility Two nullable columns on tasks are reserved for v2 workflow routing: workflow template id which template this task belongs to and current step key which step in that template is active . The v1 kernel ignores them for routing but lets clients write them, so a v2 release can add the routing machinery without another schema migration. Event reference Every transition appends a row to task events . Each row carries an optional run id so UIs can group events by attempt. Kinds group into three clusters so filtering is easy hermes kanban watch --kinds completed,gave up,timed out : Lifecycle what changed about the task as a logical unit : | Kind | Payload | When | |---|---|---| | created | {assignee, status, parents, tenant} | Task inserted. run id is NULL . | | promoted | — | todo → ready because all parents hit done . run id is NULL . | | claimed | {lock, expires, run id} | Dispatcher atomically claimed a ready task for spawn. | | completed | {result len, summary?} | Worker wrote --result / --summary and task hit done . summary is the first-line handoff 400-char cap ; full version lives on the run row. If complete task is called on a never-claimed task with handoff fields, a zero-duration run is synthesized so run id still points at something. | | blocked | {reason, kind, recurrences} | Worker or human flipped the task to blocked . kind is the typed block reason needs input , capability , transient , or null for a generic block ; recurrences is the unblock-loop counter. Synthesizes a zero-duration run when called on a never-claimed task with --reason . | | dependency wait | {reason, kind} | Worker blocked with kind=dependency — the task is only waiting on another task, so it routes to todo parent-gated, auto-promoted instead of blocked . No human needed. | | block loop detected | {reason, kind, recurrences, limit} | A task was unblocked and re-blocked for the same reason BLOCK RECURRENCE LIMIT times default 2 . Instead of landing in blocked again — where a cron would keep unblocking it — it routes to triage for a human decision, breaking the unblock↔re-block loop. | | unblocked | — | blocked → ready or todo if parents are still open , either manually or via /unblock . Resets the dispatcher's consecutive failures but deliberately preserves block recurrences so the loop breaker keeps its memory. run id is NULL . | | archived | — | Hidden from the default board. If the task was still running, carries the run id of the run that was reclaimed as a side effect. | Edits human-driven changes that aren't transitions : | Kind | Payload | When | |---|---|---| | assigned | {assignee} | Assignee changed including unassignment . | | edited | {fields} | Title or body updated. | | reprioritized | {priority} | Priority changed. | | status | {status} | Dashboard drag-drop wrote a status directly e.g. todo → ready . Carries the run id of the run that was reclaimed when dragging off running ; otherwise run id is NULL. | Worker telemetry about the execution process, not the logical task : | Kind | Payload | When | |---|---|---| | spawned | {pid} | Dispatcher successfully started a worker process. | | heartbeat | {note?} | Worker called hermes kanban heartbeat $TASK to signal liveness during long operations. | | reclaimed | {stale lock} | Claim TTL expired without a completion; task goes back to ready . | | crashed | {pid, claimer} | Worker PID no longer alive but TTL hadn't expired yet. | | timed out | {pid, elapsed seconds, limit seconds, sigkill} | max runtime seconds exceeded; dispatcher SIGTERM'd then SIGKILL'd after 5 s grace and re-queued. | | stale | {elapsed seconds, last heartbeat at, heartbeat age seconds, timeout seconds, pid, terminated} | Task ran longer than kanban.dispatch stale timeout seconds default 4 h AND no kanban heartbeat arrived in the last hour. Dispatcher SIGTERM'd the host-local worker if any , reset the task to ready for re-dispatch. Does NOT tick the failure counter stale is dispatcher-side absence detection, not a worker fault . Workers running long operations should call kanban heartbeat at least once an hour to avoid this. | | reconciled | {reason, claim lock, claim expires, worker pid} | Orphaned-card reconciliation: the card was running with broken claim bookkeeping claim lock or claim expires NULL — crash mid-claim, manual SQL, DB restore and no live worker, so none of the TTL/crash/stale paths could ever recover it. The dispatcher requeued it to ready with an explanatory comment. Gated by kanban.reconcile orphans in config.yaml default true . | | respawn guarded | {reason} | Dispatcher refused to re-spawn this ready task this tick. Reasons: blocker auth last failure was a quota/auth/429 error — wait for the rate window to reset , recent success a completed run happened in the last hour — wait for review before re-running , active pr a GitHub PR URL appears in a recent comment — a prior worker already opened a PR . The task stays in ready ; the next tick gets another chance to spawn. If the underlying condition persists, the normal consecutive failures circuit breaker will auto-block via gave up after failure limit failures. | | spawn failed | {error, failures} | One spawn attempt failed missing PATH, workspace unmountable, … . Counter increments; task returns to ready for retry. | | protocol violation | {pid, claimer, exit code, protocol violation} | Worker exited successfully while the task was still running , usually because it answered without calling kanban complete or kanban block . Emitted on every violation the payload's protocol violation: true marker is copied into the run metadata and feeds the violation-only retry budget . Below the budget — up to PROTOCOL VIOLATION FAILURE LIMIT default 3 consecutive violations, per-task max retries overriding — the task simply returns to ready for another attempt; when the streak reaches the bound the dispatcher also emits gave up and auto-blocks. | | gave up | {failures, effective limit, limit source, error} | Circuit breaker fired after N consecutive non-successful attempts. Task auto-blocks with the last error. The effective limit resolves as task max retries , then dispatcher failure limit / kanban.failure limit , then the built-in default. | hermes kanban tail <id shows these for a single task. hermes kanban watch streams them board-wide. Out of scope Kanban is deliberately single-host. ~/.hermes/kanban.db is a local SQLite file and the dispatcher spawns workers on the same machine. Running a shared board across two hosts is not supported — there's no coordination primitive for "worker X on host A, worker Y on host B," and the crash-detection path assumes PIDs are host-local. If you need multi-host, run an independent board per host and use delegate task / a message queue to bridge them. Design spec The complete design — architecture, concurrency correctness, comparison with other systems, implementation plan, risks, open questions — lives in docs/hermes-kanban-v1-spec.pdf . Read that before filing any behavior-change PR.