feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
"""Kanban dashboard plugin — backend API routes.
|
|
|
|
|
|
|
|
|
|
Mounted at /api/plugins/kanban/ by the dashboard plugin system.
|
|
|
|
|
|
|
|
|
|
This layer is intentionally thin: every handler is a small wrapper around
|
|
|
|
|
``hermes_cli.kanban_db`` or a direct SQL query. Writes use the same code
|
|
|
|
|
paths the CLI and gateway ``/kanban`` command use, so the three surfaces
|
|
|
|
|
cannot drift.
|
|
|
|
|
|
|
|
|
|
Live updates arrive via the ``/events`` WebSocket, which tails the
|
|
|
|
|
append-only ``task_events`` table on a short poll interval (WAL mode lets
|
|
|
|
|
reads run alongside the dispatcher's IMMEDIATE write transactions).
|
|
|
|
|
|
|
|
|
|
Security note
|
|
|
|
|
-------------
|
2026-05-10 07:03:41 -07:00
|
|
|
Plugin HTTP routes go through the dashboard's session-token auth middleware
|
|
|
|
|
(``web_server.auth_middleware``) just like core API routes — every
|
|
|
|
|
``/api/plugins/...`` request must present the session bearer token (or the
|
|
|
|
|
session cookie set when you load the dashboard HTML). The token is the
|
|
|
|
|
random per-process ``_SESSION_TOKEN`` printed at startup; the dashboard's
|
|
|
|
|
own pages inject it via ``window.__HERMES_SESSION_TOKEN__`` so logged-in
|
|
|
|
|
browsers don't have to handle it manually.
|
|
|
|
|
|
|
|
|
|
For the ``/events`` WebSocket we still require the session token as a
|
|
|
|
|
``?token=`` query parameter (browsers cannot set the ``Authorization``
|
|
|
|
|
header on an upgrade request), matching the established pattern used by
|
|
|
|
|
the in-browser PTY bridge in ``hermes_cli/web_server.py``.
|
|
|
|
|
|
|
|
|
|
This means ``hermes dashboard --host 0.0.0.0`` is safe to run on a LAN:
|
|
|
|
|
plugin routes are no longer an unauthenticated exception. The auth still
|
|
|
|
|
isn't multi-user — anyone who can read the printed URL+token gets full
|
|
|
|
|
dashboard access — but they can't ride along just because they can reach
|
|
|
|
|
the port.
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
"""
|
|
|
|
|
|
|
|
|
|
from __future__ import annotations
|
|
|
|
|
|
|
|
|
|
import asyncio
|
|
|
|
|
import json
|
|
|
|
|
import logging
|
feat(kanban): add `specify` — auxiliary LLM fleshes out triage tasks (#21435)
* feat(kanban): add `specify` — auxiliary LLM fleshes out triage tasks
The Triage column shipped with a placeholder 'a specifier will flesh
out the spec', but the specifier itself was never built. This wires
it up as a dedicated CLI verb.
`hermes kanban specify <id>` calls the auxiliary LLM (configured under
`auxiliary.triage_specifier`) to expand a rough one-liner into a
concrete spec — tightened title plus a body with Goal / Approach /
Acceptance criteria / Out-of-scope sections — then atomically flips
`status: triage -> todo` and recomputes ready so parent-free tasks
go straight to the dispatcher on the same tick.
Surface:
hermes kanban specify <task_id> # single task
hermes kanban specify --all [--tenant T] # sweep triage column
hermes kanban specify ... --author NAME # audit-comment author
hermes kanban specify ... --json # one JSON line per task
Design choices:
- Parent gating is preserved. specify_triage_task flips to 'todo',
then recompute_ready promotes to 'ready' only when parents are
done — same rule as a normal parent-gated todo.
- No daemon, no background watcher. Every invocation is explicit —
keeps cost predictable and doesn't fight the dispatcher loop.
- Response parse is lenient: strict JSON preferred, markdown-fence
tolerated, raw-body fallback on malformed JSON so the LLM can't
strand a task in triage.
- All failure modes (no aux client, API error, task moved out of
triage mid-call) return SpecifyOutcome(ok=False, reason=...) so
--all continues past individual failures.
Changes:
hermes_cli/kanban_db.py + specify_triage_task()
hermes_cli/kanban_specify.py NEW (~220 LOC — prompt, parse, call)
hermes_cli/kanban.py + specify subcommand + _cmd_specify
hermes_cli/config.py + auxiliary.triage_specifier task slot
website/docs/user-guide/features/kanban.md specify + config notes
website/docs/reference/cli-commands.md CLI reference entry
tests/hermes_cli/test_kanban_specify_db.py NEW (10 tests)
tests/hermes_cli/test_kanban_specify.py NEW (20 tests)
Validation: 30/30 targeted tests pass. E2E: triage task -> specify ->
ends in 'ready' with events [created, specified, promoted] and the
audit comment recorded under the configured author.
* feat(kanban): wire specifier into dashboard and gateway slash
Follow-ups to the initial PR #21435 — closes the two gaps I'd left as
post-merge: dashboard button and first-class gateway surface.
Dashboard (plugins/kanban/dashboard/)
- POST /tasks/:id/specify NEW endpoint. Thin wrapper around
kanban_specify.specify_task(). Returns the CLI outcome shape
({ok, task_id, reason, new_title}); ok=false with a human reason
is a 200, not a 4xx, so the UI can render it inline without
treating 'no aux client configured' as a crash.
- Runs sync in FastAPI's threadpool because the LLM call can take
tens of seconds on reasoning models.
- Pins HERMES_KANBAN_BOARD around the specify call so the module's
argless kb.connect() lands on the right board.
- dist/index.js: doSpecify callback threaded through the drawer →
TaskDetail → StatusActions prop chain. ✨ Specify button appears
ONLY when task.status === 'triage' (elsewhere the backend would
reject anyway — hide the button to keep the action row clean).
Busy state (Specifying…) + inline success/error banner under the
button using the response.reason text.
- dist/style.css: tiny hermes-kanban-msg-ok / -err classes using
existing --color vars so themes reskin cleanly.
Gateway slash (/kanban specify)
- Already works via the existing run_slash → build_parser →
kanban_command pipeline. No code change needed — slash commands
inherit the argparse tree automatically. Added coverage:
test_run_slash_specify_end_to_end (create --triage, specify, verify
promotion + retitle) and test_run_slash_specify_help_is_reachable.
Tests
- tests/plugins/test_kanban_dashboard_plugin.py: 3 new tests for the
REST endpoint — happy path, non-triage rejection as ok=false 200,
missing aux client as ok=false 200.
- tests/hermes_cli/test_kanban_cli.py: 2 new slash-surface tests.
Docs
- website/docs/user-guide/features/kanban.md: dashboard action row
description mentions ✨ Specify + all three surfaces. REST table
gains /tasks/:id/specify. Slash examples include /kanban specify.
Validation: 340/340 targeted tests pass. E2E via TestClient: create a
triage task over REST → POST /specify with mocked aux client → task
moves to 'ready' column on /board with new title and body applied.
2026-05-07 13:04:41 -07:00
|
|
|
import os
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
import sqlite3
|
|
|
|
|
import time
|
|
|
|
|
from dataclasses import asdict
|
feat(kanban): file attachments on tasks (#35395)
Tasks can now carry file attachments (PDFs, images, source docs) that
workers read directly — closes the gap where source material had to be
pasted as a path into the task body.
- kanban_db: task_attachments table (additive), Attachment dataclass,
add/list/get/delete accessors, attachments_root/task_attachments_dir
path helpers (per-board, HERMES_KANBAN_ATTACHMENTS_ROOT override)
- build_worker_context: surfaces each attachment's absolute path so the
worker (full file/terminal tool access) reads it via read_file/pdftotext
- dashboard API: POST/GET/DELETE attachment routes (multipart upload,
25MB cap, traversal-safe filenames, root-containment check on download)
- dashboard UI: Attachments section in the task drawer — upload button,
list with download, per-row remove
- docs + tests (13 cases: DB accessors, REST round-trip, traversal
rejection, collision suffixing, worker-context surfacing)
Closes #35338
2026-05-30 07:41:04 -07:00
|
|
|
from pathlib import Path
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
from typing import Any, Optional
|
|
|
|
|
|
feat(kanban): file attachments on tasks (#35395)
Tasks can now carry file attachments (PDFs, images, source docs) that
workers read directly — closes the gap where source material had to be
pasted as a path into the task body.
- kanban_db: task_attachments table (additive), Attachment dataclass,
add/list/get/delete accessors, attachments_root/task_attachments_dir
path helpers (per-board, HERMES_KANBAN_ATTACHMENTS_ROOT override)
- build_worker_context: surfaces each attachment's absolute path so the
worker (full file/terminal tool access) reads it via read_file/pdftotext
- dashboard API: POST/GET/DELETE attachment routes (multipart upload,
25MB cap, traversal-safe filenames, root-containment check on download)
- dashboard UI: Attachments section in the task drawer — upload button,
list with download, per-row remove
- docs + tests (13 cases: DB accessors, REST round-trip, traversal
rejection, collision suffixing, worker-context surfacing)
Closes #35338
2026-05-30 07:41:04 -07:00
|
|
|
from fastapi import APIRouter, File, Form, HTTPException, Query, UploadFile, WebSocket, WebSocketDisconnect, status as http_status
|
|
|
|
|
from fastapi.responses import FileResponse
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
from pydantic import BaseModel, Field
|
|
|
|
|
|
|
|
|
|
from hermes_cli import kanban_db
|
2026-05-18 20:46:55 -07:00
|
|
|
from hermes_cli import kanban_diagnostics as kd
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
|
|
|
|
|
log = logging.getLogger(__name__)
|
|
|
|
|
|
|
|
|
|
router = APIRouter()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Auth helper — WebSocket only (HTTP routes live behind the dashboard's
|
|
|
|
|
# existing plugin-bypass; this is documented above).
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
fix(dashboard): sanction plugin WS/upload auth via SDK helpers (gated mode)
Dashboard plugins (kanban, hermes-achievements) read
window.__HERMES_SESSION_TOKEN__ directly and hand-assembled WebSocket
URLs with ?token=. That works in loopback/--insecure mode but is
rejected on OAuth-gated deployments, where the session token is absent
and _ws_auth_ok only accepts single-use ?ticket= auth. The result was
401s on plugin REST calls and 1008/403 on the kanban live-events WS
whenever the dashboard ran behind OAuth (e.g. hosted Fly agents).
Make the plugin SDK the single sanctioned auth surface:
- web/src/lib/api.ts: add authedFetch() (raw Response for FormData
uploads / blob downloads, token-or-cookie auth, no throw / no 401
redirect) and buildWsUrl() (assembles a ws(s):// URL with the correct
auth param for the active mode — fresh single-use ticket in gated
mode, token in loopback).
- web/src/plugins/registry.ts: expose authedFetch, buildWsUrl,
buildWsAuthParam, and sdkVersion on window.__HERMES_PLUGIN_SDK__;
add SDK_CONTRACT_VERSION.
- web/src/plugins/sdk.d.ts: hand-authored typed contract for the
plugin SDK + registry globals (single source of truth for the
Window declarations).
- plugins/kanban + hermes-achievements dist bundles: stop reading the
session token directly; route uploads/downloads through
SDK.authedFetch and the live-events WS through SDK.buildWsUrl.
- plugins/kanban plugin_api.py: _ws_upgrade_authorized() delegates the
/events WS upgrade to the canonical web_server._ws_auth_ok gate, so
it transparently accepts loopback token / gated ticket / internal
credential and can never drift from core auth again.
- tests: guard test asserting no plugin dist reads
__HERMES_SESSION_TOKEN__ directly; kanban gated-ticket WS test.
Verified live on a gated staging Fly agent: kanban /events upgrades
101 with a minted ticket (ticket_len=43, ws_auth_ok=True) where the
old code got 403.
2026-06-04 09:17:59 +10:00
|
|
|
def _ws_upgrade_authorized(ws: "WebSocket") -> bool:
|
|
|
|
|
"""Authorize a WebSocket upgrade by delegating to the dashboard's canonical
|
|
|
|
|
WS auth gate (``hermes_cli.web_server._ws_auth_ok``).
|
|
|
|
|
|
|
|
|
|
Delegating (rather than re-implementing a ``_SESSION_TOKEN``-only check)
|
|
|
|
|
means this endpoint transparently accepts whatever the core gate accepts
|
|
|
|
|
in each mode:
|
|
|
|
|
|
|
|
|
|
* loopback / ``--insecure``: legacy ``?token=<_SESSION_TOKEN>``
|
|
|
|
|
* gated OAuth: single-use ``?ticket=`` (the browser SDK's
|
|
|
|
|
``buildWsUrl`` mints one per connect)
|
|
|
|
|
* server-internal: the process-lifetime ``?internal=`` credential
|
|
|
|
|
|
|
|
|
|
The previous bespoke check only understood ``_SESSION_TOKEN``, so the
|
|
|
|
|
kanban live-events WS was rejected on every OAuth-gated deployment even
|
|
|
|
|
though the rest of the dashboard worked. Routing through the shared gate
|
|
|
|
|
also means this can never drift from core auth again.
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
|
|
|
|
|
Imported lazily so the plugin still loads in test contexts where the
|
fix(dashboard): sanction plugin WS/upload auth via SDK helpers (gated mode)
Dashboard plugins (kanban, hermes-achievements) read
window.__HERMES_SESSION_TOKEN__ directly and hand-assembled WebSocket
URLs with ?token=. That works in loopback/--insecure mode but is
rejected on OAuth-gated deployments, where the session token is absent
and _ws_auth_ok only accepts single-use ?ticket= auth. The result was
401s on plugin REST calls and 1008/403 on the kanban live-events WS
whenever the dashboard ran behind OAuth (e.g. hosted Fly agents).
Make the plugin SDK the single sanctioned auth surface:
- web/src/lib/api.ts: add authedFetch() (raw Response for FormData
uploads / blob downloads, token-or-cookie auth, no throw / no 401
redirect) and buildWsUrl() (assembles a ws(s):// URL with the correct
auth param for the active mode — fresh single-use ticket in gated
mode, token in loopback).
- web/src/plugins/registry.ts: expose authedFetch, buildWsUrl,
buildWsAuthParam, and sdkVersion on window.__HERMES_PLUGIN_SDK__;
add SDK_CONTRACT_VERSION.
- web/src/plugins/sdk.d.ts: hand-authored typed contract for the
plugin SDK + registry globals (single source of truth for the
Window declarations).
- plugins/kanban + hermes-achievements dist bundles: stop reading the
session token directly; route uploads/downloads through
SDK.authedFetch and the live-events WS through SDK.buildWsUrl.
- plugins/kanban plugin_api.py: _ws_upgrade_authorized() delegates the
/events WS upgrade to the canonical web_server._ws_auth_ok gate, so
it transparently accepts loopback token / gated ticket / internal
credential and can never drift from core auth again.
- tests: guard test asserting no plugin dist reads
__HERMES_SESSION_TOKEN__ directly; kanban gated-ticket WS test.
Verified live on a gated staging Fly agent: kanban /events upgrades
101 with a minted ticket (ticket_len=43, ws_auth_ok=True) where the
old code got 403.
2026-06-04 09:17:59 +10:00
|
|
|
dashboard ``web_server`` module isn't importable (e.g. the bare-FastAPI
|
|
|
|
|
test harness); there we accept so the tail loop stays testable, matching
|
|
|
|
|
the prior behaviour.
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
"""
|
|
|
|
|
try:
|
|
|
|
|
from hermes_cli import web_server as _ws
|
|
|
|
|
except Exception:
|
|
|
|
|
# No dashboard context (tests). Accept so the tail loop is still
|
|
|
|
|
# testable; in production the dashboard module always imports
|
|
|
|
|
# cleanly because it's the caller.
|
|
|
|
|
return True
|
fix(dashboard): sanction plugin WS/upload auth via SDK helpers (gated mode)
Dashboard plugins (kanban, hermes-achievements) read
window.__HERMES_SESSION_TOKEN__ directly and hand-assembled WebSocket
URLs with ?token=. That works in loopback/--insecure mode but is
rejected on OAuth-gated deployments, where the session token is absent
and _ws_auth_ok only accepts single-use ?ticket= auth. The result was
401s on plugin REST calls and 1008/403 on the kanban live-events WS
whenever the dashboard ran behind OAuth (e.g. hosted Fly agents).
Make the plugin SDK the single sanctioned auth surface:
- web/src/lib/api.ts: add authedFetch() (raw Response for FormData
uploads / blob downloads, token-or-cookie auth, no throw / no 401
redirect) and buildWsUrl() (assembles a ws(s):// URL with the correct
auth param for the active mode — fresh single-use ticket in gated
mode, token in loopback).
- web/src/plugins/registry.ts: expose authedFetch, buildWsUrl,
buildWsAuthParam, and sdkVersion on window.__HERMES_PLUGIN_SDK__;
add SDK_CONTRACT_VERSION.
- web/src/plugins/sdk.d.ts: hand-authored typed contract for the
plugin SDK + registry globals (single source of truth for the
Window declarations).
- plugins/kanban + hermes-achievements dist bundles: stop reading the
session token directly; route uploads/downloads through
SDK.authedFetch and the live-events WS through SDK.buildWsUrl.
- plugins/kanban plugin_api.py: _ws_upgrade_authorized() delegates the
/events WS upgrade to the canonical web_server._ws_auth_ok gate, so
it transparently accepts loopback token / gated ticket / internal
credential and can never drift from core auth again.
- tests: guard test asserting no plugin dist reads
__HERMES_SESSION_TOKEN__ directly; kanban gated-ticket WS test.
Verified live on a gated staging Fly agent: kanban /events upgrades
101 with a minted ticket (ticket_len=43, ws_auth_ok=True) where the
old code got 403.
2026-06-04 09:17:59 +10:00
|
|
|
return bool(_ws._ws_auth_ok(ws))
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
|
|
|
|
|
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
def _resolve_board(board: Optional[str]) -> Optional[str]:
|
|
|
|
|
"""Validate and normalise a board slug from a query param.
|
|
|
|
|
|
|
|
|
|
Raises :class:`HTTPException` 400 on malformed slugs so the browser
|
|
|
|
|
sees a clean error instead of a 500. Returns the normalised slug,
|
|
|
|
|
or ``None`` when the caller omitted the param (which then falls
|
|
|
|
|
through to the active board inside ``kb.connect()``).
|
|
|
|
|
"""
|
|
|
|
|
if board is None or board == "":
|
|
|
|
|
return None
|
|
|
|
|
try:
|
|
|
|
|
normed = kanban_db._normalize_board_slug(board)
|
|
|
|
|
except ValueError as exc:
|
|
|
|
|
raise HTTPException(status_code=400, detail=str(exc))
|
|
|
|
|
if normed and normed != kanban_db.DEFAULT_BOARD and not kanban_db.board_exists(normed):
|
|
|
|
|
raise HTTPException(
|
|
|
|
|
status_code=404,
|
|
|
|
|
detail=f"board {normed!r} does not exist",
|
|
|
|
|
)
|
|
|
|
|
return normed
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def _conn(board: Optional[str] = None):
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
"""Open a kanban_db connection, creating the schema on first use.
|
|
|
|
|
|
|
|
|
|
Every handler that mutates the DB goes through this so the plugin
|
|
|
|
|
self-heals on a fresh install (no user-visible "no such table"
|
|
|
|
|
error if somebody hits POST /tasks before GET /board).
|
|
|
|
|
``init_db`` is idempotent.
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
|
|
|
|
|
``board`` is the query-param slug (already normalised by
|
|
|
|
|
:func:`_resolve_board`). When ``None`` the active board is used
|
|
|
|
|
via the resolution chain (env var → ``current`` file → ``default``).
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
"""
|
|
|
|
|
try:
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
kanban_db.init_db(board=board)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
except Exception as exc:
|
|
|
|
|
log.warning("kanban init_db failed: %s", exc)
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
return kanban_db.connect(board=board)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Serialization helpers
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
# Columns shown by the dashboard, in left-to-right order. "archived" is
|
|
|
|
|
# available via a filter toggle rather than a visible column.
|
2026-05-18 20:25:40 -07:00
|
|
|
#
|
|
|
|
|
# Keep this in sync with kanban_db.VALID_STATUSES. In particular,
|
|
|
|
|
# ``scheduled`` is a first-class waiting column used for time-based follow-ups;
|
|
|
|
|
# if it is omitted here, the board-level fallback below mis-buckets scheduled
|
|
|
|
|
# tasks into ``todo`` and makes the dashboard look like the Scheduled column
|
|
|
|
|
# disappeared.
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
BOARD_COLUMNS: list[str] = [
|
2026-05-18 21:54:56 -07:00
|
|
|
"triage", "todo", "scheduled", "ready", "running", "blocked", "review", "done",
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
]
|
|
|
|
|
|
|
|
|
|
|
feat(kanban): surface task_runs.summary on dashboard cards + ``kanban show``
The kanban-worker skill (built into the gateway dispatcher's spawn
prompt) instructs every worker to hand off via
``kanban_complete(summary=..., metadata=...)``. That writes the summary
onto the closing ``task_runs`` row, NOT onto ``tasks.result`` — the
latter is left NULL unless the caller passes ``result=`` explicitly.
Result: a glance at the dashboard or ``hermes kanban show <id>`` shows
a blank "Result:" section even when the worker did real work, which
on 2026-05-05 caused a Mac false-alarm ("Hermes did nothing") on a
task that had a 10-line completion summary on its run.
This patch surfaces the latest non-null run summary as
``latest_summary`` so the worker's actual handoff lands in front of
operators.
* New helpers ``kanban_db.latest_summary(conn, task_id)`` and
``kanban_db.latest_summaries(conn, task_ids)``. The batch variant
uses a single window-function SELECT so the dashboard board endpoint
doesn't pay an N+1 cost on multi-hundred-task boards.
* CLI ``hermes kanban show <id>`` prints a "Latest summary:" block
when ``tasks.result`` is empty but a run has produced a summary
(the existing "Result:" section still wins when populated, so the
back-compat path for hand-edited results is untouched). JSON output
gains a top-level ``latest_summary`` field.
* Dashboard ``/board`` and ``/tasks/{id}`` now include a
``latest_summary`` field on every task. Cards on /board carry a
200-character preview (cheap to render, plenty for "what did this
worker do?" at a glance); the drawer/detail endpoint returns the
full summary.
* Five new tests cover: empty-runs case, post-complete surface,
newest-of-multiple selection, empty-string skip, batch with
missing tasks + empty input.
Smoke-tested locally against the live profile DB on the three
acceptance-criterion targets (t_f08fef91 cron-hygiene-audit,
t_007b7f1c EMA-analysis, t_05746fa4 self-assessment) — all three now
return their populated summaries via both ``latest_summary`` and
``latest_summaries``.
Test plan: 255/255 kanban tests pass + 91/91 dashboard plugin tests
pass. No regression on tasks where ``tasks.result`` is explicitly
populated (the existing "Result:" branch is preserved).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-05 14:14:25 +00:00
|
|
|
_CARD_SUMMARY_PREVIEW_CHARS = 200
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def _task_dict(
|
|
|
|
|
task: kanban_db.Task,
|
|
|
|
|
*,
|
|
|
|
|
latest_summary: Optional[str] = None,
|
|
|
|
|
) -> dict[str, Any]:
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
d = asdict(task)
|
|
|
|
|
# Add derived age metrics so the UI can colour stale cards without
|
|
|
|
|
# computing deltas client-side.
|
2026-05-06 18:18:56 -05:00
|
|
|
try:
|
|
|
|
|
d["age"] = kanban_db.task_age(task)
|
|
|
|
|
except Exception:
|
|
|
|
|
d["age"] = {"created_age_seconds": None, "started_age_seconds": None, "time_to_complete_seconds": None}
|
feat(kanban): surface task_runs.summary on dashboard cards + ``kanban show``
The kanban-worker skill (built into the gateway dispatcher's spawn
prompt) instructs every worker to hand off via
``kanban_complete(summary=..., metadata=...)``. That writes the summary
onto the closing ``task_runs`` row, NOT onto ``tasks.result`` — the
latter is left NULL unless the caller passes ``result=`` explicitly.
Result: a glance at the dashboard or ``hermes kanban show <id>`` shows
a blank "Result:" section even when the worker did real work, which
on 2026-05-05 caused a Mac false-alarm ("Hermes did nothing") on a
task that had a 10-line completion summary on its run.
This patch surfaces the latest non-null run summary as
``latest_summary`` so the worker's actual handoff lands in front of
operators.
* New helpers ``kanban_db.latest_summary(conn, task_id)`` and
``kanban_db.latest_summaries(conn, task_ids)``. The batch variant
uses a single window-function SELECT so the dashboard board endpoint
doesn't pay an N+1 cost on multi-hundred-task boards.
* CLI ``hermes kanban show <id>`` prints a "Latest summary:" block
when ``tasks.result`` is empty but a run has produced a summary
(the existing "Result:" section still wins when populated, so the
back-compat path for hand-edited results is untouched). JSON output
gains a top-level ``latest_summary`` field.
* Dashboard ``/board`` and ``/tasks/{id}`` now include a
``latest_summary`` field on every task. Cards on /board carry a
200-character preview (cheap to render, plenty for "what did this
worker do?" at a glance); the drawer/detail endpoint returns the
full summary.
* Five new tests cover: empty-runs case, post-complete surface,
newest-of-multiple selection, empty-string skip, batch with
missing tasks + empty input.
Smoke-tested locally against the live profile DB on the three
acceptance-criterion targets (t_f08fef91 cron-hygiene-audit,
t_007b7f1c EMA-analysis, t_05746fa4 self-assessment) — all three now
return their populated summaries via both ``latest_summary`` and
``latest_summaries``.
Test plan: 255/255 kanban tests pass + 91/91 dashboard plugin tests
pass. No regression on tasks where ``tasks.result`` is explicitly
populated (the existing "Result:" branch is preserved).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-05 14:14:25 +00:00
|
|
|
# Surface the latest non-null run summary so dashboards don't show
|
|
|
|
|
# blank cards/drawers for tasks where the worker handed off via
|
|
|
|
|
# ``task_runs.summary`` (the kanban-worker pattern) instead of
|
|
|
|
|
# ``tasks.result``. ``None`` when no run has produced a summary yet.
|
|
|
|
|
d["latest_summary"] = latest_summary
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
# Keep body short on list endpoints; full body comes from /tasks/:id.
|
|
|
|
|
return d
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def _event_dict(event: kanban_db.Event) -> dict[str, Any]:
|
|
|
|
|
return {
|
|
|
|
|
"id": event.id,
|
|
|
|
|
"task_id": event.task_id,
|
|
|
|
|
"kind": event.kind,
|
|
|
|
|
"payload": event.payload,
|
|
|
|
|
"created_at": event.created_at,
|
|
|
|
|
"run_id": event.run_id,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def _comment_dict(c: kanban_db.Comment) -> dict[str, Any]:
|
|
|
|
|
return {
|
|
|
|
|
"id": c.id,
|
|
|
|
|
"task_id": c.task_id,
|
|
|
|
|
"author": c.author,
|
|
|
|
|
"body": c.body,
|
|
|
|
|
"created_at": c.created_at,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
feat(kanban): file attachments on tasks (#35395)
Tasks can now carry file attachments (PDFs, images, source docs) that
workers read directly — closes the gap where source material had to be
pasted as a path into the task body.
- kanban_db: task_attachments table (additive), Attachment dataclass,
add/list/get/delete accessors, attachments_root/task_attachments_dir
path helpers (per-board, HERMES_KANBAN_ATTACHMENTS_ROOT override)
- build_worker_context: surfaces each attachment's absolute path so the
worker (full file/terminal tool access) reads it via read_file/pdftotext
- dashboard API: POST/GET/DELETE attachment routes (multipart upload,
25MB cap, traversal-safe filenames, root-containment check on download)
- dashboard UI: Attachments section in the task drawer — upload button,
list with download, per-row remove
- docs + tests (13 cases: DB accessors, REST round-trip, traversal
rejection, collision suffixing, worker-context surfacing)
Closes #35338
2026-05-30 07:41:04 -07:00
|
|
|
def _attachment_dict(a: kanban_db.Attachment) -> dict[str, Any]:
|
|
|
|
|
"""Serialise an Attachment for the drawer. ``stored_path`` is the
|
|
|
|
|
absolute on-disk path workers read; the UI uses ``id`` for download."""
|
|
|
|
|
return {
|
|
|
|
|
"id": a.id,
|
|
|
|
|
"task_id": a.task_id,
|
|
|
|
|
"filename": a.filename,
|
|
|
|
|
"content_type": a.content_type,
|
|
|
|
|
"size": a.size,
|
|
|
|
|
"uploaded_by": a.uploaded_by,
|
|
|
|
|
"stored_path": a.stored_path,
|
|
|
|
|
"created_at": a.created_at,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
def _run_dict(r: kanban_db.Run) -> dict[str, Any]:
|
|
|
|
|
"""Serialise a Run for the drawer's Run history section."""
|
|
|
|
|
return {
|
|
|
|
|
"id": r.id,
|
|
|
|
|
"task_id": r.task_id,
|
|
|
|
|
"profile": r.profile,
|
|
|
|
|
"step_key": r.step_key,
|
|
|
|
|
"status": r.status,
|
|
|
|
|
"claim_lock": r.claim_lock,
|
|
|
|
|
"claim_expires": r.claim_expires,
|
|
|
|
|
"worker_pid": r.worker_pid,
|
|
|
|
|
"max_runtime_seconds": r.max_runtime_seconds,
|
|
|
|
|
"last_heartbeat_at": r.last_heartbeat_at,
|
|
|
|
|
"started_at": r.started_at,
|
|
|
|
|
"ended_at": r.ended_at,
|
|
|
|
|
"outcome": r.outcome,
|
|
|
|
|
"summary": r.summary,
|
|
|
|
|
"metadata": r.metadata,
|
|
|
|
|
"error": r.error,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
feat(kanban): hallucination gate + recovery UX for worker-created-card claims (#20232)
Workers completing a kanban task can now claim the ids of cards they
created via an optional ``created_cards`` field on ``kanban_complete``.
The kernel verifies each id exists and was created by the completing
worker's profile; any phantom id blocks the completion with a
``HallucinatedCardsError`` and records a
``completion_blocked_hallucination`` event on the task so the rejected
attempt is auditable. Successful completions also get a non-blocking
prose-scan pass over their ``summary`` + ``result`` that emits a
``suspected_hallucinated_references`` event for any ``t_<hex>``
reference that doesn't resolve.
Closes #20017.
Recovery UX (kernel + CLI + dashboard)
--------------------------------------
A structural gate alone isn't enough — operators also need to see and
act on stuck workers, especially when a profile's model is the root
cause. This PR ships the full loop:
* ``kanban_db.reclaim_task(task_id)`` — operator-driven reclaim that
releases an active worker claim immediately (unlike
``release_stale_claims`` which only acts after claim_expires has
passed). Emits a ``reclaimed`` event with ``manual: True`` payload.
* ``kanban_db.reassign_task(task_id, profile, reclaim_first=...)`` —
switch a task to a different profile, optionally reclaiming a stuck
running worker in the same call.
* ``hermes kanban reclaim <id> [--reason ...]`` and
``hermes kanban reassign <id> <profile> [--reclaim] [--reason ...]``
CLI subcommands wired through to the same helpers.
* ``POST /api/plugins/kanban/tasks/{id}/reclaim`` and
``POST /api/plugins/kanban/tasks/{id}/reassign`` endpoints on the
dashboard plugin.
Dashboard surfacing
-------------------
* ⚠ **warning badge** on cards with active hallucination events.
* **attention strip** at the top of the board listing all flagged
tasks; dismissible per session.
* **events callout** in the task drawer — hallucination events render
with a red left border, amber icon, and phantom ids as styled chips.
* **recovery section** in the task drawer with three actions: Reclaim,
Reassign (with profile picker + reclaim-first checkbox), and a
copy-to-clipboard hint for ``hermes -p <profile> model`` since
profile config lives on disk and can't be edited from the browser.
Auto-opens when the task has warnings, collapsed otherwise.
Keyed by task id so state doesn't leak between drawers.
Active-vs-stale rule: warnings clear when a clean ``completed`` or
``edited`` event supersedes the hallucination, so recovery is never
permanently stigmatising — the audit events persist for debugging but
the badge goes away once the worker succeeds.
Skill updates
-------------
* ``skills/devops/kanban-worker/SKILL.md`` documents the
``created_cards`` contract with good/bad examples.
* ``skills/devops/kanban-orchestrator/SKILL.md`` gains a "Recovering
stuck workers" section with the three actions and when to use each.
Tests
-----
* Kernel gate: verified-cards manifest, phantom rejection + audit
event, cross-worker rejection, prose scan positive + negative.
* Recovery helpers: reclaim on running task, reclaim on non-running
returns False, reassign refuses running without reclaim_first,
reassign with reclaim_first succeeds on running.
* API endpoints: warnings field present on /board and /tasks/:id,
warnings cleared after clean completion, reclaim 200 + 409 paths,
reassign 200 + 409 + reclaim_first paths.
* CLI smoke: reclaim + reassign subcommands.
Live-verified end-to-end on a dashboard with seeded scenarios:
attention strip renders, badges land on the right cards, drawer
callout shows phantom chips, Reclaim on a running task flips status to
ready + emits manual reclaimed event + refreshes the drawer,
Reassign swaps the assignee and triggers board refresh.
359/359 kanban-suite tests pass
(test_kanban_{db,cli,boards,core_functionality} + dashboard + tools).
2026-05-05 08:06:55 -07:00
|
|
|
# Hallucination-warning event kinds — see complete_task() in kanban_db.py.
|
|
|
|
|
# completion_blocked_hallucination: kernel rejected created_cards with
|
|
|
|
|
# phantom ids; task stays in prior state.
|
|
|
|
|
# suspected_hallucinated_references: prose scan found t_<hex> in summary
|
|
|
|
|
# that doesn't resolve; completion succeeded, advisory only.
|
|
|
|
|
_WARNING_EVENT_KINDS = (
|
|
|
|
|
"completion_blocked_hallucination",
|
|
|
|
|
"suspected_hallucinated_references",
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
|
feat(kanban): generic diagnostics engine for task distress signals (#20332)
* feat(kanban): generic diagnostics engine for task distress signals
Replaces the hallucination-specific ``warnings`` / ``RecoverySection``
surface (shipped in PR #20232) with a reusable diagnostic-rule engine
that covers five distress kinds in v1 and can be extended without
touching UI code. The "something's wrong with this task" signal is
no longer limited to phantom card ids.
Closes the follow-up from #20232 discussion.
New module
----------
``hermes_cli/kanban_diagnostics.py`` — stateless, no-side-effect rule
engine. Each rule is a pure function of
``(task, events, runs, now, config) -> list[Diagnostic]``. Registry
is a simple list; adding a new distress kind is one function + one
import, no UI or API changes required.
v1 rule set
-----------
* ``hallucinated_cards`` (error) — folds the existing
``completion_blocked_hallucination`` event into the new surface.
* ``prose_phantom_refs`` (warning) — folds
``suspected_hallucinated_references``.
* ``repeated_spawn_failures`` (error → critical at 2x threshold) —
fires when ``tasks.spawn_failures >= 3``; suggests
``hermes -p <profile> doctor`` / ``auth``.
* ``repeated_crashes`` (error → critical) — fires after N consecutive
``crashed`` run outcomes with no successful completion between;
suggests ``hermes kanban log <id>``.
* ``stuck_in_blocked`` (warning) — fires after 24h in ``blocked``
state with no comments / unblock attempts; suggests commenting.
Every diagnostic carries structured ``actions`` (reclaim, reassign,
unblock, cli_hint, comment, open_docs) that render consistently in
both CLI and dashboard. Suggested actions are highlighted; generic
recovery actions (reclaim / reassign) are available on every kind as
fallbacks.
Diagnostics auto-clear when the underlying failure resolves — a
clean ``completed``/``edited`` event drops hallucination diagnostics,
a successful run drops crash diagnostics, a comment drops
stuck-blocked diagnostics. Audit events persist; the badge goes away.
API
---
``plugin_api.py``:
* ``/board`` now attaches ``diagnostics`` (full list) and
``warnings`` (compact summary with ``highest_severity``) per task.
* ``/tasks/{id}`` attaches diagnostics so the drawer's Diagnostics
section auto-opens on flagged tasks.
* NEW ``/diagnostics`` endpoint — fleet-wide listing, filterable by
severity, sorted critical-first.
CLI
---
* NEW ``hermes kanban diagnostics [--severity X] [--task id]
[--json]`` — fleet view or single-task view, matches dashboard rule
output so CLI users see the same picture.
* ``hermes kanban show <id>`` now renders a Diagnostics section near
the top with severity markers + suggested actions.
Dashboard
---------
* Card badge is severity-coloured (⚠ amber warning, !! orange error,
!!! red critical) using ``warnings.highest_severity``.
* Attention strip above the toolbar counts EVERY task with active
diagnostics (not just hallucinations), severity-coloured, lists
affected tasks with Open buttons when expanded.
* Drawer's old ``RecoverySection`` replaced with generic
``DiagnosticsSection`` rendering a card per active diagnostic:
title + detail + structured data (task-id chips when payload keys
look like id lists) + action buttons. Reassign profile picker is
inline per-diagnostic. Clipboard fallback uses ``.catch()`` for
environments where writeText rejects.
* Three-rung severity palette; amber for warning, orange for error,
red for critical. Uses CSS variables so theming is straightforward.
Tests
-----
* NEW ``tests/hermes_cli/test_kanban_diagnostics.py`` — 14 unit tests
covering each rule's positive/negative/threshold paths, severity
sorting, broken-rule isolation, and sqlite3.Row integration.
* Dashboard plugin tests extended: ``/diagnostics`` endpoint (empty,
populated, severity-filtered), ``/board`` exposes both diagnostic
list and compact summary with ``highest_severity``.
* Existing hallucination-specific test (``test_board_surfaces_
warnings_field_for_hallucinated_completions``) updated to reflect
the new contract: warning summary keys by diagnostic kind
(``hallucinated_cards``) not event kind.
379 kanban-suite tests pass (+16 net from this PR).
Live verification
-----------------
Seeded all 5 diagnostic kinds + one clean + one plain-running task
(7 total) into an isolated HERMES_HOME, spun up the dashboard, and
verified:
* Attention strip: shows ``!! 5 tasks need attention`` in the
error-severity orange; Show expands to a list of 5 rows ordered
critical > error > warning.
* Card badges: error tasks render ``!!`` orange, warning tasks
render ``⚠`` amber, clean and plain-running tasks render no badge.
* Each of the 5 rules opens a correctly-coloured, correctly-styled
diagnostic card in the drawer with its specific suggested action.
* Live reassign from a diagnostic card flipped
``broken-ml-worker → alice`` and the drawer refreshed with the
new assignee + the same diagnostic still firing (correct:
spawn_failures counter hasn't reset yet).
* CLI ``hermes kanban diagnostics`` prints all 5 in severity order;
``--severity error`` narrows to 3; ``kanban show <id>`` includes
the Diagnostics block at the top with suggested action hint.
Migration note
--------------
The old ``warnings`` shape (``{count, kinds, latest_at}``) is
preserved on the API but ``kinds`` now keys by diagnostic kind
(``hallucinated_cards``) instead of event kind
(``completion_blocked_hallucination``). ``highest_severity`` is a
new required field. The dashboard was the only consumer and has
been updated in the same commit; external API consumers of the
``warnings`` field will need to update their kind-match logic.
* feat(kanban/diagnostics): lead titles with the actual error text
The generic 'Worker crashed N runs in a row' / 'Worker failed to spawn
N times' titles buried the actual cause in the data section. Operators
had to open logs or expand the diagnostic to see WHY the worker is
stuck — rate-limit vs insufficient quota vs bad auth vs context
overflow vs network blip all looked identical at a glance.
New titles:
Agent crashed 3x: openai: 429 Too Many Requests - rate limit reached
Agent crashed 3x: anthropic: 402 insufficient_quota - credit balance
Agent crashed 3x: provider auth error: 401 Unauthorized
Agent spawn failed 4x: insufficient_quota: You exceeded your current
Detail keeps the full error snippet (capped at 500 chars + ellipsis
for tracebacks). Title takes the first line capped at 160 chars.
Fallback title if no error recorded stays honest ('no error recorded').
Tests: 4 new cases covering 429/billing/spawn/truncation. 383 total
pass (+4).
Live-verified on dashboard with 6 seeded scenarios
(rate-limit, billing, auth, context, network, spawn-billing) —
each card title leads with the actionable error text.
2026-05-05 13:32:42 -07:00
|
|
|
def _compute_task_diagnostics(
|
feat(kanban): hallucination gate + recovery UX for worker-created-card claims (#20232)
Workers completing a kanban task can now claim the ids of cards they
created via an optional ``created_cards`` field on ``kanban_complete``.
The kernel verifies each id exists and was created by the completing
worker's profile; any phantom id blocks the completion with a
``HallucinatedCardsError`` and records a
``completion_blocked_hallucination`` event on the task so the rejected
attempt is auditable. Successful completions also get a non-blocking
prose-scan pass over their ``summary`` + ``result`` that emits a
``suspected_hallucinated_references`` event for any ``t_<hex>``
reference that doesn't resolve.
Closes #20017.
Recovery UX (kernel + CLI + dashboard)
--------------------------------------
A structural gate alone isn't enough — operators also need to see and
act on stuck workers, especially when a profile's model is the root
cause. This PR ships the full loop:
* ``kanban_db.reclaim_task(task_id)`` — operator-driven reclaim that
releases an active worker claim immediately (unlike
``release_stale_claims`` which only acts after claim_expires has
passed). Emits a ``reclaimed`` event with ``manual: True`` payload.
* ``kanban_db.reassign_task(task_id, profile, reclaim_first=...)`` —
switch a task to a different profile, optionally reclaiming a stuck
running worker in the same call.
* ``hermes kanban reclaim <id> [--reason ...]`` and
``hermes kanban reassign <id> <profile> [--reclaim] [--reason ...]``
CLI subcommands wired through to the same helpers.
* ``POST /api/plugins/kanban/tasks/{id}/reclaim`` and
``POST /api/plugins/kanban/tasks/{id}/reassign`` endpoints on the
dashboard plugin.
Dashboard surfacing
-------------------
* ⚠ **warning badge** on cards with active hallucination events.
* **attention strip** at the top of the board listing all flagged
tasks; dismissible per session.
* **events callout** in the task drawer — hallucination events render
with a red left border, amber icon, and phantom ids as styled chips.
* **recovery section** in the task drawer with three actions: Reclaim,
Reassign (with profile picker + reclaim-first checkbox), and a
copy-to-clipboard hint for ``hermes -p <profile> model`` since
profile config lives on disk and can't be edited from the browser.
Auto-opens when the task has warnings, collapsed otherwise.
Keyed by task id so state doesn't leak between drawers.
Active-vs-stale rule: warnings clear when a clean ``completed`` or
``edited`` event supersedes the hallucination, so recovery is never
permanently stigmatising — the audit events persist for debugging but
the badge goes away once the worker succeeds.
Skill updates
-------------
* ``skills/devops/kanban-worker/SKILL.md`` documents the
``created_cards`` contract with good/bad examples.
* ``skills/devops/kanban-orchestrator/SKILL.md`` gains a "Recovering
stuck workers" section with the three actions and when to use each.
Tests
-----
* Kernel gate: verified-cards manifest, phantom rejection + audit
event, cross-worker rejection, prose scan positive + negative.
* Recovery helpers: reclaim on running task, reclaim on non-running
returns False, reassign refuses running without reclaim_first,
reassign with reclaim_first succeeds on running.
* API endpoints: warnings field present on /board and /tasks/:id,
warnings cleared after clean completion, reclaim 200 + 409 paths,
reassign 200 + 409 + reclaim_first paths.
* CLI smoke: reclaim + reassign subcommands.
Live-verified end-to-end on a dashboard with seeded scenarios:
attention strip renders, badges land on the right cards, drawer
callout shows phantom chips, Reclaim on a running task flips status to
ready + emits manual reclaimed event + refreshes the drawer,
Reassign swaps the assignee and triggers board refresh.
359/359 kanban-suite tests pass
(test_kanban_{db,cli,boards,core_functionality} + dashboard + tools).
2026-05-05 08:06:55 -07:00
|
|
|
conn: sqlite3.Connection,
|
|
|
|
|
task_ids: Optional[list[str]] = None,
|
feat(kanban): generic diagnostics engine for task distress signals (#20332)
* feat(kanban): generic diagnostics engine for task distress signals
Replaces the hallucination-specific ``warnings`` / ``RecoverySection``
surface (shipped in PR #20232) with a reusable diagnostic-rule engine
that covers five distress kinds in v1 and can be extended without
touching UI code. The "something's wrong with this task" signal is
no longer limited to phantom card ids.
Closes the follow-up from #20232 discussion.
New module
----------
``hermes_cli/kanban_diagnostics.py`` — stateless, no-side-effect rule
engine. Each rule is a pure function of
``(task, events, runs, now, config) -> list[Diagnostic]``. Registry
is a simple list; adding a new distress kind is one function + one
import, no UI or API changes required.
v1 rule set
-----------
* ``hallucinated_cards`` (error) — folds the existing
``completion_blocked_hallucination`` event into the new surface.
* ``prose_phantom_refs`` (warning) — folds
``suspected_hallucinated_references``.
* ``repeated_spawn_failures`` (error → critical at 2x threshold) —
fires when ``tasks.spawn_failures >= 3``; suggests
``hermes -p <profile> doctor`` / ``auth``.
* ``repeated_crashes`` (error → critical) — fires after N consecutive
``crashed`` run outcomes with no successful completion between;
suggests ``hermes kanban log <id>``.
* ``stuck_in_blocked`` (warning) — fires after 24h in ``blocked``
state with no comments / unblock attempts; suggests commenting.
Every diagnostic carries structured ``actions`` (reclaim, reassign,
unblock, cli_hint, comment, open_docs) that render consistently in
both CLI and dashboard. Suggested actions are highlighted; generic
recovery actions (reclaim / reassign) are available on every kind as
fallbacks.
Diagnostics auto-clear when the underlying failure resolves — a
clean ``completed``/``edited`` event drops hallucination diagnostics,
a successful run drops crash diagnostics, a comment drops
stuck-blocked diagnostics. Audit events persist; the badge goes away.
API
---
``plugin_api.py``:
* ``/board`` now attaches ``diagnostics`` (full list) and
``warnings`` (compact summary with ``highest_severity``) per task.
* ``/tasks/{id}`` attaches diagnostics so the drawer's Diagnostics
section auto-opens on flagged tasks.
* NEW ``/diagnostics`` endpoint — fleet-wide listing, filterable by
severity, sorted critical-first.
CLI
---
* NEW ``hermes kanban diagnostics [--severity X] [--task id]
[--json]`` — fleet view or single-task view, matches dashboard rule
output so CLI users see the same picture.
* ``hermes kanban show <id>`` now renders a Diagnostics section near
the top with severity markers + suggested actions.
Dashboard
---------
* Card badge is severity-coloured (⚠ amber warning, !! orange error,
!!! red critical) using ``warnings.highest_severity``.
* Attention strip above the toolbar counts EVERY task with active
diagnostics (not just hallucinations), severity-coloured, lists
affected tasks with Open buttons when expanded.
* Drawer's old ``RecoverySection`` replaced with generic
``DiagnosticsSection`` rendering a card per active diagnostic:
title + detail + structured data (task-id chips when payload keys
look like id lists) + action buttons. Reassign profile picker is
inline per-diagnostic. Clipboard fallback uses ``.catch()`` for
environments where writeText rejects.
* Three-rung severity palette; amber for warning, orange for error,
red for critical. Uses CSS variables so theming is straightforward.
Tests
-----
* NEW ``tests/hermes_cli/test_kanban_diagnostics.py`` — 14 unit tests
covering each rule's positive/negative/threshold paths, severity
sorting, broken-rule isolation, and sqlite3.Row integration.
* Dashboard plugin tests extended: ``/diagnostics`` endpoint (empty,
populated, severity-filtered), ``/board`` exposes both diagnostic
list and compact summary with ``highest_severity``.
* Existing hallucination-specific test (``test_board_surfaces_
warnings_field_for_hallucinated_completions``) updated to reflect
the new contract: warning summary keys by diagnostic kind
(``hallucinated_cards``) not event kind.
379 kanban-suite tests pass (+16 net from this PR).
Live verification
-----------------
Seeded all 5 diagnostic kinds + one clean + one plain-running task
(7 total) into an isolated HERMES_HOME, spun up the dashboard, and
verified:
* Attention strip: shows ``!! 5 tasks need attention`` in the
error-severity orange; Show expands to a list of 5 rows ordered
critical > error > warning.
* Card badges: error tasks render ``!!`` orange, warning tasks
render ``⚠`` amber, clean and plain-running tasks render no badge.
* Each of the 5 rules opens a correctly-coloured, correctly-styled
diagnostic card in the drawer with its specific suggested action.
* Live reassign from a diagnostic card flipped
``broken-ml-worker → alice`` and the drawer refreshed with the
new assignee + the same diagnostic still firing (correct:
spawn_failures counter hasn't reset yet).
* CLI ``hermes kanban diagnostics`` prints all 5 in severity order;
``--severity error`` narrows to 3; ``kanban show <id>`` includes
the Diagnostics block at the top with suggested action hint.
Migration note
--------------
The old ``warnings`` shape (``{count, kinds, latest_at}``) is
preserved on the API but ``kinds`` now keys by diagnostic kind
(``hallucinated_cards``) instead of event kind
(``completion_blocked_hallucination``). ``highest_severity`` is a
new required field. The dashboard was the only consumer and has
been updated in the same commit; external API consumers of the
``warnings`` field will need to update their kind-match logic.
* feat(kanban/diagnostics): lead titles with the actual error text
The generic 'Worker crashed N runs in a row' / 'Worker failed to spawn
N times' titles buried the actual cause in the data section. Operators
had to open logs or expand the diagnostic to see WHY the worker is
stuck — rate-limit vs insufficient quota vs bad auth vs context
overflow vs network blip all looked identical at a glance.
New titles:
Agent crashed 3x: openai: 429 Too Many Requests - rate limit reached
Agent crashed 3x: anthropic: 402 insufficient_quota - credit balance
Agent crashed 3x: provider auth error: 401 Unauthorized
Agent spawn failed 4x: insufficient_quota: You exceeded your current
Detail keeps the full error snippet (capped at 500 chars + ellipsis
for tracebacks). Title takes the first line capped at 160 chars.
Fallback title if no error recorded stays honest ('no error recorded').
Tests: 4 new cases covering 429/billing/spawn/truncation. 383 total
pass (+4).
Live-verified on dashboard with 6 seeded scenarios
(rate-limit, billing, auth, context, network, spawn-billing) —
each card title leads with the actionable error text.
2026-05-05 13:32:42 -07:00
|
|
|
) -> dict[str, list[dict]]:
|
|
|
|
|
"""Run the diagnostic rule engine against every task (or a subset)
|
|
|
|
|
and return ``{task_id: [diagnostic_dict, ...]}``.
|
|
|
|
|
|
|
|
|
|
Tasks with no active diagnostics are omitted from the result.
|
|
|
|
|
Uses ``hermes_cli.kanban_diagnostics`` — see that module for the
|
|
|
|
|
rule definitions.
|
feat(kanban): hallucination gate + recovery UX for worker-created-card claims (#20232)
Workers completing a kanban task can now claim the ids of cards they
created via an optional ``created_cards`` field on ``kanban_complete``.
The kernel verifies each id exists and was created by the completing
worker's profile; any phantom id blocks the completion with a
``HallucinatedCardsError`` and records a
``completion_blocked_hallucination`` event on the task so the rejected
attempt is auditable. Successful completions also get a non-blocking
prose-scan pass over their ``summary`` + ``result`` that emits a
``suspected_hallucinated_references`` event for any ``t_<hex>``
reference that doesn't resolve.
Closes #20017.
Recovery UX (kernel + CLI + dashboard)
--------------------------------------
A structural gate alone isn't enough — operators also need to see and
act on stuck workers, especially when a profile's model is the root
cause. This PR ships the full loop:
* ``kanban_db.reclaim_task(task_id)`` — operator-driven reclaim that
releases an active worker claim immediately (unlike
``release_stale_claims`` which only acts after claim_expires has
passed). Emits a ``reclaimed`` event with ``manual: True`` payload.
* ``kanban_db.reassign_task(task_id, profile, reclaim_first=...)`` —
switch a task to a different profile, optionally reclaiming a stuck
running worker in the same call.
* ``hermes kanban reclaim <id> [--reason ...]`` and
``hermes kanban reassign <id> <profile> [--reclaim] [--reason ...]``
CLI subcommands wired through to the same helpers.
* ``POST /api/plugins/kanban/tasks/{id}/reclaim`` and
``POST /api/plugins/kanban/tasks/{id}/reassign`` endpoints on the
dashboard plugin.
Dashboard surfacing
-------------------
* ⚠ **warning badge** on cards with active hallucination events.
* **attention strip** at the top of the board listing all flagged
tasks; dismissible per session.
* **events callout** in the task drawer — hallucination events render
with a red left border, amber icon, and phantom ids as styled chips.
* **recovery section** in the task drawer with three actions: Reclaim,
Reassign (with profile picker + reclaim-first checkbox), and a
copy-to-clipboard hint for ``hermes -p <profile> model`` since
profile config lives on disk and can't be edited from the browser.
Auto-opens when the task has warnings, collapsed otherwise.
Keyed by task id so state doesn't leak between drawers.
Active-vs-stale rule: warnings clear when a clean ``completed`` or
``edited`` event supersedes the hallucination, so recovery is never
permanently stigmatising — the audit events persist for debugging but
the badge goes away once the worker succeeds.
Skill updates
-------------
* ``skills/devops/kanban-worker/SKILL.md`` documents the
``created_cards`` contract with good/bad examples.
* ``skills/devops/kanban-orchestrator/SKILL.md`` gains a "Recovering
stuck workers" section with the three actions and when to use each.
Tests
-----
* Kernel gate: verified-cards manifest, phantom rejection + audit
event, cross-worker rejection, prose scan positive + negative.
* Recovery helpers: reclaim on running task, reclaim on non-running
returns False, reassign refuses running without reclaim_first,
reassign with reclaim_first succeeds on running.
* API endpoints: warnings field present on /board and /tasks/:id,
warnings cleared after clean completion, reclaim 200 + 409 paths,
reassign 200 + 409 + reclaim_first paths.
* CLI smoke: reclaim + reassign subcommands.
Live-verified end-to-end on a dashboard with seeded scenarios:
attention strip renders, badges land on the right cards, drawer
callout shows phantom chips, Reclaim on a running task flips status to
ready + emits manual reclaimed event + refreshes the drawer,
Reassign swaps the assignee and triggers board refresh.
359/359 kanban-suite tests pass
(test_kanban_{db,cli,boards,core_functionality} + dashboard + tools).
2026-05-05 08:06:55 -07:00
|
|
|
"""
|
feat(kanban): generic diagnostics engine for task distress signals (#20332)
* feat(kanban): generic diagnostics engine for task distress signals
Replaces the hallucination-specific ``warnings`` / ``RecoverySection``
surface (shipped in PR #20232) with a reusable diagnostic-rule engine
that covers five distress kinds in v1 and can be extended without
touching UI code. The "something's wrong with this task" signal is
no longer limited to phantom card ids.
Closes the follow-up from #20232 discussion.
New module
----------
``hermes_cli/kanban_diagnostics.py`` — stateless, no-side-effect rule
engine. Each rule is a pure function of
``(task, events, runs, now, config) -> list[Diagnostic]``. Registry
is a simple list; adding a new distress kind is one function + one
import, no UI or API changes required.
v1 rule set
-----------
* ``hallucinated_cards`` (error) — folds the existing
``completion_blocked_hallucination`` event into the new surface.
* ``prose_phantom_refs`` (warning) — folds
``suspected_hallucinated_references``.
* ``repeated_spawn_failures`` (error → critical at 2x threshold) —
fires when ``tasks.spawn_failures >= 3``; suggests
``hermes -p <profile> doctor`` / ``auth``.
* ``repeated_crashes`` (error → critical) — fires after N consecutive
``crashed`` run outcomes with no successful completion between;
suggests ``hermes kanban log <id>``.
* ``stuck_in_blocked`` (warning) — fires after 24h in ``blocked``
state with no comments / unblock attempts; suggests commenting.
Every diagnostic carries structured ``actions`` (reclaim, reassign,
unblock, cli_hint, comment, open_docs) that render consistently in
both CLI and dashboard. Suggested actions are highlighted; generic
recovery actions (reclaim / reassign) are available on every kind as
fallbacks.
Diagnostics auto-clear when the underlying failure resolves — a
clean ``completed``/``edited`` event drops hallucination diagnostics,
a successful run drops crash diagnostics, a comment drops
stuck-blocked diagnostics. Audit events persist; the badge goes away.
API
---
``plugin_api.py``:
* ``/board`` now attaches ``diagnostics`` (full list) and
``warnings`` (compact summary with ``highest_severity``) per task.
* ``/tasks/{id}`` attaches diagnostics so the drawer's Diagnostics
section auto-opens on flagged tasks.
* NEW ``/diagnostics`` endpoint — fleet-wide listing, filterable by
severity, sorted critical-first.
CLI
---
* NEW ``hermes kanban diagnostics [--severity X] [--task id]
[--json]`` — fleet view or single-task view, matches dashboard rule
output so CLI users see the same picture.
* ``hermes kanban show <id>`` now renders a Diagnostics section near
the top with severity markers + suggested actions.
Dashboard
---------
* Card badge is severity-coloured (⚠ amber warning, !! orange error,
!!! red critical) using ``warnings.highest_severity``.
* Attention strip above the toolbar counts EVERY task with active
diagnostics (not just hallucinations), severity-coloured, lists
affected tasks with Open buttons when expanded.
* Drawer's old ``RecoverySection`` replaced with generic
``DiagnosticsSection`` rendering a card per active diagnostic:
title + detail + structured data (task-id chips when payload keys
look like id lists) + action buttons. Reassign profile picker is
inline per-diagnostic. Clipboard fallback uses ``.catch()`` for
environments where writeText rejects.
* Three-rung severity palette; amber for warning, orange for error,
red for critical. Uses CSS variables so theming is straightforward.
Tests
-----
* NEW ``tests/hermes_cli/test_kanban_diagnostics.py`` — 14 unit tests
covering each rule's positive/negative/threshold paths, severity
sorting, broken-rule isolation, and sqlite3.Row integration.
* Dashboard plugin tests extended: ``/diagnostics`` endpoint (empty,
populated, severity-filtered), ``/board`` exposes both diagnostic
list and compact summary with ``highest_severity``.
* Existing hallucination-specific test (``test_board_surfaces_
warnings_field_for_hallucinated_completions``) updated to reflect
the new contract: warning summary keys by diagnostic kind
(``hallucinated_cards``) not event kind.
379 kanban-suite tests pass (+16 net from this PR).
Live verification
-----------------
Seeded all 5 diagnostic kinds + one clean + one plain-running task
(7 total) into an isolated HERMES_HOME, spun up the dashboard, and
verified:
* Attention strip: shows ``!! 5 tasks need attention`` in the
error-severity orange; Show expands to a list of 5 rows ordered
critical > error > warning.
* Card badges: error tasks render ``!!`` orange, warning tasks
render ``⚠`` amber, clean and plain-running tasks render no badge.
* Each of the 5 rules opens a correctly-coloured, correctly-styled
diagnostic card in the drawer with its specific suggested action.
* Live reassign from a diagnostic card flipped
``broken-ml-worker → alice`` and the drawer refreshed with the
new assignee + the same diagnostic still firing (correct:
spawn_failures counter hasn't reset yet).
* CLI ``hermes kanban diagnostics`` prints all 5 in severity order;
``--severity error`` narrows to 3; ``kanban show <id>`` includes
the Diagnostics block at the top with suggested action hint.
Migration note
--------------
The old ``warnings`` shape (``{count, kinds, latest_at}``) is
preserved on the API but ``kinds`` now keys by diagnostic kind
(``hallucinated_cards``) instead of event kind
(``completion_blocked_hallucination``). ``highest_severity`` is a
new required field. The dashboard was the only consumer and has
been updated in the same commit; external API consumers of the
``warnings`` field will need to update their kind-match logic.
* feat(kanban/diagnostics): lead titles with the actual error text
The generic 'Worker crashed N runs in a row' / 'Worker failed to spawn
N times' titles buried the actual cause in the data section. Operators
had to open logs or expand the diagnostic to see WHY the worker is
stuck — rate-limit vs insufficient quota vs bad auth vs context
overflow vs network blip all looked identical at a glance.
New titles:
Agent crashed 3x: openai: 429 Too Many Requests - rate limit reached
Agent crashed 3x: anthropic: 402 insufficient_quota - credit balance
Agent crashed 3x: provider auth error: 401 Unauthorized
Agent spawn failed 4x: insufficient_quota: You exceeded your current
Detail keeps the full error snippet (capped at 500 chars + ellipsis
for tracebacks). Title takes the first line capped at 160 chars.
Fallback title if no error recorded stays honest ('no error recorded').
Tests: 4 new cases covering 429/billing/spawn/truncation. 383 total
pass (+4).
Live-verified on dashboard with 6 seeded scenarios
(rate-limit, billing, auth, context, network, spawn-billing) —
each card title leads with the actionable error text.
2026-05-05 13:32:42 -07:00
|
|
|
from hermes_cli import kanban_diagnostics as kd
|
2026-05-14 17:07:57 +08:00
|
|
|
from hermes_cli.config import load_config
|
|
|
|
|
|
2026-05-18 01:27:06 -07:00
|
|
|
diag_config = kd.config_from_runtime_config(load_config())
|
feat(kanban): generic diagnostics engine for task distress signals (#20332)
* feat(kanban): generic diagnostics engine for task distress signals
Replaces the hallucination-specific ``warnings`` / ``RecoverySection``
surface (shipped in PR #20232) with a reusable diagnostic-rule engine
that covers five distress kinds in v1 and can be extended without
touching UI code. The "something's wrong with this task" signal is
no longer limited to phantom card ids.
Closes the follow-up from #20232 discussion.
New module
----------
``hermes_cli/kanban_diagnostics.py`` — stateless, no-side-effect rule
engine. Each rule is a pure function of
``(task, events, runs, now, config) -> list[Diagnostic]``. Registry
is a simple list; adding a new distress kind is one function + one
import, no UI or API changes required.
v1 rule set
-----------
* ``hallucinated_cards`` (error) — folds the existing
``completion_blocked_hallucination`` event into the new surface.
* ``prose_phantom_refs`` (warning) — folds
``suspected_hallucinated_references``.
* ``repeated_spawn_failures`` (error → critical at 2x threshold) —
fires when ``tasks.spawn_failures >= 3``; suggests
``hermes -p <profile> doctor`` / ``auth``.
* ``repeated_crashes`` (error → critical) — fires after N consecutive
``crashed`` run outcomes with no successful completion between;
suggests ``hermes kanban log <id>``.
* ``stuck_in_blocked`` (warning) — fires after 24h in ``blocked``
state with no comments / unblock attempts; suggests commenting.
Every diagnostic carries structured ``actions`` (reclaim, reassign,
unblock, cli_hint, comment, open_docs) that render consistently in
both CLI and dashboard. Suggested actions are highlighted; generic
recovery actions (reclaim / reassign) are available on every kind as
fallbacks.
Diagnostics auto-clear when the underlying failure resolves — a
clean ``completed``/``edited`` event drops hallucination diagnostics,
a successful run drops crash diagnostics, a comment drops
stuck-blocked diagnostics. Audit events persist; the badge goes away.
API
---
``plugin_api.py``:
* ``/board`` now attaches ``diagnostics`` (full list) and
``warnings`` (compact summary with ``highest_severity``) per task.
* ``/tasks/{id}`` attaches diagnostics so the drawer's Diagnostics
section auto-opens on flagged tasks.
* NEW ``/diagnostics`` endpoint — fleet-wide listing, filterable by
severity, sorted critical-first.
CLI
---
* NEW ``hermes kanban diagnostics [--severity X] [--task id]
[--json]`` — fleet view or single-task view, matches dashboard rule
output so CLI users see the same picture.
* ``hermes kanban show <id>`` now renders a Diagnostics section near
the top with severity markers + suggested actions.
Dashboard
---------
* Card badge is severity-coloured (⚠ amber warning, !! orange error,
!!! red critical) using ``warnings.highest_severity``.
* Attention strip above the toolbar counts EVERY task with active
diagnostics (not just hallucinations), severity-coloured, lists
affected tasks with Open buttons when expanded.
* Drawer's old ``RecoverySection`` replaced with generic
``DiagnosticsSection`` rendering a card per active diagnostic:
title + detail + structured data (task-id chips when payload keys
look like id lists) + action buttons. Reassign profile picker is
inline per-diagnostic. Clipboard fallback uses ``.catch()`` for
environments where writeText rejects.
* Three-rung severity palette; amber for warning, orange for error,
red for critical. Uses CSS variables so theming is straightforward.
Tests
-----
* NEW ``tests/hermes_cli/test_kanban_diagnostics.py`` — 14 unit tests
covering each rule's positive/negative/threshold paths, severity
sorting, broken-rule isolation, and sqlite3.Row integration.
* Dashboard plugin tests extended: ``/diagnostics`` endpoint (empty,
populated, severity-filtered), ``/board`` exposes both diagnostic
list and compact summary with ``highest_severity``.
* Existing hallucination-specific test (``test_board_surfaces_
warnings_field_for_hallucinated_completions``) updated to reflect
the new contract: warning summary keys by diagnostic kind
(``hallucinated_cards``) not event kind.
379 kanban-suite tests pass (+16 net from this PR).
Live verification
-----------------
Seeded all 5 diagnostic kinds + one clean + one plain-running task
(7 total) into an isolated HERMES_HOME, spun up the dashboard, and
verified:
* Attention strip: shows ``!! 5 tasks need attention`` in the
error-severity orange; Show expands to a list of 5 rows ordered
critical > error > warning.
* Card badges: error tasks render ``!!`` orange, warning tasks
render ``⚠`` amber, clean and plain-running tasks render no badge.
* Each of the 5 rules opens a correctly-coloured, correctly-styled
diagnostic card in the drawer with its specific suggested action.
* Live reassign from a diagnostic card flipped
``broken-ml-worker → alice`` and the drawer refreshed with the
new assignee + the same diagnostic still firing (correct:
spawn_failures counter hasn't reset yet).
* CLI ``hermes kanban diagnostics`` prints all 5 in severity order;
``--severity error`` narrows to 3; ``kanban show <id>`` includes
the Diagnostics block at the top with suggested action hint.
Migration note
--------------
The old ``warnings`` shape (``{count, kinds, latest_at}``) is
preserved on the API but ``kinds`` now keys by diagnostic kind
(``hallucinated_cards``) instead of event kind
(``completion_blocked_hallucination``). ``highest_severity`` is a
new required field. The dashboard was the only consumer and has
been updated in the same commit; external API consumers of the
``warnings`` field will need to update their kind-match logic.
* feat(kanban/diagnostics): lead titles with the actual error text
The generic 'Worker crashed N runs in a row' / 'Worker failed to spawn
N times' titles buried the actual cause in the data section. Operators
had to open logs or expand the diagnostic to see WHY the worker is
stuck — rate-limit vs insufficient quota vs bad auth vs context
overflow vs network blip all looked identical at a glance.
New titles:
Agent crashed 3x: openai: 429 Too Many Requests - rate limit reached
Agent crashed 3x: anthropic: 402 insufficient_quota - credit balance
Agent crashed 3x: provider auth error: 401 Unauthorized
Agent spawn failed 4x: insufficient_quota: You exceeded your current
Detail keeps the full error snippet (capped at 500 chars + ellipsis
for tracebacks). Title takes the first line capped at 160 chars.
Fallback title if no error recorded stays honest ('no error recorded').
Tests: 4 new cases covering 429/billing/spawn/truncation. 383 total
pass (+4).
Live-verified on dashboard with 6 seeded scenarios
(rate-limit, billing, auth, context, network, spawn-billing) —
each card title leads with the actionable error text.
2026-05-05 13:32:42 -07:00
|
|
|
|
|
|
|
|
# Build the candidate task list. We need each task's row + its
|
|
|
|
|
# events + its runs. Doing N separate queries works but scales
|
|
|
|
|
# poorly; do three aggregate queries instead.
|
feat(kanban): hallucination gate + recovery UX for worker-created-card claims (#20232)
Workers completing a kanban task can now claim the ids of cards they
created via an optional ``created_cards`` field on ``kanban_complete``.
The kernel verifies each id exists and was created by the completing
worker's profile; any phantom id blocks the completion with a
``HallucinatedCardsError`` and records a
``completion_blocked_hallucination`` event on the task so the rejected
attempt is auditable. Successful completions also get a non-blocking
prose-scan pass over their ``summary`` + ``result`` that emits a
``suspected_hallucinated_references`` event for any ``t_<hex>``
reference that doesn't resolve.
Closes #20017.
Recovery UX (kernel + CLI + dashboard)
--------------------------------------
A structural gate alone isn't enough — operators also need to see and
act on stuck workers, especially when a profile's model is the root
cause. This PR ships the full loop:
* ``kanban_db.reclaim_task(task_id)`` — operator-driven reclaim that
releases an active worker claim immediately (unlike
``release_stale_claims`` which only acts after claim_expires has
passed). Emits a ``reclaimed`` event with ``manual: True`` payload.
* ``kanban_db.reassign_task(task_id, profile, reclaim_first=...)`` —
switch a task to a different profile, optionally reclaiming a stuck
running worker in the same call.
* ``hermes kanban reclaim <id> [--reason ...]`` and
``hermes kanban reassign <id> <profile> [--reclaim] [--reason ...]``
CLI subcommands wired through to the same helpers.
* ``POST /api/plugins/kanban/tasks/{id}/reclaim`` and
``POST /api/plugins/kanban/tasks/{id}/reassign`` endpoints on the
dashboard plugin.
Dashboard surfacing
-------------------
* ⚠ **warning badge** on cards with active hallucination events.
* **attention strip** at the top of the board listing all flagged
tasks; dismissible per session.
* **events callout** in the task drawer — hallucination events render
with a red left border, amber icon, and phantom ids as styled chips.
* **recovery section** in the task drawer with three actions: Reclaim,
Reassign (with profile picker + reclaim-first checkbox), and a
copy-to-clipboard hint for ``hermes -p <profile> model`` since
profile config lives on disk and can't be edited from the browser.
Auto-opens when the task has warnings, collapsed otherwise.
Keyed by task id so state doesn't leak between drawers.
Active-vs-stale rule: warnings clear when a clean ``completed`` or
``edited`` event supersedes the hallucination, so recovery is never
permanently stigmatising — the audit events persist for debugging but
the badge goes away once the worker succeeds.
Skill updates
-------------
* ``skills/devops/kanban-worker/SKILL.md`` documents the
``created_cards`` contract with good/bad examples.
* ``skills/devops/kanban-orchestrator/SKILL.md`` gains a "Recovering
stuck workers" section with the three actions and when to use each.
Tests
-----
* Kernel gate: verified-cards manifest, phantom rejection + audit
event, cross-worker rejection, prose scan positive + negative.
* Recovery helpers: reclaim on running task, reclaim on non-running
returns False, reassign refuses running without reclaim_first,
reassign with reclaim_first succeeds on running.
* API endpoints: warnings field present on /board and /tasks/:id,
warnings cleared after clean completion, reclaim 200 + 409 paths,
reassign 200 + 409 + reclaim_first paths.
* CLI smoke: reclaim + reassign subcommands.
Live-verified end-to-end on a dashboard with seeded scenarios:
attention strip renders, badges land on the right cards, drawer
callout shows phantom chips, Reclaim on a running task flips status to
ready + emits manual reclaimed event + refreshes the drawer,
Reassign swaps the assignee and triggers board refresh.
359/359 kanban-suite tests pass
(test_kanban_{db,cli,boards,core_functionality} + dashboard + tools).
2026-05-05 08:06:55 -07:00
|
|
|
if task_ids is not None:
|
|
|
|
|
if not task_ids:
|
|
|
|
|
return {}
|
|
|
|
|
placeholders = ",".join(["?"] * len(task_ids))
|
feat(kanban): generic diagnostics engine for task distress signals (#20332)
* feat(kanban): generic diagnostics engine for task distress signals
Replaces the hallucination-specific ``warnings`` / ``RecoverySection``
surface (shipped in PR #20232) with a reusable diagnostic-rule engine
that covers five distress kinds in v1 and can be extended without
touching UI code. The "something's wrong with this task" signal is
no longer limited to phantom card ids.
Closes the follow-up from #20232 discussion.
New module
----------
``hermes_cli/kanban_diagnostics.py`` — stateless, no-side-effect rule
engine. Each rule is a pure function of
``(task, events, runs, now, config) -> list[Diagnostic]``. Registry
is a simple list; adding a new distress kind is one function + one
import, no UI or API changes required.
v1 rule set
-----------
* ``hallucinated_cards`` (error) — folds the existing
``completion_blocked_hallucination`` event into the new surface.
* ``prose_phantom_refs`` (warning) — folds
``suspected_hallucinated_references``.
* ``repeated_spawn_failures`` (error → critical at 2x threshold) —
fires when ``tasks.spawn_failures >= 3``; suggests
``hermes -p <profile> doctor`` / ``auth``.
* ``repeated_crashes`` (error → critical) — fires after N consecutive
``crashed`` run outcomes with no successful completion between;
suggests ``hermes kanban log <id>``.
* ``stuck_in_blocked`` (warning) — fires after 24h in ``blocked``
state with no comments / unblock attempts; suggests commenting.
Every diagnostic carries structured ``actions`` (reclaim, reassign,
unblock, cli_hint, comment, open_docs) that render consistently in
both CLI and dashboard. Suggested actions are highlighted; generic
recovery actions (reclaim / reassign) are available on every kind as
fallbacks.
Diagnostics auto-clear when the underlying failure resolves — a
clean ``completed``/``edited`` event drops hallucination diagnostics,
a successful run drops crash diagnostics, a comment drops
stuck-blocked diagnostics. Audit events persist; the badge goes away.
API
---
``plugin_api.py``:
* ``/board`` now attaches ``diagnostics`` (full list) and
``warnings`` (compact summary with ``highest_severity``) per task.
* ``/tasks/{id}`` attaches diagnostics so the drawer's Diagnostics
section auto-opens on flagged tasks.
* NEW ``/diagnostics`` endpoint — fleet-wide listing, filterable by
severity, sorted critical-first.
CLI
---
* NEW ``hermes kanban diagnostics [--severity X] [--task id]
[--json]`` — fleet view or single-task view, matches dashboard rule
output so CLI users see the same picture.
* ``hermes kanban show <id>`` now renders a Diagnostics section near
the top with severity markers + suggested actions.
Dashboard
---------
* Card badge is severity-coloured (⚠ amber warning, !! orange error,
!!! red critical) using ``warnings.highest_severity``.
* Attention strip above the toolbar counts EVERY task with active
diagnostics (not just hallucinations), severity-coloured, lists
affected tasks with Open buttons when expanded.
* Drawer's old ``RecoverySection`` replaced with generic
``DiagnosticsSection`` rendering a card per active diagnostic:
title + detail + structured data (task-id chips when payload keys
look like id lists) + action buttons. Reassign profile picker is
inline per-diagnostic. Clipboard fallback uses ``.catch()`` for
environments where writeText rejects.
* Three-rung severity palette; amber for warning, orange for error,
red for critical. Uses CSS variables so theming is straightforward.
Tests
-----
* NEW ``tests/hermes_cli/test_kanban_diagnostics.py`` — 14 unit tests
covering each rule's positive/negative/threshold paths, severity
sorting, broken-rule isolation, and sqlite3.Row integration.
* Dashboard plugin tests extended: ``/diagnostics`` endpoint (empty,
populated, severity-filtered), ``/board`` exposes both diagnostic
list and compact summary with ``highest_severity``.
* Existing hallucination-specific test (``test_board_surfaces_
warnings_field_for_hallucinated_completions``) updated to reflect
the new contract: warning summary keys by diagnostic kind
(``hallucinated_cards``) not event kind.
379 kanban-suite tests pass (+16 net from this PR).
Live verification
-----------------
Seeded all 5 diagnostic kinds + one clean + one plain-running task
(7 total) into an isolated HERMES_HOME, spun up the dashboard, and
verified:
* Attention strip: shows ``!! 5 tasks need attention`` in the
error-severity orange; Show expands to a list of 5 rows ordered
critical > error > warning.
* Card badges: error tasks render ``!!`` orange, warning tasks
render ``⚠`` amber, clean and plain-running tasks render no badge.
* Each of the 5 rules opens a correctly-coloured, correctly-styled
diagnostic card in the drawer with its specific suggested action.
* Live reassign from a diagnostic card flipped
``broken-ml-worker → alice`` and the drawer refreshed with the
new assignee + the same diagnostic still firing (correct:
spawn_failures counter hasn't reset yet).
* CLI ``hermes kanban diagnostics`` prints all 5 in severity order;
``--severity error`` narrows to 3; ``kanban show <id>`` includes
the Diagnostics block at the top with suggested action hint.
Migration note
--------------
The old ``warnings`` shape (``{count, kinds, latest_at}``) is
preserved on the API but ``kinds`` now keys by diagnostic kind
(``hallucinated_cards``) instead of event kind
(``completion_blocked_hallucination``). ``highest_severity`` is a
new required field. The dashboard was the only consumer and has
been updated in the same commit; external API consumers of the
``warnings`` field will need to update their kind-match logic.
* feat(kanban/diagnostics): lead titles with the actual error text
The generic 'Worker crashed N runs in a row' / 'Worker failed to spawn
N times' titles buried the actual cause in the data section. Operators
had to open logs or expand the diagnostic to see WHY the worker is
stuck — rate-limit vs insufficient quota vs bad auth vs context
overflow vs network blip all looked identical at a glance.
New titles:
Agent crashed 3x: openai: 429 Too Many Requests - rate limit reached
Agent crashed 3x: anthropic: 402 insufficient_quota - credit balance
Agent crashed 3x: provider auth error: 401 Unauthorized
Agent spawn failed 4x: insufficient_quota: You exceeded your current
Detail keeps the full error snippet (capped at 500 chars + ellipsis
for tracebacks). Title takes the first line capped at 160 chars.
Fallback title if no error recorded stays honest ('no error recorded').
Tests: 4 new cases covering 429/billing/spawn/truncation. 383 total
pass (+4).
Live-verified on dashboard with 6 seeded scenarios
(rate-limit, billing, auth, context, network, spawn-billing) —
each card title leads with the actionable error text.
2026-05-05 13:32:42 -07:00
|
|
|
rows = conn.execute(
|
|
|
|
|
f"SELECT * FROM tasks WHERE id IN ({placeholders})",
|
|
|
|
|
tuple(task_ids),
|
|
|
|
|
).fetchall()
|
feat(kanban): hallucination gate + recovery UX for worker-created-card claims (#20232)
Workers completing a kanban task can now claim the ids of cards they
created via an optional ``created_cards`` field on ``kanban_complete``.
The kernel verifies each id exists and was created by the completing
worker's profile; any phantom id blocks the completion with a
``HallucinatedCardsError`` and records a
``completion_blocked_hallucination`` event on the task so the rejected
attempt is auditable. Successful completions also get a non-blocking
prose-scan pass over their ``summary`` + ``result`` that emits a
``suspected_hallucinated_references`` event for any ``t_<hex>``
reference that doesn't resolve.
Closes #20017.
Recovery UX (kernel + CLI + dashboard)
--------------------------------------
A structural gate alone isn't enough — operators also need to see and
act on stuck workers, especially when a profile's model is the root
cause. This PR ships the full loop:
* ``kanban_db.reclaim_task(task_id)`` — operator-driven reclaim that
releases an active worker claim immediately (unlike
``release_stale_claims`` which only acts after claim_expires has
passed). Emits a ``reclaimed`` event with ``manual: True`` payload.
* ``kanban_db.reassign_task(task_id, profile, reclaim_first=...)`` —
switch a task to a different profile, optionally reclaiming a stuck
running worker in the same call.
* ``hermes kanban reclaim <id> [--reason ...]`` and
``hermes kanban reassign <id> <profile> [--reclaim] [--reason ...]``
CLI subcommands wired through to the same helpers.
* ``POST /api/plugins/kanban/tasks/{id}/reclaim`` and
``POST /api/plugins/kanban/tasks/{id}/reassign`` endpoints on the
dashboard plugin.
Dashboard surfacing
-------------------
* ⚠ **warning badge** on cards with active hallucination events.
* **attention strip** at the top of the board listing all flagged
tasks; dismissible per session.
* **events callout** in the task drawer — hallucination events render
with a red left border, amber icon, and phantom ids as styled chips.
* **recovery section** in the task drawer with three actions: Reclaim,
Reassign (with profile picker + reclaim-first checkbox), and a
copy-to-clipboard hint for ``hermes -p <profile> model`` since
profile config lives on disk and can't be edited from the browser.
Auto-opens when the task has warnings, collapsed otherwise.
Keyed by task id so state doesn't leak between drawers.
Active-vs-stale rule: warnings clear when a clean ``completed`` or
``edited`` event supersedes the hallucination, so recovery is never
permanently stigmatising — the audit events persist for debugging but
the badge goes away once the worker succeeds.
Skill updates
-------------
* ``skills/devops/kanban-worker/SKILL.md`` documents the
``created_cards`` contract with good/bad examples.
* ``skills/devops/kanban-orchestrator/SKILL.md`` gains a "Recovering
stuck workers" section with the three actions and when to use each.
Tests
-----
* Kernel gate: verified-cards manifest, phantom rejection + audit
event, cross-worker rejection, prose scan positive + negative.
* Recovery helpers: reclaim on running task, reclaim on non-running
returns False, reassign refuses running without reclaim_first,
reassign with reclaim_first succeeds on running.
* API endpoints: warnings field present on /board and /tasks/:id,
warnings cleared after clean completion, reclaim 200 + 409 paths,
reassign 200 + 409 + reclaim_first paths.
* CLI smoke: reclaim + reassign subcommands.
Live-verified end-to-end on a dashboard with seeded scenarios:
attention strip renders, badges land on the right cards, drawer
callout shows phantom chips, Reclaim on a running task flips status to
ready + emits manual reclaimed event + refreshes the drawer,
Reassign swaps the assignee and triggers board refresh.
359/359 kanban-suite tests pass
(test_kanban_{db,cli,boards,core_functionality} + dashboard + tools).
2026-05-05 08:06:55 -07:00
|
|
|
else:
|
feat(kanban): generic diagnostics engine for task distress signals (#20332)
* feat(kanban): generic diagnostics engine for task distress signals
Replaces the hallucination-specific ``warnings`` / ``RecoverySection``
surface (shipped in PR #20232) with a reusable diagnostic-rule engine
that covers five distress kinds in v1 and can be extended without
touching UI code. The "something's wrong with this task" signal is
no longer limited to phantom card ids.
Closes the follow-up from #20232 discussion.
New module
----------
``hermes_cli/kanban_diagnostics.py`` — stateless, no-side-effect rule
engine. Each rule is a pure function of
``(task, events, runs, now, config) -> list[Diagnostic]``. Registry
is a simple list; adding a new distress kind is one function + one
import, no UI or API changes required.
v1 rule set
-----------
* ``hallucinated_cards`` (error) — folds the existing
``completion_blocked_hallucination`` event into the new surface.
* ``prose_phantom_refs`` (warning) — folds
``suspected_hallucinated_references``.
* ``repeated_spawn_failures`` (error → critical at 2x threshold) —
fires when ``tasks.spawn_failures >= 3``; suggests
``hermes -p <profile> doctor`` / ``auth``.
* ``repeated_crashes`` (error → critical) — fires after N consecutive
``crashed`` run outcomes with no successful completion between;
suggests ``hermes kanban log <id>``.
* ``stuck_in_blocked`` (warning) — fires after 24h in ``blocked``
state with no comments / unblock attempts; suggests commenting.
Every diagnostic carries structured ``actions`` (reclaim, reassign,
unblock, cli_hint, comment, open_docs) that render consistently in
both CLI and dashboard. Suggested actions are highlighted; generic
recovery actions (reclaim / reassign) are available on every kind as
fallbacks.
Diagnostics auto-clear when the underlying failure resolves — a
clean ``completed``/``edited`` event drops hallucination diagnostics,
a successful run drops crash diagnostics, a comment drops
stuck-blocked diagnostics. Audit events persist; the badge goes away.
API
---
``plugin_api.py``:
* ``/board`` now attaches ``diagnostics`` (full list) and
``warnings`` (compact summary with ``highest_severity``) per task.
* ``/tasks/{id}`` attaches diagnostics so the drawer's Diagnostics
section auto-opens on flagged tasks.
* NEW ``/diagnostics`` endpoint — fleet-wide listing, filterable by
severity, sorted critical-first.
CLI
---
* NEW ``hermes kanban diagnostics [--severity X] [--task id]
[--json]`` — fleet view or single-task view, matches dashboard rule
output so CLI users see the same picture.
* ``hermes kanban show <id>`` now renders a Diagnostics section near
the top with severity markers + suggested actions.
Dashboard
---------
* Card badge is severity-coloured (⚠ amber warning, !! orange error,
!!! red critical) using ``warnings.highest_severity``.
* Attention strip above the toolbar counts EVERY task with active
diagnostics (not just hallucinations), severity-coloured, lists
affected tasks with Open buttons when expanded.
* Drawer's old ``RecoverySection`` replaced with generic
``DiagnosticsSection`` rendering a card per active diagnostic:
title + detail + structured data (task-id chips when payload keys
look like id lists) + action buttons. Reassign profile picker is
inline per-diagnostic. Clipboard fallback uses ``.catch()`` for
environments where writeText rejects.
* Three-rung severity palette; amber for warning, orange for error,
red for critical. Uses CSS variables so theming is straightforward.
Tests
-----
* NEW ``tests/hermes_cli/test_kanban_diagnostics.py`` — 14 unit tests
covering each rule's positive/negative/threshold paths, severity
sorting, broken-rule isolation, and sqlite3.Row integration.
* Dashboard plugin tests extended: ``/diagnostics`` endpoint (empty,
populated, severity-filtered), ``/board`` exposes both diagnostic
list and compact summary with ``highest_severity``.
* Existing hallucination-specific test (``test_board_surfaces_
warnings_field_for_hallucinated_completions``) updated to reflect
the new contract: warning summary keys by diagnostic kind
(``hallucinated_cards``) not event kind.
379 kanban-suite tests pass (+16 net from this PR).
Live verification
-----------------
Seeded all 5 diagnostic kinds + one clean + one plain-running task
(7 total) into an isolated HERMES_HOME, spun up the dashboard, and
verified:
* Attention strip: shows ``!! 5 tasks need attention`` in the
error-severity orange; Show expands to a list of 5 rows ordered
critical > error > warning.
* Card badges: error tasks render ``!!`` orange, warning tasks
render ``⚠`` amber, clean and plain-running tasks render no badge.
* Each of the 5 rules opens a correctly-coloured, correctly-styled
diagnostic card in the drawer with its specific suggested action.
* Live reassign from a diagnostic card flipped
``broken-ml-worker → alice`` and the drawer refreshed with the
new assignee + the same diagnostic still firing (correct:
spawn_failures counter hasn't reset yet).
* CLI ``hermes kanban diagnostics`` prints all 5 in severity order;
``--severity error`` narrows to 3; ``kanban show <id>`` includes
the Diagnostics block at the top with suggested action hint.
Migration note
--------------
The old ``warnings`` shape (``{count, kinds, latest_at}``) is
preserved on the API but ``kinds`` now keys by diagnostic kind
(``hallucinated_cards``) instead of event kind
(``completion_blocked_hallucination``). ``highest_severity`` is a
new required field. The dashboard was the only consumer and has
been updated in the same commit; external API consumers of the
``warnings`` field will need to update their kind-match logic.
* feat(kanban/diagnostics): lead titles with the actual error text
The generic 'Worker crashed N runs in a row' / 'Worker failed to spawn
N times' titles buried the actual cause in the data section. Operators
had to open logs or expand the diagnostic to see WHY the worker is
stuck — rate-limit vs insufficient quota vs bad auth vs context
overflow vs network blip all looked identical at a glance.
New titles:
Agent crashed 3x: openai: 429 Too Many Requests - rate limit reached
Agent crashed 3x: anthropic: 402 insufficient_quota - credit balance
Agent crashed 3x: provider auth error: 401 Unauthorized
Agent spawn failed 4x: insufficient_quota: You exceeded your current
Detail keeps the full error snippet (capped at 500 chars + ellipsis
for tracebacks). Title takes the first line capped at 160 chars.
Fallback title if no error recorded stays honest ('no error recorded').
Tests: 4 new cases covering 429/billing/spawn/truncation. 383 total
pass (+4).
Live-verified on dashboard with 6 seeded scenarios
(rate-limit, billing, auth, context, network, spawn-billing) —
each card title leads with the actionable error text.
2026-05-05 13:32:42 -07:00
|
|
|
rows = conn.execute(
|
|
|
|
|
"SELECT * FROM tasks WHERE status != 'archived'",
|
|
|
|
|
).fetchall()
|
|
|
|
|
|
|
|
|
|
if not rows:
|
|
|
|
|
return {}
|
|
|
|
|
|
|
|
|
|
# Index events + runs by task id. For very large boards this will
|
|
|
|
|
# slurp a lot — acceptable on the dashboard's typical working set
|
|
|
|
|
# (hundreds of tasks), but we can add pagination / filtering later
|
|
|
|
|
# if profiling shows it's a hotspot.
|
|
|
|
|
row_ids = [r["id"] for r in rows]
|
|
|
|
|
placeholders = ",".join(["?"] * len(row_ids))
|
|
|
|
|
events_by_task: dict[str, list] = {tid: [] for tid in row_ids}
|
|
|
|
|
for ev_row in conn.execute(
|
|
|
|
|
f"SELECT * FROM task_events WHERE task_id IN ({placeholders}) ORDER BY id",
|
|
|
|
|
tuple(row_ids),
|
|
|
|
|
).fetchall():
|
|
|
|
|
events_by_task.setdefault(ev_row["task_id"], []).append(ev_row)
|
|
|
|
|
runs_by_task: dict[str, list] = {tid: [] for tid in row_ids}
|
|
|
|
|
for run_row in conn.execute(
|
|
|
|
|
f"SELECT * FROM task_runs WHERE task_id IN ({placeholders}) ORDER BY id",
|
|
|
|
|
tuple(row_ids),
|
|
|
|
|
).fetchall():
|
|
|
|
|
runs_by_task.setdefault(run_row["task_id"], []).append(run_row)
|
|
|
|
|
|
|
|
|
|
out: dict[str, list[dict]] = {}
|
|
|
|
|
for r in rows:
|
|
|
|
|
tid = r["id"]
|
|
|
|
|
diags = kd.compute_task_diagnostics(
|
|
|
|
|
r,
|
|
|
|
|
events_by_task.get(tid, []),
|
|
|
|
|
runs_by_task.get(tid, []),
|
2026-05-14 17:07:57 +08:00
|
|
|
config=diag_config,
|
feat(kanban): hallucination gate + recovery UX for worker-created-card claims (#20232)
Workers completing a kanban task can now claim the ids of cards they
created via an optional ``created_cards`` field on ``kanban_complete``.
The kernel verifies each id exists and was created by the completing
worker's profile; any phantom id blocks the completion with a
``HallucinatedCardsError`` and records a
``completion_blocked_hallucination`` event on the task so the rejected
attempt is auditable. Successful completions also get a non-blocking
prose-scan pass over their ``summary`` + ``result`` that emits a
``suspected_hallucinated_references`` event for any ``t_<hex>``
reference that doesn't resolve.
Closes #20017.
Recovery UX (kernel + CLI + dashboard)
--------------------------------------
A structural gate alone isn't enough — operators also need to see and
act on stuck workers, especially when a profile's model is the root
cause. This PR ships the full loop:
* ``kanban_db.reclaim_task(task_id)`` — operator-driven reclaim that
releases an active worker claim immediately (unlike
``release_stale_claims`` which only acts after claim_expires has
passed). Emits a ``reclaimed`` event with ``manual: True`` payload.
* ``kanban_db.reassign_task(task_id, profile, reclaim_first=...)`` —
switch a task to a different profile, optionally reclaiming a stuck
running worker in the same call.
* ``hermes kanban reclaim <id> [--reason ...]`` and
``hermes kanban reassign <id> <profile> [--reclaim] [--reason ...]``
CLI subcommands wired through to the same helpers.
* ``POST /api/plugins/kanban/tasks/{id}/reclaim`` and
``POST /api/plugins/kanban/tasks/{id}/reassign`` endpoints on the
dashboard plugin.
Dashboard surfacing
-------------------
* ⚠ **warning badge** on cards with active hallucination events.
* **attention strip** at the top of the board listing all flagged
tasks; dismissible per session.
* **events callout** in the task drawer — hallucination events render
with a red left border, amber icon, and phantom ids as styled chips.
* **recovery section** in the task drawer with three actions: Reclaim,
Reassign (with profile picker + reclaim-first checkbox), and a
copy-to-clipboard hint for ``hermes -p <profile> model`` since
profile config lives on disk and can't be edited from the browser.
Auto-opens when the task has warnings, collapsed otherwise.
Keyed by task id so state doesn't leak between drawers.
Active-vs-stale rule: warnings clear when a clean ``completed`` or
``edited`` event supersedes the hallucination, so recovery is never
permanently stigmatising — the audit events persist for debugging but
the badge goes away once the worker succeeds.
Skill updates
-------------
* ``skills/devops/kanban-worker/SKILL.md`` documents the
``created_cards`` contract with good/bad examples.
* ``skills/devops/kanban-orchestrator/SKILL.md`` gains a "Recovering
stuck workers" section with the three actions and when to use each.
Tests
-----
* Kernel gate: verified-cards manifest, phantom rejection + audit
event, cross-worker rejection, prose scan positive + negative.
* Recovery helpers: reclaim on running task, reclaim on non-running
returns False, reassign refuses running without reclaim_first,
reassign with reclaim_first succeeds on running.
* API endpoints: warnings field present on /board and /tasks/:id,
warnings cleared after clean completion, reclaim 200 + 409 paths,
reassign 200 + 409 + reclaim_first paths.
* CLI smoke: reclaim + reassign subcommands.
Live-verified end-to-end on a dashboard with seeded scenarios:
attention strip renders, badges land on the right cards, drawer
callout shows phantom chips, Reclaim on a running task flips status to
ready + emits manual reclaimed event + refreshes the drawer,
Reassign swaps the assignee and triggers board refresh.
359/359 kanban-suite tests pass
(test_kanban_{db,cli,boards,core_functionality} + dashboard + tools).
2026-05-05 08:06:55 -07:00
|
|
|
)
|
feat(kanban): generic diagnostics engine for task distress signals (#20332)
* feat(kanban): generic diagnostics engine for task distress signals
Replaces the hallucination-specific ``warnings`` / ``RecoverySection``
surface (shipped in PR #20232) with a reusable diagnostic-rule engine
that covers five distress kinds in v1 and can be extended without
touching UI code. The "something's wrong with this task" signal is
no longer limited to phantom card ids.
Closes the follow-up from #20232 discussion.
New module
----------
``hermes_cli/kanban_diagnostics.py`` — stateless, no-side-effect rule
engine. Each rule is a pure function of
``(task, events, runs, now, config) -> list[Diagnostic]``. Registry
is a simple list; adding a new distress kind is one function + one
import, no UI or API changes required.
v1 rule set
-----------
* ``hallucinated_cards`` (error) — folds the existing
``completion_blocked_hallucination`` event into the new surface.
* ``prose_phantom_refs`` (warning) — folds
``suspected_hallucinated_references``.
* ``repeated_spawn_failures`` (error → critical at 2x threshold) —
fires when ``tasks.spawn_failures >= 3``; suggests
``hermes -p <profile> doctor`` / ``auth``.
* ``repeated_crashes`` (error → critical) — fires after N consecutive
``crashed`` run outcomes with no successful completion between;
suggests ``hermes kanban log <id>``.
* ``stuck_in_blocked`` (warning) — fires after 24h in ``blocked``
state with no comments / unblock attempts; suggests commenting.
Every diagnostic carries structured ``actions`` (reclaim, reassign,
unblock, cli_hint, comment, open_docs) that render consistently in
both CLI and dashboard. Suggested actions are highlighted; generic
recovery actions (reclaim / reassign) are available on every kind as
fallbacks.
Diagnostics auto-clear when the underlying failure resolves — a
clean ``completed``/``edited`` event drops hallucination diagnostics,
a successful run drops crash diagnostics, a comment drops
stuck-blocked diagnostics. Audit events persist; the badge goes away.
API
---
``plugin_api.py``:
* ``/board`` now attaches ``diagnostics`` (full list) and
``warnings`` (compact summary with ``highest_severity``) per task.
* ``/tasks/{id}`` attaches diagnostics so the drawer's Diagnostics
section auto-opens on flagged tasks.
* NEW ``/diagnostics`` endpoint — fleet-wide listing, filterable by
severity, sorted critical-first.
CLI
---
* NEW ``hermes kanban diagnostics [--severity X] [--task id]
[--json]`` — fleet view or single-task view, matches dashboard rule
output so CLI users see the same picture.
* ``hermes kanban show <id>`` now renders a Diagnostics section near
the top with severity markers + suggested actions.
Dashboard
---------
* Card badge is severity-coloured (⚠ amber warning, !! orange error,
!!! red critical) using ``warnings.highest_severity``.
* Attention strip above the toolbar counts EVERY task with active
diagnostics (not just hallucinations), severity-coloured, lists
affected tasks with Open buttons when expanded.
* Drawer's old ``RecoverySection`` replaced with generic
``DiagnosticsSection`` rendering a card per active diagnostic:
title + detail + structured data (task-id chips when payload keys
look like id lists) + action buttons. Reassign profile picker is
inline per-diagnostic. Clipboard fallback uses ``.catch()`` for
environments where writeText rejects.
* Three-rung severity palette; amber for warning, orange for error,
red for critical. Uses CSS variables so theming is straightforward.
Tests
-----
* NEW ``tests/hermes_cli/test_kanban_diagnostics.py`` — 14 unit tests
covering each rule's positive/negative/threshold paths, severity
sorting, broken-rule isolation, and sqlite3.Row integration.
* Dashboard plugin tests extended: ``/diagnostics`` endpoint (empty,
populated, severity-filtered), ``/board`` exposes both diagnostic
list and compact summary with ``highest_severity``.
* Existing hallucination-specific test (``test_board_surfaces_
warnings_field_for_hallucinated_completions``) updated to reflect
the new contract: warning summary keys by diagnostic kind
(``hallucinated_cards``) not event kind.
379 kanban-suite tests pass (+16 net from this PR).
Live verification
-----------------
Seeded all 5 diagnostic kinds + one clean + one plain-running task
(7 total) into an isolated HERMES_HOME, spun up the dashboard, and
verified:
* Attention strip: shows ``!! 5 tasks need attention`` in the
error-severity orange; Show expands to a list of 5 rows ordered
critical > error > warning.
* Card badges: error tasks render ``!!`` orange, warning tasks
render ``⚠`` amber, clean and plain-running tasks render no badge.
* Each of the 5 rules opens a correctly-coloured, correctly-styled
diagnostic card in the drawer with its specific suggested action.
* Live reassign from a diagnostic card flipped
``broken-ml-worker → alice`` and the drawer refreshed with the
new assignee + the same diagnostic still firing (correct:
spawn_failures counter hasn't reset yet).
* CLI ``hermes kanban diagnostics`` prints all 5 in severity order;
``--severity error`` narrows to 3; ``kanban show <id>`` includes
the Diagnostics block at the top with suggested action hint.
Migration note
--------------
The old ``warnings`` shape (``{count, kinds, latest_at}``) is
preserved on the API but ``kinds`` now keys by diagnostic kind
(``hallucinated_cards``) instead of event kind
(``completion_blocked_hallucination``). ``highest_severity`` is a
new required field. The dashboard was the only consumer and has
been updated in the same commit; external API consumers of the
``warnings`` field will need to update their kind-match logic.
* feat(kanban/diagnostics): lead titles with the actual error text
The generic 'Worker crashed N runs in a row' / 'Worker failed to spawn
N times' titles buried the actual cause in the data section. Operators
had to open logs or expand the diagnostic to see WHY the worker is
stuck — rate-limit vs insufficient quota vs bad auth vs context
overflow vs network blip all looked identical at a glance.
New titles:
Agent crashed 3x: openai: 429 Too Many Requests - rate limit reached
Agent crashed 3x: anthropic: 402 insufficient_quota - credit balance
Agent crashed 3x: provider auth error: 401 Unauthorized
Agent spawn failed 4x: insufficient_quota: You exceeded your current
Detail keeps the full error snippet (capped at 500 chars + ellipsis
for tracebacks). Title takes the first line capped at 160 chars.
Fallback title if no error recorded stays honest ('no error recorded').
Tests: 4 new cases covering 429/billing/spawn/truncation. 383 total
pass (+4).
Live-verified on dashboard with 6 seeded scenarios
(rate-limit, billing, auth, context, network, spawn-billing) —
each card title leads with the actionable error text.
2026-05-05 13:32:42 -07:00
|
|
|
if diags:
|
|
|
|
|
out[tid] = [d.to_dict() for d in diags]
|
feat(kanban): hallucination gate + recovery UX for worker-created-card claims (#20232)
Workers completing a kanban task can now claim the ids of cards they
created via an optional ``created_cards`` field on ``kanban_complete``.
The kernel verifies each id exists and was created by the completing
worker's profile; any phantom id blocks the completion with a
``HallucinatedCardsError`` and records a
``completion_blocked_hallucination`` event on the task so the rejected
attempt is auditable. Successful completions also get a non-blocking
prose-scan pass over their ``summary`` + ``result`` that emits a
``suspected_hallucinated_references`` event for any ``t_<hex>``
reference that doesn't resolve.
Closes #20017.
Recovery UX (kernel + CLI + dashboard)
--------------------------------------
A structural gate alone isn't enough — operators also need to see and
act on stuck workers, especially when a profile's model is the root
cause. This PR ships the full loop:
* ``kanban_db.reclaim_task(task_id)`` — operator-driven reclaim that
releases an active worker claim immediately (unlike
``release_stale_claims`` which only acts after claim_expires has
passed). Emits a ``reclaimed`` event with ``manual: True`` payload.
* ``kanban_db.reassign_task(task_id, profile, reclaim_first=...)`` —
switch a task to a different profile, optionally reclaiming a stuck
running worker in the same call.
* ``hermes kanban reclaim <id> [--reason ...]`` and
``hermes kanban reassign <id> <profile> [--reclaim] [--reason ...]``
CLI subcommands wired through to the same helpers.
* ``POST /api/plugins/kanban/tasks/{id}/reclaim`` and
``POST /api/plugins/kanban/tasks/{id}/reassign`` endpoints on the
dashboard plugin.
Dashboard surfacing
-------------------
* ⚠ **warning badge** on cards with active hallucination events.
* **attention strip** at the top of the board listing all flagged
tasks; dismissible per session.
* **events callout** in the task drawer — hallucination events render
with a red left border, amber icon, and phantom ids as styled chips.
* **recovery section** in the task drawer with three actions: Reclaim,
Reassign (with profile picker + reclaim-first checkbox), and a
copy-to-clipboard hint for ``hermes -p <profile> model`` since
profile config lives on disk and can't be edited from the browser.
Auto-opens when the task has warnings, collapsed otherwise.
Keyed by task id so state doesn't leak between drawers.
Active-vs-stale rule: warnings clear when a clean ``completed`` or
``edited`` event supersedes the hallucination, so recovery is never
permanently stigmatising — the audit events persist for debugging but
the badge goes away once the worker succeeds.
Skill updates
-------------
* ``skills/devops/kanban-worker/SKILL.md`` documents the
``created_cards`` contract with good/bad examples.
* ``skills/devops/kanban-orchestrator/SKILL.md`` gains a "Recovering
stuck workers" section with the three actions and when to use each.
Tests
-----
* Kernel gate: verified-cards manifest, phantom rejection + audit
event, cross-worker rejection, prose scan positive + negative.
* Recovery helpers: reclaim on running task, reclaim on non-running
returns False, reassign refuses running without reclaim_first,
reassign with reclaim_first succeeds on running.
* API endpoints: warnings field present on /board and /tasks/:id,
warnings cleared after clean completion, reclaim 200 + 409 paths,
reassign 200 + 409 + reclaim_first paths.
* CLI smoke: reclaim + reassign subcommands.
Live-verified end-to-end on a dashboard with seeded scenarios:
attention strip renders, badges land on the right cards, drawer
callout shows phantom chips, Reclaim on a running task flips status to
ready + emits manual reclaimed event + refreshes the drawer,
Reassign swaps the assignee and triggers board refresh.
359/359 kanban-suite tests pass
(test_kanban_{db,cli,boards,core_functionality} + dashboard + tools).
2026-05-05 08:06:55 -07:00
|
|
|
return out
|
|
|
|
|
|
|
|
|
|
|
feat(kanban): generic diagnostics engine for task distress signals (#20332)
* feat(kanban): generic diagnostics engine for task distress signals
Replaces the hallucination-specific ``warnings`` / ``RecoverySection``
surface (shipped in PR #20232) with a reusable diagnostic-rule engine
that covers five distress kinds in v1 and can be extended without
touching UI code. The "something's wrong with this task" signal is
no longer limited to phantom card ids.
Closes the follow-up from #20232 discussion.
New module
----------
``hermes_cli/kanban_diagnostics.py`` — stateless, no-side-effect rule
engine. Each rule is a pure function of
``(task, events, runs, now, config) -> list[Diagnostic]``. Registry
is a simple list; adding a new distress kind is one function + one
import, no UI or API changes required.
v1 rule set
-----------
* ``hallucinated_cards`` (error) — folds the existing
``completion_blocked_hallucination`` event into the new surface.
* ``prose_phantom_refs`` (warning) — folds
``suspected_hallucinated_references``.
* ``repeated_spawn_failures`` (error → critical at 2x threshold) —
fires when ``tasks.spawn_failures >= 3``; suggests
``hermes -p <profile> doctor`` / ``auth``.
* ``repeated_crashes`` (error → critical) — fires after N consecutive
``crashed`` run outcomes with no successful completion between;
suggests ``hermes kanban log <id>``.
* ``stuck_in_blocked`` (warning) — fires after 24h in ``blocked``
state with no comments / unblock attempts; suggests commenting.
Every diagnostic carries structured ``actions`` (reclaim, reassign,
unblock, cli_hint, comment, open_docs) that render consistently in
both CLI and dashboard. Suggested actions are highlighted; generic
recovery actions (reclaim / reassign) are available on every kind as
fallbacks.
Diagnostics auto-clear when the underlying failure resolves — a
clean ``completed``/``edited`` event drops hallucination diagnostics,
a successful run drops crash diagnostics, a comment drops
stuck-blocked diagnostics. Audit events persist; the badge goes away.
API
---
``plugin_api.py``:
* ``/board`` now attaches ``diagnostics`` (full list) and
``warnings`` (compact summary with ``highest_severity``) per task.
* ``/tasks/{id}`` attaches diagnostics so the drawer's Diagnostics
section auto-opens on flagged tasks.
* NEW ``/diagnostics`` endpoint — fleet-wide listing, filterable by
severity, sorted critical-first.
CLI
---
* NEW ``hermes kanban diagnostics [--severity X] [--task id]
[--json]`` — fleet view or single-task view, matches dashboard rule
output so CLI users see the same picture.
* ``hermes kanban show <id>`` now renders a Diagnostics section near
the top with severity markers + suggested actions.
Dashboard
---------
* Card badge is severity-coloured (⚠ amber warning, !! orange error,
!!! red critical) using ``warnings.highest_severity``.
* Attention strip above the toolbar counts EVERY task with active
diagnostics (not just hallucinations), severity-coloured, lists
affected tasks with Open buttons when expanded.
* Drawer's old ``RecoverySection`` replaced with generic
``DiagnosticsSection`` rendering a card per active diagnostic:
title + detail + structured data (task-id chips when payload keys
look like id lists) + action buttons. Reassign profile picker is
inline per-diagnostic. Clipboard fallback uses ``.catch()`` for
environments where writeText rejects.
* Three-rung severity palette; amber for warning, orange for error,
red for critical. Uses CSS variables so theming is straightforward.
Tests
-----
* NEW ``tests/hermes_cli/test_kanban_diagnostics.py`` — 14 unit tests
covering each rule's positive/negative/threshold paths, severity
sorting, broken-rule isolation, and sqlite3.Row integration.
* Dashboard plugin tests extended: ``/diagnostics`` endpoint (empty,
populated, severity-filtered), ``/board`` exposes both diagnostic
list and compact summary with ``highest_severity``.
* Existing hallucination-specific test (``test_board_surfaces_
warnings_field_for_hallucinated_completions``) updated to reflect
the new contract: warning summary keys by diagnostic kind
(``hallucinated_cards``) not event kind.
379 kanban-suite tests pass (+16 net from this PR).
Live verification
-----------------
Seeded all 5 diagnostic kinds + one clean + one plain-running task
(7 total) into an isolated HERMES_HOME, spun up the dashboard, and
verified:
* Attention strip: shows ``!! 5 tasks need attention`` in the
error-severity orange; Show expands to a list of 5 rows ordered
critical > error > warning.
* Card badges: error tasks render ``!!`` orange, warning tasks
render ``⚠`` amber, clean and plain-running tasks render no badge.
* Each of the 5 rules opens a correctly-coloured, correctly-styled
diagnostic card in the drawer with its specific suggested action.
* Live reassign from a diagnostic card flipped
``broken-ml-worker → alice`` and the drawer refreshed with the
new assignee + the same diagnostic still firing (correct:
spawn_failures counter hasn't reset yet).
* CLI ``hermes kanban diagnostics`` prints all 5 in severity order;
``--severity error`` narrows to 3; ``kanban show <id>`` includes
the Diagnostics block at the top with suggested action hint.
Migration note
--------------
The old ``warnings`` shape (``{count, kinds, latest_at}``) is
preserved on the API but ``kinds`` now keys by diagnostic kind
(``hallucinated_cards``) instead of event kind
(``completion_blocked_hallucination``). ``highest_severity`` is a
new required field. The dashboard was the only consumer and has
been updated in the same commit; external API consumers of the
``warnings`` field will need to update their kind-match logic.
* feat(kanban/diagnostics): lead titles with the actual error text
The generic 'Worker crashed N runs in a row' / 'Worker failed to spawn
N times' titles buried the actual cause in the data section. Operators
had to open logs or expand the diagnostic to see WHY the worker is
stuck — rate-limit vs insufficient quota vs bad auth vs context
overflow vs network blip all looked identical at a glance.
New titles:
Agent crashed 3x: openai: 429 Too Many Requests - rate limit reached
Agent crashed 3x: anthropic: 402 insufficient_quota - credit balance
Agent crashed 3x: provider auth error: 401 Unauthorized
Agent spawn failed 4x: insufficient_quota: You exceeded your current
Detail keeps the full error snippet (capped at 500 chars + ellipsis
for tracebacks). Title takes the first line capped at 160 chars.
Fallback title if no error recorded stays honest ('no error recorded').
Tests: 4 new cases covering 429/billing/spawn/truncation. 383 total
pass (+4).
Live-verified on dashboard with 6 seeded scenarios
(rate-limit, billing, auth, context, network, spawn-billing) —
each card title leads with the actionable error text.
2026-05-05 13:32:42 -07:00
|
|
|
def _warnings_summary_from_diagnostics(
|
|
|
|
|
diagnostics: list[dict],
|
|
|
|
|
) -> Optional[dict]:
|
|
|
|
|
"""Compact summary for cards: {count, highest_severity, kinds,
|
|
|
|
|
latest_at}. Replaces the old hallucination-only ``warnings`` object
|
|
|
|
|
— same shape additions plus ``highest_severity`` so the UI can color
|
|
|
|
|
badges per diagnostic severity.
|
|
|
|
|
|
|
|
|
|
Returns None when ``diagnostics`` is empty.
|
|
|
|
|
"""
|
|
|
|
|
if not diagnostics:
|
|
|
|
|
return None
|
|
|
|
|
from hermes_cli.kanban_diagnostics import SEVERITY_ORDER
|
|
|
|
|
|
|
|
|
|
kinds: dict[str, int] = {}
|
|
|
|
|
latest = 0
|
|
|
|
|
highest_idx = -1
|
|
|
|
|
highest_sev: Optional[str] = None
|
|
|
|
|
count = 0
|
|
|
|
|
for d in diagnostics:
|
|
|
|
|
kinds[d["kind"]] = kinds.get(d["kind"], 0) + d.get("count", 1)
|
|
|
|
|
count += d.get("count", 1)
|
|
|
|
|
la = d.get("last_seen_at") or 0
|
|
|
|
|
if la > latest:
|
|
|
|
|
latest = la
|
|
|
|
|
sev = d.get("severity")
|
|
|
|
|
if sev in SEVERITY_ORDER:
|
|
|
|
|
idx = SEVERITY_ORDER.index(sev)
|
|
|
|
|
if idx > highest_idx:
|
|
|
|
|
highest_idx = idx
|
|
|
|
|
highest_sev = sev
|
|
|
|
|
return {
|
|
|
|
|
"count": count,
|
|
|
|
|
"kinds": kinds,
|
|
|
|
|
"latest_at": latest,
|
|
|
|
|
"highest_severity": highest_sev,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
def _links_for(conn: sqlite3.Connection, task_id: str) -> dict[str, list[str]]:
|
|
|
|
|
"""Return {'parents': [...], 'children': [...]} for a task."""
|
|
|
|
|
parents = [
|
|
|
|
|
r["parent_id"]
|
|
|
|
|
for r in conn.execute(
|
|
|
|
|
"SELECT parent_id FROM task_links WHERE child_id = ? ORDER BY parent_id",
|
|
|
|
|
(task_id,),
|
|
|
|
|
)
|
|
|
|
|
]
|
|
|
|
|
children = [
|
|
|
|
|
r["child_id"]
|
|
|
|
|
for r in conn.execute(
|
|
|
|
|
"SELECT child_id FROM task_links WHERE parent_id = ? ORDER BY child_id",
|
|
|
|
|
(task_id,),
|
|
|
|
|
)
|
|
|
|
|
]
|
|
|
|
|
return {"parents": parents, "children": children}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# GET /board
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
@router.get("/board")
|
|
|
|
|
def get_board(
|
|
|
|
|
tenant: Optional[str] = Query(None, description="Filter to a single tenant"),
|
|
|
|
|
include_archived: bool = Query(False),
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
board: Optional[str] = Query(None, description="Kanban board slug (omit for current)"),
|
2026-05-18 21:22:26 -07:00
|
|
|
workflow_template_id: Optional[str] = Query(
|
|
|
|
|
None, description="Restrict to tasks using this workflow template id",
|
|
|
|
|
),
|
|
|
|
|
current_step_key: Optional[str] = Query(
|
|
|
|
|
None, description="Restrict to tasks at this workflow step key",
|
|
|
|
|
),
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
):
|
|
|
|
|
"""Return the full board grouped by status column.
|
|
|
|
|
|
|
|
|
|
``_conn()`` auto-initializes ``kanban.db`` on first call so a fresh
|
|
|
|
|
install doesn't surface a "failed to load" error on the plugin tab.
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
|
|
|
|
|
``board`` selects which board to read from. Omitting it falls
|
|
|
|
|
through to the active board (``HERMES_KANBAN_BOARD`` env → on-disk
|
|
|
|
|
``current`` pointer → ``default``).
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
"""
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
try:
|
|
|
|
|
tasks = kanban_db.list_tasks(
|
2026-05-18 21:22:26 -07:00
|
|
|
conn,
|
|
|
|
|
tenant=tenant,
|
|
|
|
|
include_archived=include_archived,
|
|
|
|
|
workflow_template_id=workflow_template_id,
|
|
|
|
|
current_step_key=current_step_key,
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
)
|
|
|
|
|
# Pre-fetch link counts per task (cheap: one query).
|
|
|
|
|
link_counts: dict[str, dict[str, int]] = {}
|
|
|
|
|
for row in conn.execute(
|
|
|
|
|
"SELECT parent_id, child_id FROM task_links"
|
|
|
|
|
).fetchall():
|
|
|
|
|
link_counts.setdefault(row["parent_id"], {"parents": 0, "children": 0})[
|
|
|
|
|
"children"
|
|
|
|
|
] += 1
|
|
|
|
|
link_counts.setdefault(row["child_id"], {"parents": 0, "children": 0})[
|
|
|
|
|
"parents"
|
|
|
|
|
] += 1
|
|
|
|
|
|
|
|
|
|
# Comment + event counts (both cheap aggregates).
|
|
|
|
|
comment_counts: dict[str, int] = {
|
|
|
|
|
r["task_id"]: r["n"]
|
|
|
|
|
for r in conn.execute(
|
|
|
|
|
"SELECT task_id, COUNT(*) AS n FROM task_comments GROUP BY task_id"
|
|
|
|
|
)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
# Progress rollup: for each parent, how many children are done / total.
|
|
|
|
|
# One pass over task_links joined with child status — cheaper than
|
|
|
|
|
# N per-task queries and the plugin uses it to render "N/M".
|
|
|
|
|
progress: dict[str, dict[str, int]] = {}
|
|
|
|
|
for row in conn.execute(
|
|
|
|
|
"SELECT l.parent_id AS pid, t.status AS cstatus "
|
|
|
|
|
"FROM task_links l JOIN tasks t ON t.id = l.child_id"
|
|
|
|
|
).fetchall():
|
|
|
|
|
p = progress.setdefault(row["pid"], {"done": 0, "total": 0})
|
|
|
|
|
p["total"] += 1
|
|
|
|
|
if row["cstatus"] == "done":
|
|
|
|
|
p["done"] += 1
|
|
|
|
|
|
feat(kanban): generic diagnostics engine for task distress signals (#20332)
* feat(kanban): generic diagnostics engine for task distress signals
Replaces the hallucination-specific ``warnings`` / ``RecoverySection``
surface (shipped in PR #20232) with a reusable diagnostic-rule engine
that covers five distress kinds in v1 and can be extended without
touching UI code. The "something's wrong with this task" signal is
no longer limited to phantom card ids.
Closes the follow-up from #20232 discussion.
New module
----------
``hermes_cli/kanban_diagnostics.py`` — stateless, no-side-effect rule
engine. Each rule is a pure function of
``(task, events, runs, now, config) -> list[Diagnostic]``. Registry
is a simple list; adding a new distress kind is one function + one
import, no UI or API changes required.
v1 rule set
-----------
* ``hallucinated_cards`` (error) — folds the existing
``completion_blocked_hallucination`` event into the new surface.
* ``prose_phantom_refs`` (warning) — folds
``suspected_hallucinated_references``.
* ``repeated_spawn_failures`` (error → critical at 2x threshold) —
fires when ``tasks.spawn_failures >= 3``; suggests
``hermes -p <profile> doctor`` / ``auth``.
* ``repeated_crashes`` (error → critical) — fires after N consecutive
``crashed`` run outcomes with no successful completion between;
suggests ``hermes kanban log <id>``.
* ``stuck_in_blocked`` (warning) — fires after 24h in ``blocked``
state with no comments / unblock attempts; suggests commenting.
Every diagnostic carries structured ``actions`` (reclaim, reassign,
unblock, cli_hint, comment, open_docs) that render consistently in
both CLI and dashboard. Suggested actions are highlighted; generic
recovery actions (reclaim / reassign) are available on every kind as
fallbacks.
Diagnostics auto-clear when the underlying failure resolves — a
clean ``completed``/``edited`` event drops hallucination diagnostics,
a successful run drops crash diagnostics, a comment drops
stuck-blocked diagnostics. Audit events persist; the badge goes away.
API
---
``plugin_api.py``:
* ``/board`` now attaches ``diagnostics`` (full list) and
``warnings`` (compact summary with ``highest_severity``) per task.
* ``/tasks/{id}`` attaches diagnostics so the drawer's Diagnostics
section auto-opens on flagged tasks.
* NEW ``/diagnostics`` endpoint — fleet-wide listing, filterable by
severity, sorted critical-first.
CLI
---
* NEW ``hermes kanban diagnostics [--severity X] [--task id]
[--json]`` — fleet view or single-task view, matches dashboard rule
output so CLI users see the same picture.
* ``hermes kanban show <id>`` now renders a Diagnostics section near
the top with severity markers + suggested actions.
Dashboard
---------
* Card badge is severity-coloured (⚠ amber warning, !! orange error,
!!! red critical) using ``warnings.highest_severity``.
* Attention strip above the toolbar counts EVERY task with active
diagnostics (not just hallucinations), severity-coloured, lists
affected tasks with Open buttons when expanded.
* Drawer's old ``RecoverySection`` replaced with generic
``DiagnosticsSection`` rendering a card per active diagnostic:
title + detail + structured data (task-id chips when payload keys
look like id lists) + action buttons. Reassign profile picker is
inline per-diagnostic. Clipboard fallback uses ``.catch()`` for
environments where writeText rejects.
* Three-rung severity palette; amber for warning, orange for error,
red for critical. Uses CSS variables so theming is straightforward.
Tests
-----
* NEW ``tests/hermes_cli/test_kanban_diagnostics.py`` — 14 unit tests
covering each rule's positive/negative/threshold paths, severity
sorting, broken-rule isolation, and sqlite3.Row integration.
* Dashboard plugin tests extended: ``/diagnostics`` endpoint (empty,
populated, severity-filtered), ``/board`` exposes both diagnostic
list and compact summary with ``highest_severity``.
* Existing hallucination-specific test (``test_board_surfaces_
warnings_field_for_hallucinated_completions``) updated to reflect
the new contract: warning summary keys by diagnostic kind
(``hallucinated_cards``) not event kind.
379 kanban-suite tests pass (+16 net from this PR).
Live verification
-----------------
Seeded all 5 diagnostic kinds + one clean + one plain-running task
(7 total) into an isolated HERMES_HOME, spun up the dashboard, and
verified:
* Attention strip: shows ``!! 5 tasks need attention`` in the
error-severity orange; Show expands to a list of 5 rows ordered
critical > error > warning.
* Card badges: error tasks render ``!!`` orange, warning tasks
render ``⚠`` amber, clean and plain-running tasks render no badge.
* Each of the 5 rules opens a correctly-coloured, correctly-styled
diagnostic card in the drawer with its specific suggested action.
* Live reassign from a diagnostic card flipped
``broken-ml-worker → alice`` and the drawer refreshed with the
new assignee + the same diagnostic still firing (correct:
spawn_failures counter hasn't reset yet).
* CLI ``hermes kanban diagnostics`` prints all 5 in severity order;
``--severity error`` narrows to 3; ``kanban show <id>`` includes
the Diagnostics block at the top with suggested action hint.
Migration note
--------------
The old ``warnings`` shape (``{count, kinds, latest_at}``) is
preserved on the API but ``kinds`` now keys by diagnostic kind
(``hallucinated_cards``) instead of event kind
(``completion_blocked_hallucination``). ``highest_severity`` is a
new required field. The dashboard was the only consumer and has
been updated in the same commit; external API consumers of the
``warnings`` field will need to update their kind-match logic.
* feat(kanban/diagnostics): lead titles with the actual error text
The generic 'Worker crashed N runs in a row' / 'Worker failed to spawn
N times' titles buried the actual cause in the data section. Operators
had to open logs or expand the diagnostic to see WHY the worker is
stuck — rate-limit vs insufficient quota vs bad auth vs context
overflow vs network blip all looked identical at a glance.
New titles:
Agent crashed 3x: openai: 429 Too Many Requests - rate limit reached
Agent crashed 3x: anthropic: 402 insufficient_quota - credit balance
Agent crashed 3x: provider auth error: 401 Unauthorized
Agent spawn failed 4x: insufficient_quota: You exceeded your current
Detail keeps the full error snippet (capped at 500 chars + ellipsis
for tracebacks). Title takes the first line capped at 160 chars.
Fallback title if no error recorded stays honest ('no error recorded').
Tests: 4 new cases covering 429/billing/spawn/truncation. 383 total
pass (+4).
Live-verified on dashboard with 6 seeded scenarios
(rate-limit, billing, auth, context, network, spawn-billing) —
each card title leads with the actionable error text.
2026-05-05 13:32:42 -07:00
|
|
|
# Diagnostics rollup for this board — see kanban_diagnostics.
|
|
|
|
|
# We get the full structured list per task AND a compact
|
|
|
|
|
# summary for the card badge (so cards don't carry the detail
|
|
|
|
|
# text; the drawer fetches that via /tasks/:id or /diagnostics).
|
|
|
|
|
diagnostics_per_task = _compute_task_diagnostics(conn, task_ids=None)
|
feat(kanban): hallucination gate + recovery UX for worker-created-card claims (#20232)
Workers completing a kanban task can now claim the ids of cards they
created via an optional ``created_cards`` field on ``kanban_complete``.
The kernel verifies each id exists and was created by the completing
worker's profile; any phantom id blocks the completion with a
``HallucinatedCardsError`` and records a
``completion_blocked_hallucination`` event on the task so the rejected
attempt is auditable. Successful completions also get a non-blocking
prose-scan pass over their ``summary`` + ``result`` that emits a
``suspected_hallucinated_references`` event for any ``t_<hex>``
reference that doesn't resolve.
Closes #20017.
Recovery UX (kernel + CLI + dashboard)
--------------------------------------
A structural gate alone isn't enough — operators also need to see and
act on stuck workers, especially when a profile's model is the root
cause. This PR ships the full loop:
* ``kanban_db.reclaim_task(task_id)`` — operator-driven reclaim that
releases an active worker claim immediately (unlike
``release_stale_claims`` which only acts after claim_expires has
passed). Emits a ``reclaimed`` event with ``manual: True`` payload.
* ``kanban_db.reassign_task(task_id, profile, reclaim_first=...)`` —
switch a task to a different profile, optionally reclaiming a stuck
running worker in the same call.
* ``hermes kanban reclaim <id> [--reason ...]`` and
``hermes kanban reassign <id> <profile> [--reclaim] [--reason ...]``
CLI subcommands wired through to the same helpers.
* ``POST /api/plugins/kanban/tasks/{id}/reclaim`` and
``POST /api/plugins/kanban/tasks/{id}/reassign`` endpoints on the
dashboard plugin.
Dashboard surfacing
-------------------
* ⚠ **warning badge** on cards with active hallucination events.
* **attention strip** at the top of the board listing all flagged
tasks; dismissible per session.
* **events callout** in the task drawer — hallucination events render
with a red left border, amber icon, and phantom ids as styled chips.
* **recovery section** in the task drawer with three actions: Reclaim,
Reassign (with profile picker + reclaim-first checkbox), and a
copy-to-clipboard hint for ``hermes -p <profile> model`` since
profile config lives on disk and can't be edited from the browser.
Auto-opens when the task has warnings, collapsed otherwise.
Keyed by task id so state doesn't leak between drawers.
Active-vs-stale rule: warnings clear when a clean ``completed`` or
``edited`` event supersedes the hallucination, so recovery is never
permanently stigmatising — the audit events persist for debugging but
the badge goes away once the worker succeeds.
Skill updates
-------------
* ``skills/devops/kanban-worker/SKILL.md`` documents the
``created_cards`` contract with good/bad examples.
* ``skills/devops/kanban-orchestrator/SKILL.md`` gains a "Recovering
stuck workers" section with the three actions and when to use each.
Tests
-----
* Kernel gate: verified-cards manifest, phantom rejection + audit
event, cross-worker rejection, prose scan positive + negative.
* Recovery helpers: reclaim on running task, reclaim on non-running
returns False, reassign refuses running without reclaim_first,
reassign with reclaim_first succeeds on running.
* API endpoints: warnings field present on /board and /tasks/:id,
warnings cleared after clean completion, reclaim 200 + 409 paths,
reassign 200 + 409 + reclaim_first paths.
* CLI smoke: reclaim + reassign subcommands.
Live-verified end-to-end on a dashboard with seeded scenarios:
attention strip renders, badges land on the right cards, drawer
callout shows phantom chips, Reclaim on a running task flips status to
ready + emits manual reclaimed event + refreshes the drawer,
Reassign swaps the assignee and triggers board refresh.
359/359 kanban-suite tests pass
(test_kanban_{db,cli,boards,core_functionality} + dashboard + tools).
2026-05-05 08:06:55 -07:00
|
|
|
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
latest_event_id = conn.execute(
|
|
|
|
|
"SELECT COALESCE(MAX(id), 0) AS m FROM task_events"
|
|
|
|
|
).fetchone()["m"]
|
|
|
|
|
|
|
|
|
|
columns: dict[str, list[dict]] = {c: [] for c in BOARD_COLUMNS}
|
|
|
|
|
if include_archived:
|
|
|
|
|
columns["archived"] = []
|
|
|
|
|
|
feat(kanban): surface task_runs.summary on dashboard cards + ``kanban show``
The kanban-worker skill (built into the gateway dispatcher's spawn
prompt) instructs every worker to hand off via
``kanban_complete(summary=..., metadata=...)``. That writes the summary
onto the closing ``task_runs`` row, NOT onto ``tasks.result`` — the
latter is left NULL unless the caller passes ``result=`` explicitly.
Result: a glance at the dashboard or ``hermes kanban show <id>`` shows
a blank "Result:" section even when the worker did real work, which
on 2026-05-05 caused a Mac false-alarm ("Hermes did nothing") on a
task that had a 10-line completion summary on its run.
This patch surfaces the latest non-null run summary as
``latest_summary`` so the worker's actual handoff lands in front of
operators.
* New helpers ``kanban_db.latest_summary(conn, task_id)`` and
``kanban_db.latest_summaries(conn, task_ids)``. The batch variant
uses a single window-function SELECT so the dashboard board endpoint
doesn't pay an N+1 cost on multi-hundred-task boards.
* CLI ``hermes kanban show <id>`` prints a "Latest summary:" block
when ``tasks.result`` is empty but a run has produced a summary
(the existing "Result:" section still wins when populated, so the
back-compat path for hand-edited results is untouched). JSON output
gains a top-level ``latest_summary`` field.
* Dashboard ``/board`` and ``/tasks/{id}`` now include a
``latest_summary`` field on every task. Cards on /board carry a
200-character preview (cheap to render, plenty for "what did this
worker do?" at a glance); the drawer/detail endpoint returns the
full summary.
* Five new tests cover: empty-runs case, post-complete surface,
newest-of-multiple selection, empty-string skip, batch with
missing tasks + empty input.
Smoke-tested locally against the live profile DB on the three
acceptance-criterion targets (t_f08fef91 cron-hygiene-audit,
t_007b7f1c EMA-analysis, t_05746fa4 self-assessment) — all three now
return their populated summaries via both ``latest_summary`` and
``latest_summaries``.
Test plan: 255/255 kanban tests pass + 91/91 dashboard plugin tests
pass. No regression on tasks where ``tasks.result`` is explicitly
populated (the existing "Result:" branch is preserved).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-05 14:14:25 +00:00
|
|
|
# Batch-fetch the latest non-null run summary per task in one
|
|
|
|
|
# window-function query (avoids N+1 ``latest_summary`` calls
|
|
|
|
|
# for boards with hundreds of tasks). Truncated to a card-size
|
|
|
|
|
# preview here — the full text is available via /tasks/:id.
|
|
|
|
|
summary_map = kanban_db.latest_summaries(conn, [t.id for t in tasks])
|
|
|
|
|
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
for t in tasks:
|
feat(kanban): surface task_runs.summary on dashboard cards + ``kanban show``
The kanban-worker skill (built into the gateway dispatcher's spawn
prompt) instructs every worker to hand off via
``kanban_complete(summary=..., metadata=...)``. That writes the summary
onto the closing ``task_runs`` row, NOT onto ``tasks.result`` — the
latter is left NULL unless the caller passes ``result=`` explicitly.
Result: a glance at the dashboard or ``hermes kanban show <id>`` shows
a blank "Result:" section even when the worker did real work, which
on 2026-05-05 caused a Mac false-alarm ("Hermes did nothing") on a
task that had a 10-line completion summary on its run.
This patch surfaces the latest non-null run summary as
``latest_summary`` so the worker's actual handoff lands in front of
operators.
* New helpers ``kanban_db.latest_summary(conn, task_id)`` and
``kanban_db.latest_summaries(conn, task_ids)``. The batch variant
uses a single window-function SELECT so the dashboard board endpoint
doesn't pay an N+1 cost on multi-hundred-task boards.
* CLI ``hermes kanban show <id>`` prints a "Latest summary:" block
when ``tasks.result`` is empty but a run has produced a summary
(the existing "Result:" section still wins when populated, so the
back-compat path for hand-edited results is untouched). JSON output
gains a top-level ``latest_summary`` field.
* Dashboard ``/board`` and ``/tasks/{id}`` now include a
``latest_summary`` field on every task. Cards on /board carry a
200-character preview (cheap to render, plenty for "what did this
worker do?" at a glance); the drawer/detail endpoint returns the
full summary.
* Five new tests cover: empty-runs case, post-complete surface,
newest-of-multiple selection, empty-string skip, batch with
missing tasks + empty input.
Smoke-tested locally against the live profile DB on the three
acceptance-criterion targets (t_f08fef91 cron-hygiene-audit,
t_007b7f1c EMA-analysis, t_05746fa4 self-assessment) — all three now
return their populated summaries via both ``latest_summary`` and
``latest_summaries``.
Test plan: 255/255 kanban tests pass + 91/91 dashboard plugin tests
pass. No regression on tasks where ``tasks.result`` is explicitly
populated (the existing "Result:" branch is preserved).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-05 14:14:25 +00:00
|
|
|
full = summary_map.get(t.id)
|
|
|
|
|
preview = (
|
|
|
|
|
full[:_CARD_SUMMARY_PREVIEW_CHARS] if full else None
|
|
|
|
|
)
|
|
|
|
|
d = _task_dict(t, latest_summary=preview)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
d["link_counts"] = link_counts.get(t.id, {"parents": 0, "children": 0})
|
|
|
|
|
d["comment_count"] = comment_counts.get(t.id, 0)
|
|
|
|
|
d["progress"] = progress.get(t.id) # None when the task has no children
|
feat(kanban): generic diagnostics engine for task distress signals (#20332)
* feat(kanban): generic diagnostics engine for task distress signals
Replaces the hallucination-specific ``warnings`` / ``RecoverySection``
surface (shipped in PR #20232) with a reusable diagnostic-rule engine
that covers five distress kinds in v1 and can be extended without
touching UI code. The "something's wrong with this task" signal is
no longer limited to phantom card ids.
Closes the follow-up from #20232 discussion.
New module
----------
``hermes_cli/kanban_diagnostics.py`` — stateless, no-side-effect rule
engine. Each rule is a pure function of
``(task, events, runs, now, config) -> list[Diagnostic]``. Registry
is a simple list; adding a new distress kind is one function + one
import, no UI or API changes required.
v1 rule set
-----------
* ``hallucinated_cards`` (error) — folds the existing
``completion_blocked_hallucination`` event into the new surface.
* ``prose_phantom_refs`` (warning) — folds
``suspected_hallucinated_references``.
* ``repeated_spawn_failures`` (error → critical at 2x threshold) —
fires when ``tasks.spawn_failures >= 3``; suggests
``hermes -p <profile> doctor`` / ``auth``.
* ``repeated_crashes`` (error → critical) — fires after N consecutive
``crashed`` run outcomes with no successful completion between;
suggests ``hermes kanban log <id>``.
* ``stuck_in_blocked`` (warning) — fires after 24h in ``blocked``
state with no comments / unblock attempts; suggests commenting.
Every diagnostic carries structured ``actions`` (reclaim, reassign,
unblock, cli_hint, comment, open_docs) that render consistently in
both CLI and dashboard. Suggested actions are highlighted; generic
recovery actions (reclaim / reassign) are available on every kind as
fallbacks.
Diagnostics auto-clear when the underlying failure resolves — a
clean ``completed``/``edited`` event drops hallucination diagnostics,
a successful run drops crash diagnostics, a comment drops
stuck-blocked diagnostics. Audit events persist; the badge goes away.
API
---
``plugin_api.py``:
* ``/board`` now attaches ``diagnostics`` (full list) and
``warnings`` (compact summary with ``highest_severity``) per task.
* ``/tasks/{id}`` attaches diagnostics so the drawer's Diagnostics
section auto-opens on flagged tasks.
* NEW ``/diagnostics`` endpoint — fleet-wide listing, filterable by
severity, sorted critical-first.
CLI
---
* NEW ``hermes kanban diagnostics [--severity X] [--task id]
[--json]`` — fleet view or single-task view, matches dashboard rule
output so CLI users see the same picture.
* ``hermes kanban show <id>`` now renders a Diagnostics section near
the top with severity markers + suggested actions.
Dashboard
---------
* Card badge is severity-coloured (⚠ amber warning, !! orange error,
!!! red critical) using ``warnings.highest_severity``.
* Attention strip above the toolbar counts EVERY task with active
diagnostics (not just hallucinations), severity-coloured, lists
affected tasks with Open buttons when expanded.
* Drawer's old ``RecoverySection`` replaced with generic
``DiagnosticsSection`` rendering a card per active diagnostic:
title + detail + structured data (task-id chips when payload keys
look like id lists) + action buttons. Reassign profile picker is
inline per-diagnostic. Clipboard fallback uses ``.catch()`` for
environments where writeText rejects.
* Three-rung severity palette; amber for warning, orange for error,
red for critical. Uses CSS variables so theming is straightforward.
Tests
-----
* NEW ``tests/hermes_cli/test_kanban_diagnostics.py`` — 14 unit tests
covering each rule's positive/negative/threshold paths, severity
sorting, broken-rule isolation, and sqlite3.Row integration.
* Dashboard plugin tests extended: ``/diagnostics`` endpoint (empty,
populated, severity-filtered), ``/board`` exposes both diagnostic
list and compact summary with ``highest_severity``.
* Existing hallucination-specific test (``test_board_surfaces_
warnings_field_for_hallucinated_completions``) updated to reflect
the new contract: warning summary keys by diagnostic kind
(``hallucinated_cards``) not event kind.
379 kanban-suite tests pass (+16 net from this PR).
Live verification
-----------------
Seeded all 5 diagnostic kinds + one clean + one plain-running task
(7 total) into an isolated HERMES_HOME, spun up the dashboard, and
verified:
* Attention strip: shows ``!! 5 tasks need attention`` in the
error-severity orange; Show expands to a list of 5 rows ordered
critical > error > warning.
* Card badges: error tasks render ``!!`` orange, warning tasks
render ``⚠`` amber, clean and plain-running tasks render no badge.
* Each of the 5 rules opens a correctly-coloured, correctly-styled
diagnostic card in the drawer with its specific suggested action.
* Live reassign from a diagnostic card flipped
``broken-ml-worker → alice`` and the drawer refreshed with the
new assignee + the same diagnostic still firing (correct:
spawn_failures counter hasn't reset yet).
* CLI ``hermes kanban diagnostics`` prints all 5 in severity order;
``--severity error`` narrows to 3; ``kanban show <id>`` includes
the Diagnostics block at the top with suggested action hint.
Migration note
--------------
The old ``warnings`` shape (``{count, kinds, latest_at}``) is
preserved on the API but ``kinds`` now keys by diagnostic kind
(``hallucinated_cards``) instead of event kind
(``completion_blocked_hallucination``). ``highest_severity`` is a
new required field. The dashboard was the only consumer and has
been updated in the same commit; external API consumers of the
``warnings`` field will need to update their kind-match logic.
* feat(kanban/diagnostics): lead titles with the actual error text
The generic 'Worker crashed N runs in a row' / 'Worker failed to spawn
N times' titles buried the actual cause in the data section. Operators
had to open logs or expand the diagnostic to see WHY the worker is
stuck — rate-limit vs insufficient quota vs bad auth vs context
overflow vs network blip all looked identical at a glance.
New titles:
Agent crashed 3x: openai: 429 Too Many Requests - rate limit reached
Agent crashed 3x: anthropic: 402 insufficient_quota - credit balance
Agent crashed 3x: provider auth error: 401 Unauthorized
Agent spawn failed 4x: insufficient_quota: You exceeded your current
Detail keeps the full error snippet (capped at 500 chars + ellipsis
for tracebacks). Title takes the first line capped at 160 chars.
Fallback title if no error recorded stays honest ('no error recorded').
Tests: 4 new cases covering 429/billing/spawn/truncation. 383 total
pass (+4).
Live-verified on dashboard with 6 seeded scenarios
(rate-limit, billing, auth, context, network, spawn-billing) —
each card title leads with the actionable error text.
2026-05-05 13:32:42 -07:00
|
|
|
diags = diagnostics_per_task.get(t.id)
|
|
|
|
|
if diags:
|
|
|
|
|
# Full list goes into the payload so the drawer can render
|
|
|
|
|
# without a second round-trip. The board-level badge only
|
|
|
|
|
# needs the summary.
|
|
|
|
|
d["diagnostics"] = diags
|
|
|
|
|
d["warnings"] = _warnings_summary_from_diagnostics(diags)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
col = t.status if t.status in columns else "todo"
|
|
|
|
|
columns[col].append(d)
|
|
|
|
|
|
|
|
|
|
# Stable per-column ordering already applied by list_tasks
|
|
|
|
|
# (priority DESC, created_at ASC), keep as-is.
|
|
|
|
|
|
|
|
|
|
# List of known tenants for the UI filter dropdown.
|
|
|
|
|
tenants = [
|
|
|
|
|
r["tenant"]
|
|
|
|
|
for r in conn.execute(
|
|
|
|
|
"SELECT DISTINCT tenant FROM tasks WHERE tenant IS NOT NULL ORDER BY tenant"
|
|
|
|
|
)
|
|
|
|
|
]
|
|
|
|
|
# List of distinct assignees for the lane-by-profile sub-grouping.
|
|
|
|
|
assignees = [
|
|
|
|
|
r["assignee"]
|
|
|
|
|
for r in conn.execute(
|
|
|
|
|
"SELECT DISTINCT assignee FROM tasks WHERE assignee IS NOT NULL "
|
|
|
|
|
"AND status != 'archived' ORDER BY assignee"
|
|
|
|
|
)
|
|
|
|
|
]
|
|
|
|
|
|
|
|
|
|
return {
|
|
|
|
|
"columns": [
|
|
|
|
|
{"name": name, "tasks": columns[name]} for name in columns.keys()
|
|
|
|
|
],
|
|
|
|
|
"tenants": tenants,
|
|
|
|
|
"assignees": assignees,
|
|
|
|
|
"latest_event_id": int(latest_event_id),
|
|
|
|
|
"now": int(time.time()),
|
|
|
|
|
}
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# GET /tasks/:id
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
@router.get("/tasks/{task_id}")
|
2026-05-18 21:22:26 -07:00
|
|
|
def get_task(
|
|
|
|
|
task_id: str,
|
|
|
|
|
board: Optional[str] = Query(None),
|
|
|
|
|
run_state_type: Optional[str] = Query(
|
|
|
|
|
None, description="With run_state_name: filter runs by column 'status' or 'outcome'",
|
|
|
|
|
),
|
|
|
|
|
run_state_name: Optional[str] = Query(
|
|
|
|
|
None, description="With run_state_type: exact value for that run column",
|
|
|
|
|
),
|
|
|
|
|
):
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
try:
|
2026-05-18 21:22:26 -07:00
|
|
|
if (run_state_type is None) ^ (run_state_name is None):
|
|
|
|
|
raise HTTPException(
|
|
|
|
|
status_code=400,
|
|
|
|
|
detail="run_state_type and run_state_name must be passed together or omitted",
|
|
|
|
|
)
|
|
|
|
|
if run_state_type is not None and run_state_type not in ("status", "outcome"):
|
|
|
|
|
raise HTTPException(
|
|
|
|
|
status_code=400,
|
|
|
|
|
detail="run_state_type must be 'status' or 'outcome'",
|
|
|
|
|
)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
task = kanban_db.get_task(conn, task_id)
|
|
|
|
|
if task is None:
|
|
|
|
|
raise HTTPException(status_code=404, detail=f"task {task_id} not found")
|
feat(kanban): surface task_runs.summary on dashboard cards + ``kanban show``
The kanban-worker skill (built into the gateway dispatcher's spawn
prompt) instructs every worker to hand off via
``kanban_complete(summary=..., metadata=...)``. That writes the summary
onto the closing ``task_runs`` row, NOT onto ``tasks.result`` — the
latter is left NULL unless the caller passes ``result=`` explicitly.
Result: a glance at the dashboard or ``hermes kanban show <id>`` shows
a blank "Result:" section even when the worker did real work, which
on 2026-05-05 caused a Mac false-alarm ("Hermes did nothing") on a
task that had a 10-line completion summary on its run.
This patch surfaces the latest non-null run summary as
``latest_summary`` so the worker's actual handoff lands in front of
operators.
* New helpers ``kanban_db.latest_summary(conn, task_id)`` and
``kanban_db.latest_summaries(conn, task_ids)``. The batch variant
uses a single window-function SELECT so the dashboard board endpoint
doesn't pay an N+1 cost on multi-hundred-task boards.
* CLI ``hermes kanban show <id>`` prints a "Latest summary:" block
when ``tasks.result`` is empty but a run has produced a summary
(the existing "Result:" section still wins when populated, so the
back-compat path for hand-edited results is untouched). JSON output
gains a top-level ``latest_summary`` field.
* Dashboard ``/board`` and ``/tasks/{id}`` now include a
``latest_summary`` field on every task. Cards on /board carry a
200-character preview (cheap to render, plenty for "what did this
worker do?" at a glance); the drawer/detail endpoint returns the
full summary.
* Five new tests cover: empty-runs case, post-complete surface,
newest-of-multiple selection, empty-string skip, batch with
missing tasks + empty input.
Smoke-tested locally against the live profile DB on the three
acceptance-criterion targets (t_f08fef91 cron-hygiene-audit,
t_007b7f1c EMA-analysis, t_05746fa4 self-assessment) — all three now
return their populated summaries via both ``latest_summary`` and
``latest_summaries``.
Test plan: 255/255 kanban tests pass + 91/91 dashboard plugin tests
pass. No regression on tasks where ``tasks.result`` is explicitly
populated (the existing "Result:" branch is preserved).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-05 14:14:25 +00:00
|
|
|
# Drawer/detail view returns the FULL summary (no truncation) so
|
|
|
|
|
# operators can read the complete worker handoff without making
|
|
|
|
|
# a second round-trip. Cards on /board carry a 200-char preview.
|
|
|
|
|
full_summary = kanban_db.latest_summary(conn, task_id)
|
|
|
|
|
task_d = _task_dict(task, latest_summary=full_summary)
|
feat(kanban): generic diagnostics engine for task distress signals (#20332)
* feat(kanban): generic diagnostics engine for task distress signals
Replaces the hallucination-specific ``warnings`` / ``RecoverySection``
surface (shipped in PR #20232) with a reusable diagnostic-rule engine
that covers five distress kinds in v1 and can be extended without
touching UI code. The "something's wrong with this task" signal is
no longer limited to phantom card ids.
Closes the follow-up from #20232 discussion.
New module
----------
``hermes_cli/kanban_diagnostics.py`` — stateless, no-side-effect rule
engine. Each rule is a pure function of
``(task, events, runs, now, config) -> list[Diagnostic]``. Registry
is a simple list; adding a new distress kind is one function + one
import, no UI or API changes required.
v1 rule set
-----------
* ``hallucinated_cards`` (error) — folds the existing
``completion_blocked_hallucination`` event into the new surface.
* ``prose_phantom_refs`` (warning) — folds
``suspected_hallucinated_references``.
* ``repeated_spawn_failures`` (error → critical at 2x threshold) —
fires when ``tasks.spawn_failures >= 3``; suggests
``hermes -p <profile> doctor`` / ``auth``.
* ``repeated_crashes`` (error → critical) — fires after N consecutive
``crashed`` run outcomes with no successful completion between;
suggests ``hermes kanban log <id>``.
* ``stuck_in_blocked`` (warning) — fires after 24h in ``blocked``
state with no comments / unblock attempts; suggests commenting.
Every diagnostic carries structured ``actions`` (reclaim, reassign,
unblock, cli_hint, comment, open_docs) that render consistently in
both CLI and dashboard. Suggested actions are highlighted; generic
recovery actions (reclaim / reassign) are available on every kind as
fallbacks.
Diagnostics auto-clear when the underlying failure resolves — a
clean ``completed``/``edited`` event drops hallucination diagnostics,
a successful run drops crash diagnostics, a comment drops
stuck-blocked diagnostics. Audit events persist; the badge goes away.
API
---
``plugin_api.py``:
* ``/board`` now attaches ``diagnostics`` (full list) and
``warnings`` (compact summary with ``highest_severity``) per task.
* ``/tasks/{id}`` attaches diagnostics so the drawer's Diagnostics
section auto-opens on flagged tasks.
* NEW ``/diagnostics`` endpoint — fleet-wide listing, filterable by
severity, sorted critical-first.
CLI
---
* NEW ``hermes kanban diagnostics [--severity X] [--task id]
[--json]`` — fleet view or single-task view, matches dashboard rule
output so CLI users see the same picture.
* ``hermes kanban show <id>`` now renders a Diagnostics section near
the top with severity markers + suggested actions.
Dashboard
---------
* Card badge is severity-coloured (⚠ amber warning, !! orange error,
!!! red critical) using ``warnings.highest_severity``.
* Attention strip above the toolbar counts EVERY task with active
diagnostics (not just hallucinations), severity-coloured, lists
affected tasks with Open buttons when expanded.
* Drawer's old ``RecoverySection`` replaced with generic
``DiagnosticsSection`` rendering a card per active diagnostic:
title + detail + structured data (task-id chips when payload keys
look like id lists) + action buttons. Reassign profile picker is
inline per-diagnostic. Clipboard fallback uses ``.catch()`` for
environments where writeText rejects.
* Three-rung severity palette; amber for warning, orange for error,
red for critical. Uses CSS variables so theming is straightforward.
Tests
-----
* NEW ``tests/hermes_cli/test_kanban_diagnostics.py`` — 14 unit tests
covering each rule's positive/negative/threshold paths, severity
sorting, broken-rule isolation, and sqlite3.Row integration.
* Dashboard plugin tests extended: ``/diagnostics`` endpoint (empty,
populated, severity-filtered), ``/board`` exposes both diagnostic
list and compact summary with ``highest_severity``.
* Existing hallucination-specific test (``test_board_surfaces_
warnings_field_for_hallucinated_completions``) updated to reflect
the new contract: warning summary keys by diagnostic kind
(``hallucinated_cards``) not event kind.
379 kanban-suite tests pass (+16 net from this PR).
Live verification
-----------------
Seeded all 5 diagnostic kinds + one clean + one plain-running task
(7 total) into an isolated HERMES_HOME, spun up the dashboard, and
verified:
* Attention strip: shows ``!! 5 tasks need attention`` in the
error-severity orange; Show expands to a list of 5 rows ordered
critical > error > warning.
* Card badges: error tasks render ``!!`` orange, warning tasks
render ``⚠`` amber, clean and plain-running tasks render no badge.
* Each of the 5 rules opens a correctly-coloured, correctly-styled
diagnostic card in the drawer with its specific suggested action.
* Live reassign from a diagnostic card flipped
``broken-ml-worker → alice`` and the drawer refreshed with the
new assignee + the same diagnostic still firing (correct:
spawn_failures counter hasn't reset yet).
* CLI ``hermes kanban diagnostics`` prints all 5 in severity order;
``--severity error`` narrows to 3; ``kanban show <id>`` includes
the Diagnostics block at the top with suggested action hint.
Migration note
--------------
The old ``warnings`` shape (``{count, kinds, latest_at}``) is
preserved on the API but ``kinds`` now keys by diagnostic kind
(``hallucinated_cards``) instead of event kind
(``completion_blocked_hallucination``). ``highest_severity`` is a
new required field. The dashboard was the only consumer and has
been updated in the same commit; external API consumers of the
``warnings`` field will need to update their kind-match logic.
* feat(kanban/diagnostics): lead titles with the actual error text
The generic 'Worker crashed N runs in a row' / 'Worker failed to spawn
N times' titles buried the actual cause in the data section. Operators
had to open logs or expand the diagnostic to see WHY the worker is
stuck — rate-limit vs insufficient quota vs bad auth vs context
overflow vs network blip all looked identical at a glance.
New titles:
Agent crashed 3x: openai: 429 Too Many Requests - rate limit reached
Agent crashed 3x: anthropic: 402 insufficient_quota - credit balance
Agent crashed 3x: provider auth error: 401 Unauthorized
Agent spawn failed 4x: insufficient_quota: You exceeded your current
Detail keeps the full error snippet (capped at 500 chars + ellipsis
for tracebacks). Title takes the first line capped at 160 chars.
Fallback title if no error recorded stays honest ('no error recorded').
Tests: 4 new cases covering 429/billing/spawn/truncation. 383 total
pass (+4).
Live-verified on dashboard with 6 seeded scenarios
(rate-limit, billing, auth, context, network, spawn-billing) —
each card title leads with the actionable error text.
2026-05-05 13:32:42 -07:00
|
|
|
# Attach diagnostics so the drawer's Diagnostics section can
|
|
|
|
|
# render recovery actions without a second round-trip.
|
|
|
|
|
diags = _compute_task_diagnostics(conn, task_ids=[task_id])
|
|
|
|
|
diag_list = diags.get(task_id) or []
|
|
|
|
|
if diag_list:
|
|
|
|
|
task_d["diagnostics"] = diag_list
|
|
|
|
|
task_d["warnings"] = _warnings_summary_from_diagnostics(diag_list)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
return {
|
feat(kanban): hallucination gate + recovery UX for worker-created-card claims (#20232)
Workers completing a kanban task can now claim the ids of cards they
created via an optional ``created_cards`` field on ``kanban_complete``.
The kernel verifies each id exists and was created by the completing
worker's profile; any phantom id blocks the completion with a
``HallucinatedCardsError`` and records a
``completion_blocked_hallucination`` event on the task so the rejected
attempt is auditable. Successful completions also get a non-blocking
prose-scan pass over their ``summary`` + ``result`` that emits a
``suspected_hallucinated_references`` event for any ``t_<hex>``
reference that doesn't resolve.
Closes #20017.
Recovery UX (kernel + CLI + dashboard)
--------------------------------------
A structural gate alone isn't enough — operators also need to see and
act on stuck workers, especially when a profile's model is the root
cause. This PR ships the full loop:
* ``kanban_db.reclaim_task(task_id)`` — operator-driven reclaim that
releases an active worker claim immediately (unlike
``release_stale_claims`` which only acts after claim_expires has
passed). Emits a ``reclaimed`` event with ``manual: True`` payload.
* ``kanban_db.reassign_task(task_id, profile, reclaim_first=...)`` —
switch a task to a different profile, optionally reclaiming a stuck
running worker in the same call.
* ``hermes kanban reclaim <id> [--reason ...]`` and
``hermes kanban reassign <id> <profile> [--reclaim] [--reason ...]``
CLI subcommands wired through to the same helpers.
* ``POST /api/plugins/kanban/tasks/{id}/reclaim`` and
``POST /api/plugins/kanban/tasks/{id}/reassign`` endpoints on the
dashboard plugin.
Dashboard surfacing
-------------------
* ⚠ **warning badge** on cards with active hallucination events.
* **attention strip** at the top of the board listing all flagged
tasks; dismissible per session.
* **events callout** in the task drawer — hallucination events render
with a red left border, amber icon, and phantom ids as styled chips.
* **recovery section** in the task drawer with three actions: Reclaim,
Reassign (with profile picker + reclaim-first checkbox), and a
copy-to-clipboard hint for ``hermes -p <profile> model`` since
profile config lives on disk and can't be edited from the browser.
Auto-opens when the task has warnings, collapsed otherwise.
Keyed by task id so state doesn't leak between drawers.
Active-vs-stale rule: warnings clear when a clean ``completed`` or
``edited`` event supersedes the hallucination, so recovery is never
permanently stigmatising — the audit events persist for debugging but
the badge goes away once the worker succeeds.
Skill updates
-------------
* ``skills/devops/kanban-worker/SKILL.md`` documents the
``created_cards`` contract with good/bad examples.
* ``skills/devops/kanban-orchestrator/SKILL.md`` gains a "Recovering
stuck workers" section with the three actions and when to use each.
Tests
-----
* Kernel gate: verified-cards manifest, phantom rejection + audit
event, cross-worker rejection, prose scan positive + negative.
* Recovery helpers: reclaim on running task, reclaim on non-running
returns False, reassign refuses running without reclaim_first,
reassign with reclaim_first succeeds on running.
* API endpoints: warnings field present on /board and /tasks/:id,
warnings cleared after clean completion, reclaim 200 + 409 paths,
reassign 200 + 409 + reclaim_first paths.
* CLI smoke: reclaim + reassign subcommands.
Live-verified end-to-end on a dashboard with seeded scenarios:
attention strip renders, badges land on the right cards, drawer
callout shows phantom chips, Reclaim on a running task flips status to
ready + emits manual reclaimed event + refreshes the drawer,
Reassign swaps the assignee and triggers board refresh.
359/359 kanban-suite tests pass
(test_kanban_{db,cli,boards,core_functionality} + dashboard + tools).
2026-05-05 08:06:55 -07:00
|
|
|
"task": task_d,
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
"comments": [_comment_dict(c) for c in kanban_db.list_comments(conn, task_id)],
|
|
|
|
|
"events": [_event_dict(e) for e in kanban_db.list_events(conn, task_id)],
|
feat(kanban): file attachments on tasks (#35395)
Tasks can now carry file attachments (PDFs, images, source docs) that
workers read directly — closes the gap where source material had to be
pasted as a path into the task body.
- kanban_db: task_attachments table (additive), Attachment dataclass,
add/list/get/delete accessors, attachments_root/task_attachments_dir
path helpers (per-board, HERMES_KANBAN_ATTACHMENTS_ROOT override)
- build_worker_context: surfaces each attachment's absolute path so the
worker (full file/terminal tool access) reads it via read_file/pdftotext
- dashboard API: POST/GET/DELETE attachment routes (multipart upload,
25MB cap, traversal-safe filenames, root-containment check on download)
- dashboard UI: Attachments section in the task drawer — upload button,
list with download, per-row remove
- docs + tests (13 cases: DB accessors, REST round-trip, traversal
rejection, collision suffixing, worker-context surfacing)
Closes #35338
2026-05-30 07:41:04 -07:00
|
|
|
"attachments": [_attachment_dict(a) for a in kanban_db.list_attachments(conn, task_id)],
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
"links": _links_for(conn, task_id),
|
2026-05-18 21:22:26 -07:00
|
|
|
"runs": [
|
|
|
|
|
_run_dict(r)
|
|
|
|
|
for r in kanban_db.list_runs(
|
|
|
|
|
conn,
|
|
|
|
|
task_id,
|
|
|
|
|
state_type=run_state_type,
|
|
|
|
|
state_name=run_state_name,
|
|
|
|
|
)
|
|
|
|
|
],
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
}
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# POST /tasks
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
class CreateTaskBody(BaseModel):
|
|
|
|
|
title: str
|
|
|
|
|
body: Optional[str] = None
|
|
|
|
|
assignee: Optional[str] = None
|
|
|
|
|
tenant: Optional[str] = None
|
|
|
|
|
priority: int = 0
|
|
|
|
|
workspace_kind: str = "scratch"
|
|
|
|
|
workspace_path: Optional[str] = None
|
|
|
|
|
parents: list[str] = Field(default_factory=list)
|
|
|
|
|
triage: bool = False
|
|
|
|
|
idempotency_key: Optional[str] = None
|
|
|
|
|
max_runtime_seconds: Optional[int] = None
|
|
|
|
|
skills: Optional[list[str]] = None
|
feat(kanban): goal_mode cards run workers in a /goal loop (#35710)
* feat(kanban): goal_mode cards run workers in a /goal loop
A goal_mode card wraps its dispatched worker in the Ralph-style goal
loop behind /goal: after each turn an auxiliary judge checks the
worker's response against the card title+body, and if not done the
worker keeps going in the SAME session until the judge agrees, the
worker terminates the task itself, or the turn budget runs out (which
blocks the card for human review — never a silent exit).
- kanban_db: goal_mode + goal_max_turns columns (additive migration),
Task fields, create_task params, INSERT wiring, created-event payload.
- kanban_tools: goal_mode/goal_max_turns on the kanban_create tool so
orchestrators can opt cards in when fanning out.
- kanban CLI: --goal / --goal-max-turns on 'kanban create'.
- dashboard API: goal_mode/goal_max_turns on the create endpoint
(auto-surfaced back via asdict).
- _default_spawn: sets HERMES_KANBAN_GOAL_MODE / _GOAL_MAX_TURNS only
when the card opts in.
- goals.run_kanban_goal_loop: standalone, callback-injected loop engine
(no SessionDB persistence; ephemeral worker). cli.py quiet path calls
it after the worker's first turn when the env vars are set.
- Docs: orchestrator skill + kanban feature page.
Tests: DB roundtrip + legacy migration, spawn env gating, and the loop's
continuation/completion/budget-block/finalize-nudge branches. E2E run
against a real kanban DB confirms a budget-exhausted goal worker lands
in a sticky blocked state.
* feat(kanban/dashboard): goal-mode toggle in the create form
Wires the goal_mode card setting into the dashboard UI (the plugin's
hand-written IIFE bundle, no build step):
- InlineCreate: 'goal mode' checkbox after the skills field; checking it
reveals an optional 'max turns' number input. Both reset on submit and
only post goal_mode/goal_max_turns when enabled.
- TaskDrawer: a 'Goal mode: on (max N turns)' MetaRow so a card's
goal-mode setting is visible after creation (auto-fed by asdict via the
existing _task_dict).
Live-tested through the running dashboard with a browser: created a
goal-mode card with max-turns=8, confirmed it persisted to the kanban DB
(goal_mode=1, goal_max_turns=8) and rendered back in the drawer as
'on (max 8 turns)'. No JS console errors.
2026-05-31 01:16:33 -07:00
|
|
|
goal_mode: bool = False
|
|
|
|
|
goal_max_turns: Optional[int] = None
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.post("/tasks")
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
def create_task(payload: CreateTaskBody, board: Optional[str] = Query(None)):
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
try:
|
|
|
|
|
task_id = kanban_db.create_task(
|
|
|
|
|
conn,
|
|
|
|
|
title=payload.title,
|
|
|
|
|
body=payload.body,
|
|
|
|
|
assignee=payload.assignee,
|
|
|
|
|
created_by="dashboard",
|
|
|
|
|
workspace_kind=payload.workspace_kind,
|
|
|
|
|
workspace_path=payload.workspace_path,
|
|
|
|
|
tenant=payload.tenant,
|
|
|
|
|
priority=payload.priority,
|
|
|
|
|
parents=payload.parents,
|
|
|
|
|
triage=payload.triage,
|
|
|
|
|
idempotency_key=payload.idempotency_key,
|
|
|
|
|
max_runtime_seconds=payload.max_runtime_seconds,
|
|
|
|
|
skills=payload.skills,
|
feat(kanban): goal_mode cards run workers in a /goal loop (#35710)
* feat(kanban): goal_mode cards run workers in a /goal loop
A goal_mode card wraps its dispatched worker in the Ralph-style goal
loop behind /goal: after each turn an auxiliary judge checks the
worker's response against the card title+body, and if not done the
worker keeps going in the SAME session until the judge agrees, the
worker terminates the task itself, or the turn budget runs out (which
blocks the card for human review — never a silent exit).
- kanban_db: goal_mode + goal_max_turns columns (additive migration),
Task fields, create_task params, INSERT wiring, created-event payload.
- kanban_tools: goal_mode/goal_max_turns on the kanban_create tool so
orchestrators can opt cards in when fanning out.
- kanban CLI: --goal / --goal-max-turns on 'kanban create'.
- dashboard API: goal_mode/goal_max_turns on the create endpoint
(auto-surfaced back via asdict).
- _default_spawn: sets HERMES_KANBAN_GOAL_MODE / _GOAL_MAX_TURNS only
when the card opts in.
- goals.run_kanban_goal_loop: standalone, callback-injected loop engine
(no SessionDB persistence; ephemeral worker). cli.py quiet path calls
it after the worker's first turn when the env vars are set.
- Docs: orchestrator skill + kanban feature page.
Tests: DB roundtrip + legacy migration, spawn env gating, and the loop's
continuation/completion/budget-block/finalize-nudge branches. E2E run
against a real kanban DB confirms a budget-exhausted goal worker lands
in a sticky blocked state.
* feat(kanban/dashboard): goal-mode toggle in the create form
Wires the goal_mode card setting into the dashboard UI (the plugin's
hand-written IIFE bundle, no build step):
- InlineCreate: 'goal mode' checkbox after the skills field; checking it
reveals an optional 'max turns' number input. Both reset on submit and
only post goal_mode/goal_max_turns when enabled.
- TaskDrawer: a 'Goal mode: on (max N turns)' MetaRow so a card's
goal-mode setting is visible after creation (auto-fed by asdict via the
existing _task_dict).
Live-tested through the running dashboard with a browser: created a
goal-mode card with max-turns=8, confirmed it persisted to the kanban DB
(goal_mode=1, goal_max_turns=8) and rendered back in the drawer as
'on (max 8 turns)'. No JS console errors.
2026-05-31 01:16:33 -07:00
|
|
|
goal_mode=payload.goal_mode,
|
|
|
|
|
goal_max_turns=payload.goal_max_turns,
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
)
|
|
|
|
|
task = kanban_db.get_task(conn, task_id)
|
|
|
|
|
body: dict[str, Any] = {"task": _task_dict(task) if task else None}
|
|
|
|
|
# Surface a dispatcher-presence warning so the UI can show a
|
|
|
|
|
# banner when a `ready` task would otherwise sit idle because no
|
|
|
|
|
# gateway is running (or dispatch_in_gateway=false). Only emit
|
|
|
|
|
# for ready+assigned tasks; triage/todo are expected to wait,
|
|
|
|
|
# and unassigned tasks can't be dispatched regardless.
|
|
|
|
|
if task and task.status == "ready" and task.assignee:
|
|
|
|
|
try:
|
|
|
|
|
from hermes_cli.kanban import _check_dispatcher_presence
|
|
|
|
|
running, message = _check_dispatcher_presence()
|
|
|
|
|
if not running and message:
|
|
|
|
|
body["warning"] = message
|
|
|
|
|
except Exception:
|
|
|
|
|
# Probe failure must never block the create itself.
|
|
|
|
|
pass
|
|
|
|
|
return body
|
|
|
|
|
except ValueError as e:
|
|
|
|
|
raise HTTPException(status_code=400, detail=str(e))
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
feat(kanban): file attachments on tasks (#35395)
Tasks can now carry file attachments (PDFs, images, source docs) that
workers read directly — closes the gap where source material had to be
pasted as a path into the task body.
- kanban_db: task_attachments table (additive), Attachment dataclass,
add/list/get/delete accessors, attachments_root/task_attachments_dir
path helpers (per-board, HERMES_KANBAN_ATTACHMENTS_ROOT override)
- build_worker_context: surfaces each attachment's absolute path so the
worker (full file/terminal tool access) reads it via read_file/pdftotext
- dashboard API: POST/GET/DELETE attachment routes (multipart upload,
25MB cap, traversal-safe filenames, root-containment check on download)
- dashboard UI: Attachments section in the task drawer — upload button,
list with download, per-row remove
- docs + tests (13 cases: DB accessors, REST round-trip, traversal
rejection, collision suffixing, worker-context surfacing)
Closes #35338
2026-05-30 07:41:04 -07:00
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Attachments — upload / list / download / delete (#35338)
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
# Cap a single upload so a runaway request can't fill the disk. 25 MB
|
|
|
|
|
# comfortably covers PDFs, images, and source docs — the kanban use case.
|
|
|
|
|
_MAX_ATTACHMENT_BYTES = 25 * 1024 * 1024
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def _safe_attachment_name(raw: str) -> str:
|
|
|
|
|
"""Reduce a client-supplied filename to a safe basename.
|
|
|
|
|
|
|
|
|
|
Strips any directory components (``os.path.basename`` on both
|
|
|
|
|
separators) so a malicious ``../../etc/passwd`` or ``C:\\x`` collapses
|
|
|
|
|
to its leaf. Rejects empty / dotfile-only names. The result is only
|
|
|
|
|
ever joined under the per-task attachments dir, never used verbatim
|
|
|
|
|
as a path from the client.
|
|
|
|
|
"""
|
|
|
|
|
name = (raw or "").replace("\\", "/").split("/")[-1].strip()
|
|
|
|
|
# Drop control chars and leading dots so we never write a dotfile or
|
|
|
|
|
# a name with embedded NULs/newlines.
|
|
|
|
|
name = "".join(ch for ch in name if ch.isprintable() and ch not in '\x00').strip()
|
|
|
|
|
name = name.lstrip(".").strip()
|
|
|
|
|
if not name:
|
|
|
|
|
raise HTTPException(status_code=400, detail="invalid attachment filename")
|
|
|
|
|
return name[:200]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.get("/tasks/{task_id}/attachments")
|
|
|
|
|
def list_task_attachments(task_id: str, board: Optional[str] = Query(None)):
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
|
|
|
|
try:
|
|
|
|
|
if kanban_db.get_task(conn, task_id) is None:
|
|
|
|
|
raise HTTPException(status_code=404, detail=f"task {task_id} not found")
|
|
|
|
|
return {
|
|
|
|
|
"attachments": [
|
|
|
|
|
_attachment_dict(a) for a in kanban_db.list_attachments(conn, task_id)
|
|
|
|
|
]
|
|
|
|
|
}
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.post("/tasks/{task_id}/attachments")
|
|
|
|
|
async def upload_task_attachment(
|
|
|
|
|
task_id: str,
|
|
|
|
|
file: UploadFile = File(...),
|
|
|
|
|
board: Optional[str] = Query(None),
|
|
|
|
|
uploaded_by: Optional[str] = Form(None),
|
|
|
|
|
):
|
|
|
|
|
"""Store an uploaded file for a task and record its metadata.
|
|
|
|
|
|
|
|
|
|
The blob lands under ``attachments_root(board)/<task_id>/`` with a
|
|
|
|
|
sanitised, collision-resolved name. The worker reads it via the
|
|
|
|
|
absolute path surfaced in ``build_worker_context``.
|
|
|
|
|
"""
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
|
|
|
|
try:
|
|
|
|
|
if kanban_db.get_task(conn, task_id) is None:
|
|
|
|
|
raise HTTPException(status_code=404, detail=f"task {task_id} not found")
|
|
|
|
|
|
|
|
|
|
safe_name = _safe_attachment_name(file.filename or "")
|
|
|
|
|
|
|
|
|
|
# Stream to disk with a hard size cap so a huge upload can't fill
|
|
|
|
|
# the disk. Read in chunks; abort + clean up if the cap is hit.
|
|
|
|
|
dest_dir = kanban_db.task_attachments_dir(task_id, board=board)
|
|
|
|
|
dest_dir.mkdir(parents=True, exist_ok=True)
|
|
|
|
|
|
|
|
|
|
# Resolve name collisions: foo.pdf → foo (1).pdf, foo (2).pdf, …
|
|
|
|
|
stem, dot, ext = safe_name.partition(".")
|
|
|
|
|
candidate = safe_name
|
|
|
|
|
n = 1
|
|
|
|
|
while (dest_dir / candidate).exists():
|
|
|
|
|
candidate = f"{stem} ({n}){dot}{ext}"
|
|
|
|
|
n += 1
|
|
|
|
|
dest_path = dest_dir / candidate
|
|
|
|
|
|
|
|
|
|
total = 0
|
|
|
|
|
try:
|
|
|
|
|
with open(dest_path, "wb") as out:
|
|
|
|
|
while True:
|
|
|
|
|
chunk = await file.read(1024 * 1024)
|
|
|
|
|
if not chunk:
|
|
|
|
|
break
|
|
|
|
|
total += len(chunk)
|
|
|
|
|
if total > _MAX_ATTACHMENT_BYTES:
|
|
|
|
|
out.close()
|
|
|
|
|
dest_path.unlink(missing_ok=True)
|
|
|
|
|
raise HTTPException(
|
|
|
|
|
status_code=413,
|
|
|
|
|
detail=(
|
|
|
|
|
f"attachment exceeds {_MAX_ATTACHMENT_BYTES // (1024 * 1024)} MB limit"
|
|
|
|
|
),
|
|
|
|
|
)
|
|
|
|
|
out.write(chunk)
|
|
|
|
|
except HTTPException:
|
|
|
|
|
raise
|
|
|
|
|
except OSError as exc:
|
|
|
|
|
raise HTTPException(status_code=500, detail=f"failed to store attachment: {exc}")
|
|
|
|
|
|
|
|
|
|
att_id = kanban_db.add_attachment(
|
|
|
|
|
conn,
|
|
|
|
|
task_id,
|
|
|
|
|
filename=candidate,
|
|
|
|
|
stored_path=str(dest_path.resolve()),
|
|
|
|
|
content_type=file.content_type,
|
|
|
|
|
size=total,
|
|
|
|
|
uploaded_by=(uploaded_by or "dashboard"),
|
|
|
|
|
)
|
|
|
|
|
att = kanban_db.get_attachment(conn, att_id)
|
|
|
|
|
return {"attachment": _attachment_dict(att) if att else None}
|
|
|
|
|
except ValueError as e:
|
|
|
|
|
raise HTTPException(status_code=400, detail=str(e))
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.get("/attachments/{attachment_id}")
|
|
|
|
|
def download_attachment(attachment_id: int, board: Optional[str] = Query(None)):
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
|
|
|
|
try:
|
|
|
|
|
att = kanban_db.get_attachment(conn, attachment_id)
|
|
|
|
|
if att is None:
|
|
|
|
|
raise HTTPException(status_code=404, detail="attachment not found")
|
|
|
|
|
# Confirm the blob still lives under the board's attachments root
|
|
|
|
|
# before serving — defense in depth against a tampered DB row.
|
|
|
|
|
root = kanban_db.attachments_root(board=board).resolve()
|
|
|
|
|
try:
|
|
|
|
|
stored = Path(att.stored_path).resolve()
|
|
|
|
|
stored.relative_to(root)
|
|
|
|
|
except (ValueError, OSError):
|
|
|
|
|
raise HTTPException(status_code=404, detail="attachment file unavailable")
|
|
|
|
|
if not stored.is_file():
|
|
|
|
|
raise HTTPException(status_code=404, detail="attachment file missing on disk")
|
|
|
|
|
return FileResponse(
|
|
|
|
|
path=str(stored),
|
|
|
|
|
filename=att.filename,
|
|
|
|
|
media_type=att.content_type or "application/octet-stream",
|
|
|
|
|
)
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.delete("/attachments/{attachment_id}")
|
|
|
|
|
def remove_attachment(attachment_id: int, board: Optional[str] = Query(None)):
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
|
|
|
|
try:
|
|
|
|
|
att = kanban_db.delete_attachment(conn, attachment_id)
|
|
|
|
|
if att is None:
|
|
|
|
|
raise HTTPException(status_code=404, detail="attachment not found")
|
|
|
|
|
return {"ok": True, "id": attachment_id}
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# PATCH /tasks/:id (status / assignee / priority / title / body)
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
class UpdateTaskBody(BaseModel):
|
|
|
|
|
status: Optional[str] = None
|
|
|
|
|
assignee: Optional[str] = None
|
|
|
|
|
priority: Optional[int] = None
|
|
|
|
|
title: Optional[str] = None
|
|
|
|
|
body: Optional[str] = None
|
|
|
|
|
result: Optional[str] = None
|
|
|
|
|
block_reason: Optional[str] = None
|
|
|
|
|
# Structured handoff fields — forwarded to complete_task when status
|
|
|
|
|
# transitions to 'done'. Dashboard parity with ``hermes kanban
|
|
|
|
|
# complete --summary ... --metadata ...``.
|
|
|
|
|
summary: Optional[str] = None
|
|
|
|
|
metadata: Optional[dict] = None
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.patch("/tasks/{task_id}")
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
def update_task(task_id: str, payload: UpdateTaskBody, board: Optional[str] = Query(None)):
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
try:
|
|
|
|
|
task = kanban_db.get_task(conn, task_id)
|
|
|
|
|
if task is None:
|
|
|
|
|
raise HTTPException(status_code=404, detail=f"task {task_id} not found")
|
|
|
|
|
|
|
|
|
|
# --- assignee ----------------------------------------------------
|
|
|
|
|
if payload.assignee is not None:
|
|
|
|
|
try:
|
|
|
|
|
ok = kanban_db.assign_task(
|
|
|
|
|
conn, task_id, payload.assignee or None,
|
|
|
|
|
)
|
|
|
|
|
except RuntimeError as e:
|
|
|
|
|
raise HTTPException(status_code=409, detail=str(e))
|
|
|
|
|
if not ok:
|
|
|
|
|
raise HTTPException(status_code=404, detail="task not found")
|
|
|
|
|
|
|
|
|
|
# --- status -------------------------------------------------------
|
|
|
|
|
if payload.status is not None:
|
|
|
|
|
s = payload.status
|
|
|
|
|
ok = True
|
|
|
|
|
if s == "done":
|
|
|
|
|
ok = kanban_db.complete_task(
|
|
|
|
|
conn, task_id,
|
|
|
|
|
result=payload.result,
|
|
|
|
|
summary=payload.summary,
|
|
|
|
|
metadata=payload.metadata,
|
|
|
|
|
)
|
|
|
|
|
elif s == "blocked":
|
|
|
|
|
ok = kanban_db.block_task(conn, task_id, reason=payload.block_reason)
|
2026-05-18 21:38:57 -07:00
|
|
|
elif s == "scheduled":
|
|
|
|
|
ok = kanban_db.schedule_task(conn, task_id, reason=payload.block_reason)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
elif s == "ready":
|
2026-05-18 21:38:57 -07:00
|
|
|
# Re-open a blocked/scheduled task, or just an explicit status set.
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
current = kanban_db.get_task(conn, task_id)
|
2026-05-18 21:38:57 -07:00
|
|
|
if current and current.status in ("blocked", "scheduled"):
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
ok = kanban_db.unblock_task(conn, task_id)
|
|
|
|
|
else:
|
|
|
|
|
# Direct status write for drag-drop (todo -> ready etc).
|
|
|
|
|
ok = _set_status_direct(conn, task_id, "ready")
|
|
|
|
|
elif s == "archived":
|
|
|
|
|
ok = kanban_db.archive_task(conn, task_id)
|
2026-05-04 14:47:13 +08:00
|
|
|
elif s == "running":
|
|
|
|
|
raise HTTPException(
|
|
|
|
|
status_code=400,
|
|
|
|
|
detail="Cannot set status to 'running' directly; use the dispatcher/claim path",
|
|
|
|
|
)
|
2026-05-18 21:38:57 -07:00
|
|
|
elif s in ("todo", "triage", "scheduled"):
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
ok = _set_status_direct(conn, task_id, s)
|
|
|
|
|
else:
|
|
|
|
|
raise HTTPException(status_code=400, detail=f"unknown status: {s}")
|
|
|
|
|
if not ok:
|
2026-05-18 21:54:56 -07:00
|
|
|
# For ``ready``, name the blocking parent(s) so the dashboard
|
|
|
|
|
# can render an actionable toast instead of a silent no-op.
|
|
|
|
|
# See #26744.
|
|
|
|
|
if s == "ready":
|
|
|
|
|
blockers = _parents_blocking_ready(conn, task_id)
|
|
|
|
|
if blockers:
|
|
|
|
|
names = ", ".join(
|
|
|
|
|
f"{p['title']!r} ({p['id']}, status={p['status']})"
|
|
|
|
|
for p in blockers
|
|
|
|
|
)
|
|
|
|
|
raise HTTPException(
|
|
|
|
|
status_code=409,
|
|
|
|
|
detail=(
|
|
|
|
|
f"Cannot move to 'ready': blocked by parent(s) "
|
|
|
|
|
f"not done — {names}"
|
|
|
|
|
),
|
|
|
|
|
)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
raise HTTPException(
|
|
|
|
|
status_code=409,
|
|
|
|
|
detail=f"status transition to {s!r} not valid from current state",
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
# --- priority -----------------------------------------------------
|
|
|
|
|
if payload.priority is not None:
|
|
|
|
|
with kanban_db.write_txn(conn):
|
|
|
|
|
conn.execute(
|
|
|
|
|
"UPDATE tasks SET priority = ? WHERE id = ?",
|
|
|
|
|
(int(payload.priority), task_id),
|
|
|
|
|
)
|
|
|
|
|
conn.execute(
|
|
|
|
|
"INSERT INTO task_events (task_id, kind, payload, created_at) "
|
|
|
|
|
"VALUES (?, 'reprioritized', ?, ?)",
|
|
|
|
|
(task_id, json.dumps({"priority": int(payload.priority)}),
|
|
|
|
|
int(time.time())),
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
# --- title / body -------------------------------------------------
|
|
|
|
|
if payload.title is not None or payload.body is not None:
|
|
|
|
|
with kanban_db.write_txn(conn):
|
|
|
|
|
sets, vals = [], []
|
|
|
|
|
if payload.title is not None:
|
|
|
|
|
if not payload.title.strip():
|
|
|
|
|
raise HTTPException(status_code=400, detail="title cannot be empty")
|
|
|
|
|
sets.append("title = ?")
|
|
|
|
|
vals.append(payload.title.strip())
|
|
|
|
|
if payload.body is not None:
|
|
|
|
|
sets.append("body = ?")
|
|
|
|
|
vals.append(payload.body)
|
|
|
|
|
vals.append(task_id)
|
|
|
|
|
conn.execute(
|
|
|
|
|
f"UPDATE tasks SET {', '.join(sets)} WHERE id = ?", vals,
|
|
|
|
|
)
|
|
|
|
|
conn.execute(
|
|
|
|
|
"INSERT INTO task_events (task_id, kind, payload, created_at) "
|
|
|
|
|
"VALUES (?, 'edited', NULL, ?)",
|
|
|
|
|
(task_id, int(time.time())),
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
updated = kanban_db.get_task(conn, task_id)
|
|
|
|
|
return {"task": _task_dict(updated) if updated else None}
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
2026-05-18 21:40:08 -07:00
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# DELETE /tasks/:id
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
@router.delete("/tasks/{task_id}")
|
|
|
|
|
def delete_task(task_id: str, board: Optional[str] = Query(None)):
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
|
|
|
|
try:
|
|
|
|
|
ok = kanban_db.delete_task(conn, task_id)
|
|
|
|
|
if not ok:
|
|
|
|
|
raise HTTPException(status_code=404, detail=f"task {task_id} not found")
|
|
|
|
|
return {"deleted": True, "task_id": task_id}
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
2026-05-18 21:54:56 -07:00
|
|
|
def _parents_blocking_ready(
|
|
|
|
|
conn: sqlite3.Connection, task_id: str,
|
|
|
|
|
) -> list:
|
|
|
|
|
"""Return parent rows (``id``, ``title``, ``status``) that aren't ``done``
|
|
|
|
|
and therefore prevent ``task_id`` from being promoted to ``ready``.
|
|
|
|
|
|
|
|
|
|
Used to enrich the 409 response from :func:`update_task` so the
|
|
|
|
|
dashboard can show an actionable toast (#26744) instead of a silent
|
|
|
|
|
no-op. Returns ``[]`` when nothing blocks the transition (e.g. no
|
|
|
|
|
parents, or all parents already done).
|
|
|
|
|
"""
|
|
|
|
|
rows = conn.execute(
|
|
|
|
|
"SELECT t.id, t.title, t.status FROM tasks t "
|
|
|
|
|
"JOIN task_links l ON l.parent_id = t.id "
|
|
|
|
|
"WHERE l.child_id = ? AND t.status != 'done'",
|
|
|
|
|
(task_id,),
|
|
|
|
|
).fetchall()
|
|
|
|
|
return [
|
|
|
|
|
{"id": r["id"], "title": r["title"], "status": r["status"]}
|
|
|
|
|
for r in rows
|
|
|
|
|
]
|
|
|
|
|
|
|
|
|
|
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
def _set_status_direct(
|
|
|
|
|
conn: sqlite3.Connection, task_id: str, new_status: str,
|
|
|
|
|
) -> bool:
|
|
|
|
|
"""Direct status write for drag-drop moves that aren't covered by the
|
|
|
|
|
structured complete/block/unblock/archive verbs (e.g. todo<->ready,
|
|
|
|
|
running<->ready). Appends a ``status`` event row for the live feed.
|
|
|
|
|
|
|
|
|
|
When this transitions OFF ``running`` to anything other than the
|
|
|
|
|
terminal verbs above (which own their own run closing), we close the
|
|
|
|
|
active run with outcome='reclaimed' so attempt history isn't
|
|
|
|
|
orphaned. ``running -> ready`` via drag-drop is the common case
|
|
|
|
|
(user yanking a stuck worker back to the queue).
|
|
|
|
|
"""
|
|
|
|
|
with kanban_db.write_txn(conn):
|
|
|
|
|
# Snapshot current state so we know whether to close a run.
|
|
|
|
|
prev = conn.execute(
|
|
|
|
|
"SELECT status, current_run_id FROM tasks WHERE id = ?",
|
|
|
|
|
(task_id,),
|
|
|
|
|
).fetchone()
|
|
|
|
|
if prev is None:
|
|
|
|
|
return False
|
2026-05-04 20:18:40 +08:00
|
|
|
|
|
|
|
|
# Guard: don't allow promoting to 'ready' unless all parents are done.
|
|
|
|
|
# Prevents the dispatcher from spawning a child whose upstream work
|
|
|
|
|
# hasn't completed (e.g. T4 dispatched while T3 is still blocked).
|
|
|
|
|
if new_status == "ready":
|
|
|
|
|
parent_statuses = conn.execute(
|
|
|
|
|
"SELECT t.status FROM tasks t "
|
|
|
|
|
"JOIN task_links l ON l.parent_id = t.id "
|
|
|
|
|
"WHERE l.child_id = ?",
|
|
|
|
|
(task_id,),
|
|
|
|
|
).fetchall()
|
|
|
|
|
if parent_statuses and not all(
|
|
|
|
|
p["status"] == "done" for p in parent_statuses
|
|
|
|
|
):
|
|
|
|
|
return False
|
|
|
|
|
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
was_running = prev["status"] == "running"
|
2026-05-18 20:17:21 -07:00
|
|
|
reopening_satisfied_parent = (
|
|
|
|
|
prev["status"] in {"done", "archived"}
|
|
|
|
|
and new_status not in {"done", "archived"}
|
|
|
|
|
)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
|
|
|
|
|
cur = conn.execute(
|
|
|
|
|
"UPDATE tasks SET status = ?, "
|
|
|
|
|
" claim_lock = CASE WHEN ? = 'running' THEN claim_lock ELSE NULL END, "
|
|
|
|
|
" claim_expires = CASE WHEN ? = 'running' THEN claim_expires ELSE NULL END, "
|
|
|
|
|
" worker_pid = CASE WHEN ? = 'running' THEN worker_pid ELSE NULL END "
|
|
|
|
|
"WHERE id = ?",
|
|
|
|
|
(new_status, new_status, new_status, new_status, task_id),
|
|
|
|
|
)
|
|
|
|
|
if cur.rowcount != 1:
|
|
|
|
|
return False
|
|
|
|
|
run_id = None
|
|
|
|
|
if was_running and new_status != "running" and prev["current_run_id"]:
|
|
|
|
|
run_id = kanban_db._end_run(
|
|
|
|
|
conn, task_id,
|
|
|
|
|
outcome="reclaimed", status="reclaimed",
|
|
|
|
|
summary=f"status changed to {new_status} (dashboard/direct)",
|
|
|
|
|
)
|
|
|
|
|
conn.execute(
|
|
|
|
|
"INSERT INTO task_events (task_id, run_id, kind, payload, created_at) "
|
|
|
|
|
"VALUES (?, ?, 'status', ?, ?)",
|
|
|
|
|
(task_id, run_id, json.dumps({"status": new_status}), int(time.time())),
|
|
|
|
|
)
|
2026-05-18 20:17:21 -07:00
|
|
|
if reopening_satisfied_parent:
|
|
|
|
|
# A parent leaving done/archived invalidates any direct child that
|
|
|
|
|
# was sitting in ready solely because that parent used to satisfy
|
|
|
|
|
# the dependency gate. Demote those children immediately so the
|
|
|
|
|
# dashboard does not keep advertising stale-ready work.
|
|
|
|
|
for row in conn.execute(
|
|
|
|
|
"SELECT child_id FROM task_links WHERE parent_id = ? ORDER BY child_id",
|
|
|
|
|
(task_id,),
|
|
|
|
|
).fetchall():
|
|
|
|
|
child_id = row["child_id"]
|
|
|
|
|
demoted = conn.execute(
|
|
|
|
|
"UPDATE tasks SET status = 'todo' "
|
|
|
|
|
"WHERE id = ? AND status = 'ready'",
|
|
|
|
|
(child_id,),
|
|
|
|
|
)
|
|
|
|
|
if demoted.rowcount == 1:
|
|
|
|
|
conn.execute(
|
|
|
|
|
"INSERT INTO task_events (task_id, kind, payload, created_at) "
|
|
|
|
|
"VALUES (?, 'status', ?, ?)",
|
|
|
|
|
(
|
|
|
|
|
child_id,
|
|
|
|
|
json.dumps(
|
|
|
|
|
{
|
|
|
|
|
"status": "todo",
|
|
|
|
|
"reason": "parent_reopened",
|
|
|
|
|
"parent": task_id,
|
|
|
|
|
}
|
|
|
|
|
),
|
|
|
|
|
int(time.time()),
|
|
|
|
|
),
|
|
|
|
|
)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
# If we re-opened something, children may have gone stale.
|
2026-05-17 02:29:41 -07:00
|
|
|
if new_status in {"done", "ready"}:
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
kanban_db.recompute_ready(conn)
|
|
|
|
|
return True
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Comments
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
class CommentBody(BaseModel):
|
|
|
|
|
body: str
|
|
|
|
|
author: Optional[str] = "dashboard"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.post("/tasks/{task_id}/comments")
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
def add_comment(task_id: str, payload: CommentBody, board: Optional[str] = Query(None)):
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
if not payload.body.strip():
|
|
|
|
|
raise HTTPException(status_code=400, detail="body is required")
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
try:
|
|
|
|
|
if kanban_db.get_task(conn, task_id) is None:
|
|
|
|
|
raise HTTPException(status_code=404, detail=f"task {task_id} not found")
|
|
|
|
|
kanban_db.add_comment(
|
|
|
|
|
conn, task_id, author=payload.author or "dashboard", body=payload.body,
|
|
|
|
|
)
|
|
|
|
|
return {"ok": True}
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Links
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
class LinkBody(BaseModel):
|
|
|
|
|
parent_id: str
|
|
|
|
|
child_id: str
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.post("/links")
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
def add_link(payload: LinkBody, board: Optional[str] = Query(None)):
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
try:
|
|
|
|
|
kanban_db.link_tasks(conn, payload.parent_id, payload.child_id)
|
|
|
|
|
return {"ok": True}
|
|
|
|
|
except ValueError as e:
|
|
|
|
|
raise HTTPException(status_code=400, detail=str(e))
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.delete("/links")
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
def delete_link(
|
|
|
|
|
parent_id: str = Query(...),
|
|
|
|
|
child_id: str = Query(...),
|
|
|
|
|
board: Optional[str] = Query(None),
|
|
|
|
|
):
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
try:
|
|
|
|
|
ok = kanban_db.unlink_tasks(conn, parent_id, child_id)
|
|
|
|
|
return {"ok": bool(ok)}
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Bulk actions (multi-select on the board)
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
class BulkTaskBody(BaseModel):
|
|
|
|
|
ids: list[str]
|
|
|
|
|
status: Optional[str] = None
|
|
|
|
|
assignee: Optional[str] = None # "" or None = unassign
|
|
|
|
|
priority: Optional[int] = None
|
|
|
|
|
archive: bool = False
|
2026-05-05 11:07:13 +08:00
|
|
|
result: Optional[str] = None
|
|
|
|
|
summary: Optional[str] = None
|
|
|
|
|
metadata: Optional[dict] = None
|
2026-05-10 11:14:50 +02:00
|
|
|
reclaim_first: bool = False
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.post("/tasks/bulk")
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
def bulk_update(payload: BulkTaskBody, board: Optional[str] = Query(None)):
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
"""Apply the same patch to every id in ``payload.ids``.
|
|
|
|
|
|
|
|
|
|
This is an *independent* iteration — per-task failures don't abort
|
|
|
|
|
siblings. Returns per-id outcome so the UI can surface partials.
|
|
|
|
|
"""
|
|
|
|
|
ids = [i for i in (payload.ids or []) if i]
|
|
|
|
|
if not ids:
|
|
|
|
|
raise HTTPException(status_code=400, detail="ids is required")
|
|
|
|
|
results: list[dict] = []
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
try:
|
|
|
|
|
for tid in ids:
|
|
|
|
|
entry: dict[str, Any] = {"id": tid, "ok": True}
|
|
|
|
|
try:
|
|
|
|
|
task = kanban_db.get_task(conn, tid)
|
|
|
|
|
if task is None:
|
|
|
|
|
entry.update(ok=False, error="not found")
|
|
|
|
|
results.append(entry)
|
|
|
|
|
continue
|
|
|
|
|
if payload.archive:
|
|
|
|
|
if not kanban_db.archive_task(conn, tid):
|
|
|
|
|
entry.update(ok=False, error="archive refused")
|
|
|
|
|
if payload.status is not None and not payload.archive:
|
|
|
|
|
s = payload.status
|
|
|
|
|
if s == "done":
|
2026-05-05 11:07:13 +08:00
|
|
|
ok = kanban_db.complete_task(
|
|
|
|
|
conn, tid,
|
|
|
|
|
result=payload.result,
|
|
|
|
|
summary=payload.summary,
|
|
|
|
|
metadata=payload.metadata,
|
|
|
|
|
)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
elif s == "blocked":
|
|
|
|
|
ok = kanban_db.block_task(conn, tid)
|
|
|
|
|
elif s == "ready":
|
|
|
|
|
cur = kanban_db.get_task(conn, tid)
|
2026-05-18 21:38:57 -07:00
|
|
|
if cur and cur.status in ("blocked", "scheduled"):
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
ok = kanban_db.unblock_task(conn, tid)
|
|
|
|
|
else:
|
|
|
|
|
ok = _set_status_direct(conn, tid, "ready")
|
2026-05-18 20:38:26 -07:00
|
|
|
elif s == "running":
|
|
|
|
|
entry.update(
|
|
|
|
|
ok=False,
|
|
|
|
|
error=(
|
|
|
|
|
"Cannot set status to 'running' directly; "
|
|
|
|
|
"use the dispatcher/claim path"
|
|
|
|
|
),
|
|
|
|
|
)
|
|
|
|
|
results.append(entry)
|
|
|
|
|
continue
|
2026-05-18 21:38:57 -07:00
|
|
|
elif s == "scheduled":
|
|
|
|
|
ok = kanban_db.schedule_task(conn, tid)
|
2026-05-18 20:38:26 -07:00
|
|
|
elif s in {"todo", "triage"}:
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
ok = _set_status_direct(conn, tid, s)
|
|
|
|
|
else:
|
|
|
|
|
entry.update(ok=False, error=f"unknown status {s!r}")
|
|
|
|
|
results.append(entry)
|
|
|
|
|
continue
|
|
|
|
|
if not ok:
|
|
|
|
|
entry.update(ok=False, error=f"transition to {s!r} refused")
|
|
|
|
|
if payload.assignee is not None:
|
|
|
|
|
try:
|
2026-05-10 11:14:50 +02:00
|
|
|
if payload.reclaim_first:
|
|
|
|
|
ok = kanban_db.reassign_task(
|
|
|
|
|
conn, tid, payload.assignee or None,
|
|
|
|
|
reclaim_first=True,
|
|
|
|
|
)
|
|
|
|
|
else:
|
|
|
|
|
ok = kanban_db.assign_task(
|
|
|
|
|
conn, tid, payload.assignee or None,
|
|
|
|
|
)
|
|
|
|
|
if not ok:
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
entry.update(ok=False, error="assign refused")
|
|
|
|
|
except RuntimeError as e:
|
|
|
|
|
entry.update(ok=False, error=str(e))
|
|
|
|
|
if payload.priority is not None:
|
|
|
|
|
with kanban_db.write_txn(conn):
|
|
|
|
|
conn.execute(
|
|
|
|
|
"UPDATE tasks SET priority = ? WHERE id = ?",
|
|
|
|
|
(int(payload.priority), tid),
|
|
|
|
|
)
|
|
|
|
|
conn.execute(
|
|
|
|
|
"INSERT INTO task_events (task_id, kind, payload, created_at) "
|
|
|
|
|
"VALUES (?, 'reprioritized', ?, ?)",
|
|
|
|
|
(tid, json.dumps({"priority": int(payload.priority)}),
|
|
|
|
|
int(time.time())),
|
|
|
|
|
)
|
|
|
|
|
except Exception as e: # defensive — one bad id shouldn't kill the batch
|
|
|
|
|
entry.update(ok=False, error=str(e))
|
|
|
|
|
results.append(entry)
|
|
|
|
|
return {"results": results}
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
feat(kanban): generic diagnostics engine for task distress signals (#20332)
* feat(kanban): generic diagnostics engine for task distress signals
Replaces the hallucination-specific ``warnings`` / ``RecoverySection``
surface (shipped in PR #20232) with a reusable diagnostic-rule engine
that covers five distress kinds in v1 and can be extended without
touching UI code. The "something's wrong with this task" signal is
no longer limited to phantom card ids.
Closes the follow-up from #20232 discussion.
New module
----------
``hermes_cli/kanban_diagnostics.py`` — stateless, no-side-effect rule
engine. Each rule is a pure function of
``(task, events, runs, now, config) -> list[Diagnostic]``. Registry
is a simple list; adding a new distress kind is one function + one
import, no UI or API changes required.
v1 rule set
-----------
* ``hallucinated_cards`` (error) — folds the existing
``completion_blocked_hallucination`` event into the new surface.
* ``prose_phantom_refs`` (warning) — folds
``suspected_hallucinated_references``.
* ``repeated_spawn_failures`` (error → critical at 2x threshold) —
fires when ``tasks.spawn_failures >= 3``; suggests
``hermes -p <profile> doctor`` / ``auth``.
* ``repeated_crashes`` (error → critical) — fires after N consecutive
``crashed`` run outcomes with no successful completion between;
suggests ``hermes kanban log <id>``.
* ``stuck_in_blocked`` (warning) — fires after 24h in ``blocked``
state with no comments / unblock attempts; suggests commenting.
Every diagnostic carries structured ``actions`` (reclaim, reassign,
unblock, cli_hint, comment, open_docs) that render consistently in
both CLI and dashboard. Suggested actions are highlighted; generic
recovery actions (reclaim / reassign) are available on every kind as
fallbacks.
Diagnostics auto-clear when the underlying failure resolves — a
clean ``completed``/``edited`` event drops hallucination diagnostics,
a successful run drops crash diagnostics, a comment drops
stuck-blocked diagnostics. Audit events persist; the badge goes away.
API
---
``plugin_api.py``:
* ``/board`` now attaches ``diagnostics`` (full list) and
``warnings`` (compact summary with ``highest_severity``) per task.
* ``/tasks/{id}`` attaches diagnostics so the drawer's Diagnostics
section auto-opens on flagged tasks.
* NEW ``/diagnostics`` endpoint — fleet-wide listing, filterable by
severity, sorted critical-first.
CLI
---
* NEW ``hermes kanban diagnostics [--severity X] [--task id]
[--json]`` — fleet view or single-task view, matches dashboard rule
output so CLI users see the same picture.
* ``hermes kanban show <id>`` now renders a Diagnostics section near
the top with severity markers + suggested actions.
Dashboard
---------
* Card badge is severity-coloured (⚠ amber warning, !! orange error,
!!! red critical) using ``warnings.highest_severity``.
* Attention strip above the toolbar counts EVERY task with active
diagnostics (not just hallucinations), severity-coloured, lists
affected tasks with Open buttons when expanded.
* Drawer's old ``RecoverySection`` replaced with generic
``DiagnosticsSection`` rendering a card per active diagnostic:
title + detail + structured data (task-id chips when payload keys
look like id lists) + action buttons. Reassign profile picker is
inline per-diagnostic. Clipboard fallback uses ``.catch()`` for
environments where writeText rejects.
* Three-rung severity palette; amber for warning, orange for error,
red for critical. Uses CSS variables so theming is straightforward.
Tests
-----
* NEW ``tests/hermes_cli/test_kanban_diagnostics.py`` — 14 unit tests
covering each rule's positive/negative/threshold paths, severity
sorting, broken-rule isolation, and sqlite3.Row integration.
* Dashboard plugin tests extended: ``/diagnostics`` endpoint (empty,
populated, severity-filtered), ``/board`` exposes both diagnostic
list and compact summary with ``highest_severity``.
* Existing hallucination-specific test (``test_board_surfaces_
warnings_field_for_hallucinated_completions``) updated to reflect
the new contract: warning summary keys by diagnostic kind
(``hallucinated_cards``) not event kind.
379 kanban-suite tests pass (+16 net from this PR).
Live verification
-----------------
Seeded all 5 diagnostic kinds + one clean + one plain-running task
(7 total) into an isolated HERMES_HOME, spun up the dashboard, and
verified:
* Attention strip: shows ``!! 5 tasks need attention`` in the
error-severity orange; Show expands to a list of 5 rows ordered
critical > error > warning.
* Card badges: error tasks render ``!!`` orange, warning tasks
render ``⚠`` amber, clean and plain-running tasks render no badge.
* Each of the 5 rules opens a correctly-coloured, correctly-styled
diagnostic card in the drawer with its specific suggested action.
* Live reassign from a diagnostic card flipped
``broken-ml-worker → alice`` and the drawer refreshed with the
new assignee + the same diagnostic still firing (correct:
spawn_failures counter hasn't reset yet).
* CLI ``hermes kanban diagnostics`` prints all 5 in severity order;
``--severity error`` narrows to 3; ``kanban show <id>`` includes
the Diagnostics block at the top with suggested action hint.
Migration note
--------------
The old ``warnings`` shape (``{count, kinds, latest_at}``) is
preserved on the API but ``kinds`` now keys by diagnostic kind
(``hallucinated_cards``) instead of event kind
(``completion_blocked_hallucination``). ``highest_severity`` is a
new required field. The dashboard was the only consumer and has
been updated in the same commit; external API consumers of the
``warnings`` field will need to update their kind-match logic.
* feat(kanban/diagnostics): lead titles with the actual error text
The generic 'Worker crashed N runs in a row' / 'Worker failed to spawn
N times' titles buried the actual cause in the data section. Operators
had to open logs or expand the diagnostic to see WHY the worker is
stuck — rate-limit vs insufficient quota vs bad auth vs context
overflow vs network blip all looked identical at a glance.
New titles:
Agent crashed 3x: openai: 429 Too Many Requests - rate limit reached
Agent crashed 3x: anthropic: 402 insufficient_quota - credit balance
Agent crashed 3x: provider auth error: 401 Unauthorized
Agent spawn failed 4x: insufficient_quota: You exceeded your current
Detail keeps the full error snippet (capped at 500 chars + ellipsis
for tracebacks). Title takes the first line capped at 160 chars.
Fallback title if no error recorded stays honest ('no error recorded').
Tests: 4 new cases covering 429/billing/spawn/truncation. 383 total
pass (+4).
Live-verified on dashboard with 6 seeded scenarios
(rate-limit, billing, auth, context, network, spawn-billing) —
each card title leads with the actionable error text.
2026-05-05 13:32:42 -07:00
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Diagnostics — fleet-wide distress signals (hallucinations, crashes,
|
|
|
|
|
# spawn failures, stuck-blocked). See hermes_cli.kanban_diagnostics for
|
|
|
|
|
# the rule engine.
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
@router.get("/diagnostics")
|
|
|
|
|
def list_diagnostics(
|
|
|
|
|
board: Optional[str] = Query(None, description="Kanban board slug (omit for current)"),
|
|
|
|
|
severity: Optional[str] = Query(
|
|
|
|
|
None,
|
|
|
|
|
description="Filter by severity: warning|error|critical",
|
|
|
|
|
),
|
|
|
|
|
):
|
|
|
|
|
"""Return ``[{task_id, task_title, task_status, task_assignee,
|
|
|
|
|
diagnostics: [...]}, ...]`` for every task on the board with at
|
|
|
|
|
least one active diagnostic.
|
|
|
|
|
|
|
|
|
|
Severity-filterable so the UI can render "just the critical ones"
|
|
|
|
|
or the CLI can grep. Useful for the board-header attention strip
|
|
|
|
|
AND for ``hermes kanban diagnostics`` which shells to this
|
|
|
|
|
endpoint when the dashboard's running, or invokes the engine
|
|
|
|
|
directly when it isn't.
|
|
|
|
|
"""
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
|
|
|
|
try:
|
|
|
|
|
diags_by_task = _compute_task_diagnostics(conn, task_ids=None)
|
|
|
|
|
if not diags_by_task:
|
|
|
|
|
return {"diagnostics": [], "count": 0}
|
|
|
|
|
|
|
|
|
|
# Narrow by severity if asked.
|
|
|
|
|
if severity:
|
|
|
|
|
filtered: dict[str, list[dict]] = {}
|
|
|
|
|
for tid, dl in diags_by_task.items():
|
2026-05-18 20:46:55 -07:00
|
|
|
keep = [d for d in dl if kd.severity_at_or_above(d.get("severity"), severity)]
|
feat(kanban): generic diagnostics engine for task distress signals (#20332)
* feat(kanban): generic diagnostics engine for task distress signals
Replaces the hallucination-specific ``warnings`` / ``RecoverySection``
surface (shipped in PR #20232) with a reusable diagnostic-rule engine
that covers five distress kinds in v1 and can be extended without
touching UI code. The "something's wrong with this task" signal is
no longer limited to phantom card ids.
Closes the follow-up from #20232 discussion.
New module
----------
``hermes_cli/kanban_diagnostics.py`` — stateless, no-side-effect rule
engine. Each rule is a pure function of
``(task, events, runs, now, config) -> list[Diagnostic]``. Registry
is a simple list; adding a new distress kind is one function + one
import, no UI or API changes required.
v1 rule set
-----------
* ``hallucinated_cards`` (error) — folds the existing
``completion_blocked_hallucination`` event into the new surface.
* ``prose_phantom_refs`` (warning) — folds
``suspected_hallucinated_references``.
* ``repeated_spawn_failures`` (error → critical at 2x threshold) —
fires when ``tasks.spawn_failures >= 3``; suggests
``hermes -p <profile> doctor`` / ``auth``.
* ``repeated_crashes`` (error → critical) — fires after N consecutive
``crashed`` run outcomes with no successful completion between;
suggests ``hermes kanban log <id>``.
* ``stuck_in_blocked`` (warning) — fires after 24h in ``blocked``
state with no comments / unblock attempts; suggests commenting.
Every diagnostic carries structured ``actions`` (reclaim, reassign,
unblock, cli_hint, comment, open_docs) that render consistently in
both CLI and dashboard. Suggested actions are highlighted; generic
recovery actions (reclaim / reassign) are available on every kind as
fallbacks.
Diagnostics auto-clear when the underlying failure resolves — a
clean ``completed``/``edited`` event drops hallucination diagnostics,
a successful run drops crash diagnostics, a comment drops
stuck-blocked diagnostics. Audit events persist; the badge goes away.
API
---
``plugin_api.py``:
* ``/board`` now attaches ``diagnostics`` (full list) and
``warnings`` (compact summary with ``highest_severity``) per task.
* ``/tasks/{id}`` attaches diagnostics so the drawer's Diagnostics
section auto-opens on flagged tasks.
* NEW ``/diagnostics`` endpoint — fleet-wide listing, filterable by
severity, sorted critical-first.
CLI
---
* NEW ``hermes kanban diagnostics [--severity X] [--task id]
[--json]`` — fleet view or single-task view, matches dashboard rule
output so CLI users see the same picture.
* ``hermes kanban show <id>`` now renders a Diagnostics section near
the top with severity markers + suggested actions.
Dashboard
---------
* Card badge is severity-coloured (⚠ amber warning, !! orange error,
!!! red critical) using ``warnings.highest_severity``.
* Attention strip above the toolbar counts EVERY task with active
diagnostics (not just hallucinations), severity-coloured, lists
affected tasks with Open buttons when expanded.
* Drawer's old ``RecoverySection`` replaced with generic
``DiagnosticsSection`` rendering a card per active diagnostic:
title + detail + structured data (task-id chips when payload keys
look like id lists) + action buttons. Reassign profile picker is
inline per-diagnostic. Clipboard fallback uses ``.catch()`` for
environments where writeText rejects.
* Three-rung severity palette; amber for warning, orange for error,
red for critical. Uses CSS variables so theming is straightforward.
Tests
-----
* NEW ``tests/hermes_cli/test_kanban_diagnostics.py`` — 14 unit tests
covering each rule's positive/negative/threshold paths, severity
sorting, broken-rule isolation, and sqlite3.Row integration.
* Dashboard plugin tests extended: ``/diagnostics`` endpoint (empty,
populated, severity-filtered), ``/board`` exposes both diagnostic
list and compact summary with ``highest_severity``.
* Existing hallucination-specific test (``test_board_surfaces_
warnings_field_for_hallucinated_completions``) updated to reflect
the new contract: warning summary keys by diagnostic kind
(``hallucinated_cards``) not event kind.
379 kanban-suite tests pass (+16 net from this PR).
Live verification
-----------------
Seeded all 5 diagnostic kinds + one clean + one plain-running task
(7 total) into an isolated HERMES_HOME, spun up the dashboard, and
verified:
* Attention strip: shows ``!! 5 tasks need attention`` in the
error-severity orange; Show expands to a list of 5 rows ordered
critical > error > warning.
* Card badges: error tasks render ``!!`` orange, warning tasks
render ``⚠`` amber, clean and plain-running tasks render no badge.
* Each of the 5 rules opens a correctly-coloured, correctly-styled
diagnostic card in the drawer with its specific suggested action.
* Live reassign from a diagnostic card flipped
``broken-ml-worker → alice`` and the drawer refreshed with the
new assignee + the same diagnostic still firing (correct:
spawn_failures counter hasn't reset yet).
* CLI ``hermes kanban diagnostics`` prints all 5 in severity order;
``--severity error`` narrows to 3; ``kanban show <id>`` includes
the Diagnostics block at the top with suggested action hint.
Migration note
--------------
The old ``warnings`` shape (``{count, kinds, latest_at}``) is
preserved on the API but ``kinds`` now keys by diagnostic kind
(``hallucinated_cards``) instead of event kind
(``completion_blocked_hallucination``). ``highest_severity`` is a
new required field. The dashboard was the only consumer and has
been updated in the same commit; external API consumers of the
``warnings`` field will need to update their kind-match logic.
* feat(kanban/diagnostics): lead titles with the actual error text
The generic 'Worker crashed N runs in a row' / 'Worker failed to spawn
N times' titles buried the actual cause in the data section. Operators
had to open logs or expand the diagnostic to see WHY the worker is
stuck — rate-limit vs insufficient quota vs bad auth vs context
overflow vs network blip all looked identical at a glance.
New titles:
Agent crashed 3x: openai: 429 Too Many Requests - rate limit reached
Agent crashed 3x: anthropic: 402 insufficient_quota - credit balance
Agent crashed 3x: provider auth error: 401 Unauthorized
Agent spawn failed 4x: insufficient_quota: You exceeded your current
Detail keeps the full error snippet (capped at 500 chars + ellipsis
for tracebacks). Title takes the first line capped at 160 chars.
Fallback title if no error recorded stays honest ('no error recorded').
Tests: 4 new cases covering 429/billing/spawn/truncation. 383 total
pass (+4).
Live-verified on dashboard with 6 seeded scenarios
(rate-limit, billing, auth, context, network, spawn-billing) —
each card title leads with the actionable error text.
2026-05-05 13:32:42 -07:00
|
|
|
if keep:
|
|
|
|
|
filtered[tid] = keep
|
|
|
|
|
diags_by_task = filtered
|
|
|
|
|
if not diags_by_task:
|
|
|
|
|
return {"diagnostics": [], "count": 0}
|
|
|
|
|
|
|
|
|
|
# Pull the task rows we need in one query so we can include
|
|
|
|
|
# titles/statuses without a per-task lookup.
|
|
|
|
|
ids = list(diags_by_task.keys())
|
|
|
|
|
placeholders = ",".join(["?"] * len(ids))
|
|
|
|
|
rows = {
|
|
|
|
|
r["id"]: r
|
|
|
|
|
for r in conn.execute(
|
|
|
|
|
f"SELECT id, title, status, assignee FROM tasks WHERE id IN ({placeholders})",
|
|
|
|
|
tuple(ids),
|
|
|
|
|
).fetchall()
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
out = []
|
|
|
|
|
for tid, dl in diags_by_task.items():
|
|
|
|
|
r = rows.get(tid)
|
|
|
|
|
out.append({
|
|
|
|
|
"task_id": tid,
|
|
|
|
|
"task_title": r["title"] if r else None,
|
|
|
|
|
"task_status": r["status"] if r else None,
|
|
|
|
|
"task_assignee": r["assignee"] if r else None,
|
|
|
|
|
"diagnostics": dl,
|
|
|
|
|
})
|
|
|
|
|
# Sort: highest severity first, then most recent.
|
|
|
|
|
from hermes_cli.kanban_diagnostics import SEVERITY_ORDER
|
|
|
|
|
sev_idx = {s: i for i, s in enumerate(SEVERITY_ORDER)}
|
|
|
|
|
def _sort_key(row):
|
|
|
|
|
top = row["diagnostics"][0]
|
|
|
|
|
return (
|
|
|
|
|
-sev_idx.get(top.get("severity"), -1),
|
|
|
|
|
-(top.get("last_seen_at") or 0),
|
|
|
|
|
)
|
|
|
|
|
out.sort(key=_sort_key)
|
|
|
|
|
|
|
|
|
|
return {
|
|
|
|
|
"diagnostics": out,
|
|
|
|
|
"count": sum(len(d["diagnostics"]) for d in out),
|
|
|
|
|
}
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
feat(kanban): worker visibility endpoints (workers/active, runs/{id}, inspect)
Adds three read-only endpoints to the kanban dashboard plugin so the
SwitchUI workspace (and any other dashboard consumer) can track
workers across tasks without N+1 round-trips through /tasks/{task_id}.
- GET /workers/active
Single SQL JOIN of task_runs + tasks where ended_at IS NULL,
worker_pid IS NOT NULL, status='running'. Returns
{workers: [...], count, checked_at}.
- GET /runs/{run_id}
Direct lookup of any task_run row by id. Reuses existing
kanban_db.get_run() helper and _run_dict() serialiser. 404 when
not found. Mirrors GET /tasks/{task_id} 404 shape.
- GET /runs/{run_id}/inspect
Live PID stats via psutil.Process.as_dict() — cpu_percent,
memory_rss_bytes, memory_vms_bytes, num_threads, num_fds, status,
create_time, cmdline. Short-circuits with alive:false when run
has ended, has no worker_pid, the pid is gone, or psutil is
unavailable. AccessDenied surfaces as alive:true with error
rather than a 500.
11 new tests in tests/plugins/test_kanban_worker_runs.py cover the
empty-board case, running-task case, ended-run filtering,
missing-pid filtering, 404 paths, already-ended inspect, no-pid
inspect, dead-pid inspect, and live-pid inspect (psutil mocked).
All pass.
Companion termination endpoint (POST /runs/{run_id}/terminate) is
intentionally out of scope here — opening a separate issue first
since the RBAC and dispatcher-mediated soft-cancel design needs
maintainer input before code.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-18 21:01:42 -07:00
|
|
|
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Worker visibility — cross-task active-worker list and per-run inspection
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
try:
|
|
|
|
|
import psutil as _psutil
|
|
|
|
|
except ImportError:
|
|
|
|
|
_psutil = None # type: ignore[assignment]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.get("/workers/active")
|
|
|
|
|
def list_active_workers(
|
|
|
|
|
board: Optional[str] = Query(None, description="Kanban board slug (omit for current)"),
|
|
|
|
|
):
|
|
|
|
|
"""Return every currently-running worker on the board.
|
|
|
|
|
|
|
|
|
|
A worker is a ``task_runs`` row whose ``ended_at`` is NULL and whose
|
|
|
|
|
``worker_pid`` is non-NULL, belonging to a task with ``status='running'``.
|
|
|
|
|
|
|
|
|
|
Returns ``{workers: [...], count: N, checked_at: <epoch>}``. Each
|
|
|
|
|
worker entry carries enough context for the dashboard to link back to
|
|
|
|
|
its task without a second round-trip.
|
|
|
|
|
"""
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
|
|
|
|
try:
|
|
|
|
|
rows = conn.execute(
|
|
|
|
|
"""
|
|
|
|
|
SELECT
|
|
|
|
|
r.id AS run_id,
|
|
|
|
|
r.task_id,
|
|
|
|
|
t.title AS task_title,
|
|
|
|
|
t.status AS task_status,
|
|
|
|
|
t.assignee AS task_assignee,
|
|
|
|
|
r.profile,
|
|
|
|
|
r.worker_pid,
|
|
|
|
|
r.started_at,
|
|
|
|
|
r.claim_lock,
|
|
|
|
|
r.claim_expires,
|
|
|
|
|
r.last_heartbeat_at,
|
|
|
|
|
r.max_runtime_seconds
|
|
|
|
|
FROM task_runs r
|
|
|
|
|
JOIN tasks t ON t.id = r.task_id
|
|
|
|
|
WHERE r.ended_at IS NULL
|
|
|
|
|
AND r.worker_pid IS NOT NULL
|
|
|
|
|
AND t.status = 'running'
|
|
|
|
|
ORDER BY r.started_at ASC
|
|
|
|
|
""",
|
|
|
|
|
).fetchall()
|
|
|
|
|
workers = [
|
|
|
|
|
{
|
|
|
|
|
"run_id": row["run_id"],
|
|
|
|
|
"task_id": row["task_id"],
|
|
|
|
|
"task_title": row["task_title"],
|
|
|
|
|
"task_status": row["task_status"],
|
|
|
|
|
"task_assignee": row["task_assignee"],
|
|
|
|
|
"profile": row["profile"],
|
|
|
|
|
"worker_pid": row["worker_pid"],
|
|
|
|
|
"started_at": row["started_at"],
|
|
|
|
|
"claim_lock": row["claim_lock"],
|
|
|
|
|
"claim_expires": row["claim_expires"],
|
|
|
|
|
"last_heartbeat_at": row["last_heartbeat_at"],
|
|
|
|
|
"max_runtime_seconds": row["max_runtime_seconds"],
|
|
|
|
|
}
|
|
|
|
|
for row in rows
|
|
|
|
|
]
|
|
|
|
|
return {"workers": workers, "count": len(workers), "checked_at": int(time.time())}
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.get("/runs/{run_id}")
|
|
|
|
|
def get_run_endpoint(
|
|
|
|
|
run_id: int,
|
|
|
|
|
board: Optional[str] = Query(None, description="Kanban board slug (omit for current)"),
|
|
|
|
|
):
|
|
|
|
|
"""Direct lookup of a ``task_runs`` row by its integer id.
|
|
|
|
|
|
|
|
|
|
Returns ``{run: {...}}`` using the same serialisation as the
|
|
|
|
|
per-task run history embedded in ``GET /tasks/{task_id}``.
|
|
|
|
|
404 when no such run exists.
|
|
|
|
|
"""
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
|
|
|
|
try:
|
|
|
|
|
r = kanban_db.get_run(conn, run_id)
|
|
|
|
|
if r is None:
|
|
|
|
|
raise HTTPException(status_code=404, detail=f"run {run_id} not found")
|
|
|
|
|
return {"run": _run_dict(r)}
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.get("/runs/{run_id}/inspect")
|
|
|
|
|
def inspect_run_endpoint(
|
|
|
|
|
run_id: int,
|
|
|
|
|
board: Optional[str] = Query(None, description="Kanban board slug (omit for current)"),
|
|
|
|
|
):
|
|
|
|
|
"""Live PID stats for a run's worker process via psutil.
|
|
|
|
|
|
|
|
|
|
If the run has already ended, or has no recorded ``worker_pid``,
|
|
|
|
|
returns ``{alive: false}`` with a human-readable ``reason``.
|
|
|
|
|
|
|
|
|
|
When the process is live, returns CPU, memory, thread count, fd count,
|
|
|
|
|
status, create_time, and cmdline. ``access_denied`` is set when the
|
|
|
|
|
OS refuses inspection rather than raising a 500.
|
|
|
|
|
|
|
|
|
|
psutil availability: if psutil is not installed the endpoint still
|
|
|
|
|
works but ``alive`` is always returned as ``false`` with
|
|
|
|
|
``reason="psutil not available"``.
|
|
|
|
|
"""
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
|
|
|
|
try:
|
|
|
|
|
r = kanban_db.get_run(conn, run_id)
|
|
|
|
|
if r is None:
|
|
|
|
|
raise HTTPException(status_code=404, detail=f"run {run_id} not found")
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
if r.ended_at is not None:
|
|
|
|
|
return {"run_id": run_id, "alive": False, "reason": "run already ended"}
|
|
|
|
|
if r.worker_pid is None:
|
|
|
|
|
return {"run_id": run_id, "alive": False, "reason": "no worker_pid recorded"}
|
|
|
|
|
|
|
|
|
|
pid = r.worker_pid
|
|
|
|
|
|
|
|
|
|
if _psutil is None:
|
|
|
|
|
return {"run_id": run_id, "alive": False, "pid": pid, "reason": "psutil not available"}
|
|
|
|
|
|
|
|
|
|
try:
|
|
|
|
|
proc = _psutil.Process(pid)
|
|
|
|
|
info = proc.as_dict(attrs=[
|
|
|
|
|
"cpu_percent", "memory_info", "num_threads",
|
|
|
|
|
"status", "create_time", "cmdline",
|
|
|
|
|
])
|
|
|
|
|
# num_fds is POSIX-only; skip gracefully on Windows.
|
|
|
|
|
try:
|
|
|
|
|
num_fds = proc.num_fds()
|
|
|
|
|
except AttributeError:
|
|
|
|
|
num_fds = None
|
|
|
|
|
mem = info.get("memory_info")
|
|
|
|
|
return {
|
|
|
|
|
"run_id": run_id,
|
|
|
|
|
"alive": True,
|
|
|
|
|
"pid": pid,
|
|
|
|
|
"cpu_percent": info.get("cpu_percent"),
|
|
|
|
|
"memory_rss_bytes": mem.rss if mem else None,
|
|
|
|
|
"memory_vms_bytes": mem.vms if mem else None,
|
|
|
|
|
"num_threads": info.get("num_threads"),
|
|
|
|
|
"num_fds": num_fds,
|
|
|
|
|
"status": info.get("status"),
|
|
|
|
|
"create_time": info.get("create_time"),
|
|
|
|
|
"cmdline": info.get("cmdline"),
|
|
|
|
|
}
|
|
|
|
|
except _psutil.NoSuchProcess:
|
|
|
|
|
return {"run_id": run_id, "alive": False, "pid": pid, "reason": "process not found"}
|
|
|
|
|
except _psutil.AccessDenied:
|
|
|
|
|
return {"run_id": run_id, "alive": True, "pid": pid, "error": "access denied"}
|
|
|
|
|
|
|
|
|
|
|
2026-05-23 21:19:00 +02:00
|
|
|
class TerminateRunBody(BaseModel):
|
|
|
|
|
reason: Optional[str] = None
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.post("/runs/{run_id}/terminate")
|
|
|
|
|
def terminate_run_endpoint(
|
|
|
|
|
run_id: int,
|
|
|
|
|
payload: TerminateRunBody,
|
|
|
|
|
board: Optional[str] = Query(None, description="Kanban board slug (omit for current)"),
|
|
|
|
|
):
|
|
|
|
|
"""Terminate the worker process backing an in-flight run.
|
|
|
|
|
|
|
|
|
|
Resolves ``run_id`` to its parent ``task_id`` and routes through
|
|
|
|
|
:func:`kanban_db.reclaim_task` so the SIGTERM->SIGKILL flow,
|
|
|
|
|
run-outcome bookkeeping, and event-log append all match what the
|
|
|
|
|
existing ``POST /tasks/{task_id}/reclaim`` endpoint does.
|
|
|
|
|
|
|
|
|
|
Responses:
|
|
|
|
|
* 200 ``{"ok": true, "run_id": ..., "task_id": ...}`` on success.
|
|
|
|
|
* 404 when ``run_id`` is unknown.
|
|
|
|
|
* 409 when the run has already ended, or the task is no longer in
|
|
|
|
|
a claimable state.
|
|
|
|
|
|
|
|
|
|
Closes the gap left by PR #28432, which shipped the read-only
|
|
|
|
|
sibling endpoints (``/workers/active``, ``/runs/{run_id}``,
|
|
|
|
|
``/runs/{run_id}/inspect``) but no termination control surface.
|
|
|
|
|
"""
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
|
|
|
|
try:
|
|
|
|
|
r = kanban_db.get_run(conn, run_id)
|
|
|
|
|
if r is None:
|
|
|
|
|
raise HTTPException(status_code=404, detail=f"run {run_id} not found")
|
|
|
|
|
if r.ended_at is not None:
|
|
|
|
|
raise HTTPException(
|
|
|
|
|
status_code=409,
|
|
|
|
|
detail=f"run {run_id} already ended",
|
|
|
|
|
)
|
|
|
|
|
ok = kanban_db.reclaim_task(conn, r.task_id, reason=payload.reason)
|
|
|
|
|
if not ok:
|
|
|
|
|
raise HTTPException(
|
|
|
|
|
status_code=409,
|
|
|
|
|
detail=(
|
|
|
|
|
f"cannot terminate run {run_id}: task {r.task_id} is no "
|
|
|
|
|
"longer in a reclaimable state"
|
|
|
|
|
),
|
|
|
|
|
)
|
|
|
|
|
return {"ok": True, "run_id": run_id, "task_id": r.task_id}
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
feat(kanban): hallucination gate + recovery UX for worker-created-card claims (#20232)
Workers completing a kanban task can now claim the ids of cards they
created via an optional ``created_cards`` field on ``kanban_complete``.
The kernel verifies each id exists and was created by the completing
worker's profile; any phantom id blocks the completion with a
``HallucinatedCardsError`` and records a
``completion_blocked_hallucination`` event on the task so the rejected
attempt is auditable. Successful completions also get a non-blocking
prose-scan pass over their ``summary`` + ``result`` that emits a
``suspected_hallucinated_references`` event for any ``t_<hex>``
reference that doesn't resolve.
Closes #20017.
Recovery UX (kernel + CLI + dashboard)
--------------------------------------
A structural gate alone isn't enough — operators also need to see and
act on stuck workers, especially when a profile's model is the root
cause. This PR ships the full loop:
* ``kanban_db.reclaim_task(task_id)`` — operator-driven reclaim that
releases an active worker claim immediately (unlike
``release_stale_claims`` which only acts after claim_expires has
passed). Emits a ``reclaimed`` event with ``manual: True`` payload.
* ``kanban_db.reassign_task(task_id, profile, reclaim_first=...)`` —
switch a task to a different profile, optionally reclaiming a stuck
running worker in the same call.
* ``hermes kanban reclaim <id> [--reason ...]`` and
``hermes kanban reassign <id> <profile> [--reclaim] [--reason ...]``
CLI subcommands wired through to the same helpers.
* ``POST /api/plugins/kanban/tasks/{id}/reclaim`` and
``POST /api/plugins/kanban/tasks/{id}/reassign`` endpoints on the
dashboard plugin.
Dashboard surfacing
-------------------
* ⚠ **warning badge** on cards with active hallucination events.
* **attention strip** at the top of the board listing all flagged
tasks; dismissible per session.
* **events callout** in the task drawer — hallucination events render
with a red left border, amber icon, and phantom ids as styled chips.
* **recovery section** in the task drawer with three actions: Reclaim,
Reassign (with profile picker + reclaim-first checkbox), and a
copy-to-clipboard hint for ``hermes -p <profile> model`` since
profile config lives on disk and can't be edited from the browser.
Auto-opens when the task has warnings, collapsed otherwise.
Keyed by task id so state doesn't leak between drawers.
Active-vs-stale rule: warnings clear when a clean ``completed`` or
``edited`` event supersedes the hallucination, so recovery is never
permanently stigmatising — the audit events persist for debugging but
the badge goes away once the worker succeeds.
Skill updates
-------------
* ``skills/devops/kanban-worker/SKILL.md`` documents the
``created_cards`` contract with good/bad examples.
* ``skills/devops/kanban-orchestrator/SKILL.md`` gains a "Recovering
stuck workers" section with the three actions and when to use each.
Tests
-----
* Kernel gate: verified-cards manifest, phantom rejection + audit
event, cross-worker rejection, prose scan positive + negative.
* Recovery helpers: reclaim on running task, reclaim on non-running
returns False, reassign refuses running without reclaim_first,
reassign with reclaim_first succeeds on running.
* API endpoints: warnings field present on /board and /tasks/:id,
warnings cleared after clean completion, reclaim 200 + 409 paths,
reassign 200 + 409 + reclaim_first paths.
* CLI smoke: reclaim + reassign subcommands.
Live-verified end-to-end on a dashboard with seeded scenarios:
attention strip renders, badges land on the right cards, drawer
callout shows phantom chips, Reclaim on a running task flips status to
ready + emits manual reclaimed event + refreshes the drawer,
Reassign swaps the assignee and triggers board refresh.
359/359 kanban-suite tests pass
(test_kanban_{db,cli,boards,core_functionality} + dashboard + tools).
2026-05-05 08:06:55 -07:00
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Recovery actions — reclaim a running claim, reassign to a new profile
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
class ReclaimBody(BaseModel):
|
|
|
|
|
reason: Optional[str] = None
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.post("/tasks/{task_id}/reclaim")
|
|
|
|
|
def reclaim_task_endpoint(
|
|
|
|
|
task_id: str,
|
|
|
|
|
payload: ReclaimBody,
|
|
|
|
|
board: Optional[str] = Query(None),
|
|
|
|
|
):
|
|
|
|
|
"""Release an active worker claim on a running task.
|
|
|
|
|
|
|
|
|
|
Used by the dashboard recovery popover when an operator wants to
|
|
|
|
|
abort a stuck worker (e.g. one that keeps hallucinating card ids)
|
|
|
|
|
without waiting for the claim TTL. Maps 1:1 to
|
|
|
|
|
``hermes kanban reclaim <task_id> --reason ...``.
|
|
|
|
|
"""
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
|
|
|
|
try:
|
|
|
|
|
ok = kanban_db.reclaim_task(conn, task_id, reason=payload.reason)
|
|
|
|
|
if not ok:
|
|
|
|
|
raise HTTPException(
|
|
|
|
|
status_code=409,
|
|
|
|
|
detail=(
|
|
|
|
|
f"cannot reclaim {task_id}: not in a claimable state "
|
|
|
|
|
"(not running, or unknown id)"
|
|
|
|
|
),
|
|
|
|
|
)
|
|
|
|
|
return {"ok": True, "task_id": task_id}
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
feat(kanban): add `specify` — auxiliary LLM fleshes out triage tasks (#21435)
* feat(kanban): add `specify` — auxiliary LLM fleshes out triage tasks
The Triage column shipped with a placeholder 'a specifier will flesh
out the spec', but the specifier itself was never built. This wires
it up as a dedicated CLI verb.
`hermes kanban specify <id>` calls the auxiliary LLM (configured under
`auxiliary.triage_specifier`) to expand a rough one-liner into a
concrete spec — tightened title plus a body with Goal / Approach /
Acceptance criteria / Out-of-scope sections — then atomically flips
`status: triage -> todo` and recomputes ready so parent-free tasks
go straight to the dispatcher on the same tick.
Surface:
hermes kanban specify <task_id> # single task
hermes kanban specify --all [--tenant T] # sweep triage column
hermes kanban specify ... --author NAME # audit-comment author
hermes kanban specify ... --json # one JSON line per task
Design choices:
- Parent gating is preserved. specify_triage_task flips to 'todo',
then recompute_ready promotes to 'ready' only when parents are
done — same rule as a normal parent-gated todo.
- No daemon, no background watcher. Every invocation is explicit —
keeps cost predictable and doesn't fight the dispatcher loop.
- Response parse is lenient: strict JSON preferred, markdown-fence
tolerated, raw-body fallback on malformed JSON so the LLM can't
strand a task in triage.
- All failure modes (no aux client, API error, task moved out of
triage mid-call) return SpecifyOutcome(ok=False, reason=...) so
--all continues past individual failures.
Changes:
hermes_cli/kanban_db.py + specify_triage_task()
hermes_cli/kanban_specify.py NEW (~220 LOC — prompt, parse, call)
hermes_cli/kanban.py + specify subcommand + _cmd_specify
hermes_cli/config.py + auxiliary.triage_specifier task slot
website/docs/user-guide/features/kanban.md specify + config notes
website/docs/reference/cli-commands.md CLI reference entry
tests/hermes_cli/test_kanban_specify_db.py NEW (10 tests)
tests/hermes_cli/test_kanban_specify.py NEW (20 tests)
Validation: 30/30 targeted tests pass. E2E: triage task -> specify ->
ends in 'ready' with events [created, specified, promoted] and the
audit comment recorded under the configured author.
* feat(kanban): wire specifier into dashboard and gateway slash
Follow-ups to the initial PR #21435 — closes the two gaps I'd left as
post-merge: dashboard button and first-class gateway surface.
Dashboard (plugins/kanban/dashboard/)
- POST /tasks/:id/specify NEW endpoint. Thin wrapper around
kanban_specify.specify_task(). Returns the CLI outcome shape
({ok, task_id, reason, new_title}); ok=false with a human reason
is a 200, not a 4xx, so the UI can render it inline without
treating 'no aux client configured' as a crash.
- Runs sync in FastAPI's threadpool because the LLM call can take
tens of seconds on reasoning models.
- Pins HERMES_KANBAN_BOARD around the specify call so the module's
argless kb.connect() lands on the right board.
- dist/index.js: doSpecify callback threaded through the drawer →
TaskDetail → StatusActions prop chain. ✨ Specify button appears
ONLY when task.status === 'triage' (elsewhere the backend would
reject anyway — hide the button to keep the action row clean).
Busy state (Specifying…) + inline success/error banner under the
button using the response.reason text.
- dist/style.css: tiny hermes-kanban-msg-ok / -err classes using
existing --color vars so themes reskin cleanly.
Gateway slash (/kanban specify)
- Already works via the existing run_slash → build_parser →
kanban_command pipeline. No code change needed — slash commands
inherit the argparse tree automatically. Added coverage:
test_run_slash_specify_end_to_end (create --triage, specify, verify
promotion + retitle) and test_run_slash_specify_help_is_reachable.
Tests
- tests/plugins/test_kanban_dashboard_plugin.py: 3 new tests for the
REST endpoint — happy path, non-triage rejection as ok=false 200,
missing aux client as ok=false 200.
- tests/hermes_cli/test_kanban_cli.py: 2 new slash-surface tests.
Docs
- website/docs/user-guide/features/kanban.md: dashboard action row
description mentions ✨ Specify + all three surfaces. REST table
gains /tasks/:id/specify. Slash examples include /kanban specify.
Validation: 340/340 targeted tests pass. E2E via TestClient: create a
triage task over REST → POST /specify with mocked aux client → task
moves to 'ready' column on /board with new title and body applied.
2026-05-07 13:04:41 -07:00
|
|
|
class SpecifyBody(BaseModel):
|
|
|
|
|
"""Optional author override. Nothing else is configurable from the
|
|
|
|
|
dashboard — model + prompt come from ``auxiliary.triage_specifier``
|
|
|
|
|
in config.yaml, same as the CLI."""
|
|
|
|
|
|
|
|
|
|
author: Optional[str] = None
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.post("/tasks/{task_id}/specify")
|
|
|
|
|
def specify_task_endpoint(
|
|
|
|
|
task_id: str,
|
|
|
|
|
payload: SpecifyBody,
|
|
|
|
|
board: Optional[str] = Query(None),
|
|
|
|
|
):
|
|
|
|
|
"""Flesh out a triage-column task via the auxiliary LLM and promote
|
|
|
|
|
it to ``todo``. Maps 1:1 to ``hermes kanban specify <task_id>``.
|
|
|
|
|
|
|
|
|
|
Returns the outcome shape used by the CLI: ``{ok, task_id, reason,
|
|
|
|
|
new_title}``. A non-OK outcome is NOT an HTTP error — the UI renders
|
|
|
|
|
the reason inline (e.g. "no auxiliary client configured") so the
|
|
|
|
|
operator knows what to fix, and retries without a page reload.
|
|
|
|
|
|
|
|
|
|
This endpoint runs in FastAPI's threadpool (sync ``def``) because
|
|
|
|
|
the underlying LLM call can take tens of seconds to minutes on
|
|
|
|
|
reasoning models, which would block the event loop if we used
|
|
|
|
|
``async def`` without an explicit ``run_in_executor``.
|
|
|
|
|
"""
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
# Pin the board for the duration of this call so the specifier module
|
|
|
|
|
# (which calls ``kb.connect()`` with no args) hits the right DB.
|
|
|
|
|
prev_env = os.environ.get("HERMES_KANBAN_BOARD")
|
|
|
|
|
try:
|
|
|
|
|
os.environ["HERMES_KANBAN_BOARD"] = board or kanban_db.DEFAULT_BOARD
|
|
|
|
|
# Import lazily so a missing auxiliary client at import time
|
|
|
|
|
# doesn't break plugin load.
|
|
|
|
|
from hermes_cli import kanban_specify # noqa: WPS433 (intentional)
|
|
|
|
|
|
|
|
|
|
outcome = kanban_specify.specify_task(
|
|
|
|
|
task_id,
|
|
|
|
|
author=(payload.author or None),
|
|
|
|
|
)
|
|
|
|
|
finally:
|
|
|
|
|
if prev_env is None:
|
|
|
|
|
os.environ.pop("HERMES_KANBAN_BOARD", None)
|
|
|
|
|
else:
|
|
|
|
|
os.environ["HERMES_KANBAN_BOARD"] = prev_env
|
|
|
|
|
|
|
|
|
|
return {
|
|
|
|
|
"ok": bool(outcome.ok),
|
|
|
|
|
"task_id": outcome.task_id,
|
|
|
|
|
"reason": outcome.reason,
|
|
|
|
|
"new_title": outcome.new_title,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
feat(kanban): hallucination gate + recovery UX for worker-created-card claims (#20232)
Workers completing a kanban task can now claim the ids of cards they
created via an optional ``created_cards`` field on ``kanban_complete``.
The kernel verifies each id exists and was created by the completing
worker's profile; any phantom id blocks the completion with a
``HallucinatedCardsError`` and records a
``completion_blocked_hallucination`` event on the task so the rejected
attempt is auditable. Successful completions also get a non-blocking
prose-scan pass over their ``summary`` + ``result`` that emits a
``suspected_hallucinated_references`` event for any ``t_<hex>``
reference that doesn't resolve.
Closes #20017.
Recovery UX (kernel + CLI + dashboard)
--------------------------------------
A structural gate alone isn't enough — operators also need to see and
act on stuck workers, especially when a profile's model is the root
cause. This PR ships the full loop:
* ``kanban_db.reclaim_task(task_id)`` — operator-driven reclaim that
releases an active worker claim immediately (unlike
``release_stale_claims`` which only acts after claim_expires has
passed). Emits a ``reclaimed`` event with ``manual: True`` payload.
* ``kanban_db.reassign_task(task_id, profile, reclaim_first=...)`` —
switch a task to a different profile, optionally reclaiming a stuck
running worker in the same call.
* ``hermes kanban reclaim <id> [--reason ...]`` and
``hermes kanban reassign <id> <profile> [--reclaim] [--reason ...]``
CLI subcommands wired through to the same helpers.
* ``POST /api/plugins/kanban/tasks/{id}/reclaim`` and
``POST /api/plugins/kanban/tasks/{id}/reassign`` endpoints on the
dashboard plugin.
Dashboard surfacing
-------------------
* ⚠ **warning badge** on cards with active hallucination events.
* **attention strip** at the top of the board listing all flagged
tasks; dismissible per session.
* **events callout** in the task drawer — hallucination events render
with a red left border, amber icon, and phantom ids as styled chips.
* **recovery section** in the task drawer with three actions: Reclaim,
Reassign (with profile picker + reclaim-first checkbox), and a
copy-to-clipboard hint for ``hermes -p <profile> model`` since
profile config lives on disk and can't be edited from the browser.
Auto-opens when the task has warnings, collapsed otherwise.
Keyed by task id so state doesn't leak between drawers.
Active-vs-stale rule: warnings clear when a clean ``completed`` or
``edited`` event supersedes the hallucination, so recovery is never
permanently stigmatising — the audit events persist for debugging but
the badge goes away once the worker succeeds.
Skill updates
-------------
* ``skills/devops/kanban-worker/SKILL.md`` documents the
``created_cards`` contract with good/bad examples.
* ``skills/devops/kanban-orchestrator/SKILL.md`` gains a "Recovering
stuck workers" section with the three actions and when to use each.
Tests
-----
* Kernel gate: verified-cards manifest, phantom rejection + audit
event, cross-worker rejection, prose scan positive + negative.
* Recovery helpers: reclaim on running task, reclaim on non-running
returns False, reassign refuses running without reclaim_first,
reassign with reclaim_first succeeds on running.
* API endpoints: warnings field present on /board and /tasks/:id,
warnings cleared after clean completion, reclaim 200 + 409 paths,
reassign 200 + 409 + reclaim_first paths.
* CLI smoke: reclaim + reassign subcommands.
Live-verified end-to-end on a dashboard with seeded scenarios:
attention strip renders, badges land on the right cards, drawer
callout shows phantom chips, Reclaim on a running task flips status to
ready + emits manual reclaimed event + refreshes the drawer,
Reassign swaps the assignee and triggers board refresh.
359/359 kanban-suite tests pass
(test_kanban_{db,cli,boards,core_functionality} + dashboard + tools).
2026-05-05 08:06:55 -07:00
|
|
|
class ReassignBody(BaseModel):
|
|
|
|
|
profile: Optional[str] = None # "" or None = unassign
|
|
|
|
|
reclaim_first: bool = False
|
|
|
|
|
reason: Optional[str] = None
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.post("/tasks/{task_id}/reassign")
|
|
|
|
|
def reassign_task_endpoint(
|
|
|
|
|
task_id: str,
|
|
|
|
|
payload: ReassignBody,
|
|
|
|
|
board: Optional[str] = Query(None),
|
|
|
|
|
):
|
|
|
|
|
"""Reassign a task to a different profile, optionally reclaiming first.
|
|
|
|
|
|
|
|
|
|
Used by the dashboard recovery popover when an operator wants to
|
|
|
|
|
retry a task with a different worker profile (e.g. switch to a
|
|
|
|
|
smarter model after the assigned profile keeps hallucinating).
|
|
|
|
|
Maps 1:1 to ``hermes kanban reassign <task_id> <profile> [--reclaim]``.
|
|
|
|
|
"""
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
|
|
|
|
try:
|
|
|
|
|
ok = kanban_db.reassign_task(
|
|
|
|
|
conn, task_id,
|
|
|
|
|
payload.profile or None,
|
|
|
|
|
reclaim_first=bool(payload.reclaim_first),
|
|
|
|
|
reason=payload.reason,
|
|
|
|
|
)
|
|
|
|
|
if not ok:
|
|
|
|
|
raise HTTPException(
|
|
|
|
|
status_code=409,
|
|
|
|
|
detail=(
|
|
|
|
|
f"cannot reassign {task_id}: unknown id, or still "
|
|
|
|
|
"running (pass reclaim_first=true to release the claim first)"
|
|
|
|
|
),
|
|
|
|
|
)
|
|
|
|
|
return {"ok": True, "task_id": task_id, "assignee": payload.profile or None}
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Plugin config (read dashboard.kanban.* defaults from config.yaml)
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
@router.get("/config")
|
|
|
|
|
def get_config():
|
|
|
|
|
"""Return kanban dashboard preferences from ~/.hermes/config.yaml.
|
|
|
|
|
|
|
|
|
|
Reads the ``dashboard.kanban`` section if present; defaults otherwise.
|
|
|
|
|
Used by the UI to pre-select tenant filters, toggle markdown rendering,
|
|
|
|
|
or set column-width preferences without a round-trip per page load.
|
|
|
|
|
"""
|
|
|
|
|
try:
|
|
|
|
|
from hermes_cli.config import load_config
|
|
|
|
|
cfg = load_config() or {}
|
|
|
|
|
except Exception:
|
|
|
|
|
cfg = {}
|
|
|
|
|
dash_cfg = (cfg.get("dashboard") or {})
|
|
|
|
|
# dashboard.kanban may itself be a dict; fall back to {}.
|
|
|
|
|
k_cfg = dash_cfg.get("kanban") or {}
|
|
|
|
|
return {
|
|
|
|
|
"default_tenant": k_cfg.get("default_tenant") or "",
|
|
|
|
|
"lane_by_profile": bool(k_cfg.get("lane_by_profile", True)),
|
|
|
|
|
"include_archived_by_default": bool(k_cfg.get("include_archived_by_default", False)),
|
|
|
|
|
"render_markdown": bool(k_cfg.get("render_markdown", True)),
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
feat(kanban-dashboard): per-platform home-channel notification toggles (#19864)
* revert: auto-subscribe gateway chat on tool-driven kanban_create (#19718)
Reverts ff3d2773e2. Teknium reviewed the merged PR and decided this
behavior isn't wanted — tool-driven kanban_create should not mirror
the slash-command path's auto-subscribe. Orchestrators that want
their originating chat notified can call kanban_notify-subscribe
explicitly; we're not going to make it implicit.
* feat(kanban-dashboard): per-platform home-channel notification toggles
Adds a "Notify home channels" section to the task drawer in the kanban
dashboard plugin. Each platform where the user has set a home channel
(/sethome, TELEGRAM_HOME_CHANNEL env var, gateway.platforms.<p>.home_channel
in config.yaml) gets a toggle pill. Toggling on writes a kanban_notify_subs
row keyed to that platform's home (chat_id + thread_id); toggling off
removes it. The existing gateway notifier watcher delivers completed /
blocked / gave_up events without any new plumbing — this is purely a GUI
surface over existing machinery.
Replaces the reverted auto-subscribe behavior from #19718 with an explicit,
per-task, per-platform, user-controlled opt-in. No implicit subscription
on tool-driven kanban_create; no CLI commands; no slash commands. Just a
toggle in the drawer.
Backend (plugins/kanban/dashboard/plugin_api.py):
- GET /api/plugins/kanban/home-channels[?task_id=X]
Returns every platform with a configured home, plus a per-entry
subscribed: bool relative to task_id (false when task_id omitted).
Reads the live GatewayConfig via load_gateway_config() so env-var
overlays stay honored.
- POST /api/plugins/kanban/tasks/:id/home-subscribe/:platform
Idempotent add_notify_sub keyed to the platform's home.
- DELETE /api/plugins/kanban/tasks/:id/home-subscribe/:platform
remove_notify_sub for the same tuple.
- 404 when the platform has no home configured, or task_id doesn't
exist (POST only).
Frontend (plugins/kanban/dashboard/dist/index.js):
- TaskDrawer fetches /home-channels on open, keyed on task_id.
- HomeSubsSection renders nothing when zero platforms have a home (so
users who haven't set one up don't see an empty UI block).
- Optimistic toggle with busy flag + revert-on-failure. One pill per
platform; ✓ prefix and --on class indicate the subscribed state.
CSS (plugins/kanban/dashboard/dist/style.css):
- .hermes-kanban-home-subs flex row + .hermes-kanban-home-sub pill
style + --on subscribed variant (subtle ring-colored background).
Live-tested against a dashboard with TELEGRAM + DISCORD_BOT_TOKEN /
HOME_CHANNEL env vars set: drawer shows both pills, toggling each
flips its visual state AND writes/removes the correct kanban_notify_subs
row (verified via direct DB read).
Tests (tests/plugins/test_kanban_dashboard_plugin.py, 11 new, 53/53
pass total):
- home-channels lists only platforms with a home (slack with a
token but no home is excluded)
- no task_id -> all subscribed=false
- subscribe creates notify_sub row with correct chat/thread/platform
- subscribed=true reflected in subsequent GET
- idempotent re-subscribe
- unknown platform -> 404
- unknown task -> 404
- unsubscribe removes the row
- telegram + discord subscribe/unsubscribe independent
- zero homes -> empty list
2026-05-04 12:31:21 -07:00
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Home-channel subscriptions (per-task, per-platform toggles)
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
#
|
|
|
|
|
# Home channels are a first-class gateway concept — each configured platform
|
|
|
|
|
# can have exactly one (chat_id, thread_id, name) it considers "home". The
|
|
|
|
|
# dashboard surfaces these as per-task toggles so a user can opt a specific
|
|
|
|
|
# task into receiving terminal notifications (completed / blocked / gave_up)
|
|
|
|
|
# at their telegram/discord/slack home, without touching the CLI.
|
|
|
|
|
#
|
|
|
|
|
# The wire format mirrors kanban_db.add_notify_sub — (task_id, platform,
|
|
|
|
|
# chat_id, thread_id) — so toggle-on creates exactly the same row the
|
|
|
|
|
# `/kanban create` slash command would, and the existing gateway notifier
|
|
|
|
|
# watcher delivers events without any additional plumbing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def _configured_home_channels() -> list[dict]:
|
|
|
|
|
"""Return every platform that has a home_channel set, fully hydrated.
|
|
|
|
|
|
|
|
|
|
Reads the live GatewayConfig so env-var overlays (``TELEGRAM_HOME_CHANNEL``
|
|
|
|
|
etc.) are honored alongside config.yaml. Returns platforms in a stable
|
|
|
|
|
order and drops platforms without a home.
|
|
|
|
|
"""
|
|
|
|
|
try:
|
|
|
|
|
from gateway.config import load_gateway_config
|
|
|
|
|
except Exception:
|
|
|
|
|
return []
|
|
|
|
|
try:
|
|
|
|
|
gw_cfg = load_gateway_config()
|
|
|
|
|
except Exception:
|
|
|
|
|
return []
|
|
|
|
|
result: list[dict] = []
|
|
|
|
|
for platform, pcfg in gw_cfg.platforms.items():
|
|
|
|
|
if not pcfg or not pcfg.home_channel:
|
|
|
|
|
continue
|
|
|
|
|
hc = pcfg.home_channel
|
|
|
|
|
result.append({
|
|
|
|
|
"platform": platform.value,
|
|
|
|
|
"chat_id": hc.chat_id,
|
|
|
|
|
"thread_id": hc.thread_id or "",
|
|
|
|
|
"name": hc.name or "Home",
|
|
|
|
|
})
|
|
|
|
|
# Stable order for deterministic UI — platform name alphabetical.
|
|
|
|
|
result.sort(key=lambda r: r["platform"])
|
|
|
|
|
return result
|
|
|
|
|
|
|
|
|
|
|
2026-05-18 20:14:39 -07:00
|
|
|
def _active_profile_name() -> str:
|
|
|
|
|
"""Return the current Hermes profile name for notify-sub ownership."""
|
|
|
|
|
try:
|
|
|
|
|
from hermes_cli.profiles import get_active_profile_name
|
|
|
|
|
return get_active_profile_name() or "default"
|
|
|
|
|
except Exception:
|
|
|
|
|
return "default"
|
|
|
|
|
|
|
|
|
|
|
feat(kanban-dashboard): per-platform home-channel notification toggles (#19864)
* revert: auto-subscribe gateway chat on tool-driven kanban_create (#19718)
Reverts ff3d2773e2. Teknium reviewed the merged PR and decided this
behavior isn't wanted — tool-driven kanban_create should not mirror
the slash-command path's auto-subscribe. Orchestrators that want
their originating chat notified can call kanban_notify-subscribe
explicitly; we're not going to make it implicit.
* feat(kanban-dashboard): per-platform home-channel notification toggles
Adds a "Notify home channels" section to the task drawer in the kanban
dashboard plugin. Each platform where the user has set a home channel
(/sethome, TELEGRAM_HOME_CHANNEL env var, gateway.platforms.<p>.home_channel
in config.yaml) gets a toggle pill. Toggling on writes a kanban_notify_subs
row keyed to that platform's home (chat_id + thread_id); toggling off
removes it. The existing gateway notifier watcher delivers completed /
blocked / gave_up events without any new plumbing — this is purely a GUI
surface over existing machinery.
Replaces the reverted auto-subscribe behavior from #19718 with an explicit,
per-task, per-platform, user-controlled opt-in. No implicit subscription
on tool-driven kanban_create; no CLI commands; no slash commands. Just a
toggle in the drawer.
Backend (plugins/kanban/dashboard/plugin_api.py):
- GET /api/plugins/kanban/home-channels[?task_id=X]
Returns every platform with a configured home, plus a per-entry
subscribed: bool relative to task_id (false when task_id omitted).
Reads the live GatewayConfig via load_gateway_config() so env-var
overlays stay honored.
- POST /api/plugins/kanban/tasks/:id/home-subscribe/:platform
Idempotent add_notify_sub keyed to the platform's home.
- DELETE /api/plugins/kanban/tasks/:id/home-subscribe/:platform
remove_notify_sub for the same tuple.
- 404 when the platform has no home configured, or task_id doesn't
exist (POST only).
Frontend (plugins/kanban/dashboard/dist/index.js):
- TaskDrawer fetches /home-channels on open, keyed on task_id.
- HomeSubsSection renders nothing when zero platforms have a home (so
users who haven't set one up don't see an empty UI block).
- Optimistic toggle with busy flag + revert-on-failure. One pill per
platform; ✓ prefix and --on class indicate the subscribed state.
CSS (plugins/kanban/dashboard/dist/style.css):
- .hermes-kanban-home-subs flex row + .hermes-kanban-home-sub pill
style + --on subscribed variant (subtle ring-colored background).
Live-tested against a dashboard with TELEGRAM + DISCORD_BOT_TOKEN /
HOME_CHANNEL env vars set: drawer shows both pills, toggling each
flips its visual state AND writes/removes the correct kanban_notify_subs
row (verified via direct DB read).
Tests (tests/plugins/test_kanban_dashboard_plugin.py, 11 new, 53/53
pass total):
- home-channels lists only platforms with a home (slack with a
token but no home is excluded)
- no task_id -> all subscribed=false
- subscribe creates notify_sub row with correct chat/thread/platform
- subscribed=true reflected in subsequent GET
- idempotent re-subscribe
- unknown platform -> 404
- unknown task -> 404
- unsubscribe removes the row
- telegram + discord subscribe/unsubscribe independent
- zero homes -> empty list
2026-05-04 12:31:21 -07:00
|
|
|
def _home_sub_matches(sub: dict, home: dict) -> bool:
|
|
|
|
|
"""True if a notify_subs row corresponds to the given home channel."""
|
|
|
|
|
return (
|
|
|
|
|
sub.get("platform") == home["platform"]
|
|
|
|
|
and str(sub.get("chat_id", "")) == str(home["chat_id"])
|
|
|
|
|
and str(sub.get("thread_id") or "") == str(home["thread_id"] or "")
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.get("/home-channels")
|
|
|
|
|
def get_home_channels(
|
|
|
|
|
task_id: Optional[str] = Query(None),
|
|
|
|
|
board: Optional[str] = Query(None),
|
|
|
|
|
):
|
|
|
|
|
"""List every platform with a home channel, plus whether *task_id*
|
|
|
|
|
(if given) is currently subscribed to that home.
|
|
|
|
|
|
|
|
|
|
When ``task_id`` is omitted, every entry's ``subscribed`` is ``false``
|
|
|
|
|
— useful for the "no task selected" state of the UI.
|
|
|
|
|
"""
|
|
|
|
|
homes = _configured_home_channels()
|
|
|
|
|
subscribed_homes: set[tuple[str, str, str]] = set()
|
|
|
|
|
if task_id:
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
|
|
|
|
try:
|
|
|
|
|
subs = kanban_db.list_notify_subs(conn, task_id)
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
for sub in subs:
|
|
|
|
|
key = (
|
|
|
|
|
str(sub.get("platform") or ""),
|
|
|
|
|
str(sub.get("chat_id") or ""),
|
|
|
|
|
str(sub.get("thread_id") or ""),
|
|
|
|
|
)
|
|
|
|
|
subscribed_homes.add(key)
|
|
|
|
|
result = []
|
|
|
|
|
for home in homes:
|
|
|
|
|
key = (home["platform"], home["chat_id"], home["thread_id"])
|
|
|
|
|
result.append({**home, "subscribed": key in subscribed_homes})
|
|
|
|
|
return {"home_channels": result}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.post("/tasks/{task_id}/home-subscribe/{platform}")
|
|
|
|
|
def subscribe_home(task_id: str, platform: str, board: Optional[str] = Query(None)):
|
|
|
|
|
"""Subscribe *task_id* to notifications routed to *platform*'s home channel.
|
|
|
|
|
|
|
|
|
|
Idempotent — re-subscribing is a no-op at the DB layer. 404 if the
|
|
|
|
|
platform has no home channel configured. 404 if the task doesn't exist.
|
|
|
|
|
"""
|
|
|
|
|
homes = _configured_home_channels()
|
|
|
|
|
home = next((h for h in homes if h["platform"] == platform), None)
|
|
|
|
|
if not home:
|
|
|
|
|
raise HTTPException(
|
|
|
|
|
status_code=404,
|
|
|
|
|
detail=f"No home channel configured for platform {platform!r}. "
|
|
|
|
|
f"Set one from the messenger via /sethome, or configure "
|
|
|
|
|
f"gateway.platforms.{platform}.home_channel in config.yaml.",
|
|
|
|
|
)
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
|
|
|
|
try:
|
|
|
|
|
task = kanban_db.get_task(conn, task_id)
|
|
|
|
|
if task is None:
|
|
|
|
|
raise HTTPException(status_code=404, detail=f"task {task_id} not found")
|
|
|
|
|
kanban_db.add_notify_sub(
|
|
|
|
|
conn,
|
|
|
|
|
task_id=task_id,
|
|
|
|
|
platform=platform,
|
|
|
|
|
chat_id=home["chat_id"],
|
|
|
|
|
thread_id=home["thread_id"] or None,
|
2026-05-18 20:14:39 -07:00
|
|
|
notifier_profile=_active_profile_name(),
|
feat(kanban-dashboard): per-platform home-channel notification toggles (#19864)
* revert: auto-subscribe gateway chat on tool-driven kanban_create (#19718)
Reverts ff3d2773e2. Teknium reviewed the merged PR and decided this
behavior isn't wanted — tool-driven kanban_create should not mirror
the slash-command path's auto-subscribe. Orchestrators that want
their originating chat notified can call kanban_notify-subscribe
explicitly; we're not going to make it implicit.
* feat(kanban-dashboard): per-platform home-channel notification toggles
Adds a "Notify home channels" section to the task drawer in the kanban
dashboard plugin. Each platform where the user has set a home channel
(/sethome, TELEGRAM_HOME_CHANNEL env var, gateway.platforms.<p>.home_channel
in config.yaml) gets a toggle pill. Toggling on writes a kanban_notify_subs
row keyed to that platform's home (chat_id + thread_id); toggling off
removes it. The existing gateway notifier watcher delivers completed /
blocked / gave_up events without any new plumbing — this is purely a GUI
surface over existing machinery.
Replaces the reverted auto-subscribe behavior from #19718 with an explicit,
per-task, per-platform, user-controlled opt-in. No implicit subscription
on tool-driven kanban_create; no CLI commands; no slash commands. Just a
toggle in the drawer.
Backend (plugins/kanban/dashboard/plugin_api.py):
- GET /api/plugins/kanban/home-channels[?task_id=X]
Returns every platform with a configured home, plus a per-entry
subscribed: bool relative to task_id (false when task_id omitted).
Reads the live GatewayConfig via load_gateway_config() so env-var
overlays stay honored.
- POST /api/plugins/kanban/tasks/:id/home-subscribe/:platform
Idempotent add_notify_sub keyed to the platform's home.
- DELETE /api/plugins/kanban/tasks/:id/home-subscribe/:platform
remove_notify_sub for the same tuple.
- 404 when the platform has no home configured, or task_id doesn't
exist (POST only).
Frontend (plugins/kanban/dashboard/dist/index.js):
- TaskDrawer fetches /home-channels on open, keyed on task_id.
- HomeSubsSection renders nothing when zero platforms have a home (so
users who haven't set one up don't see an empty UI block).
- Optimistic toggle with busy flag + revert-on-failure. One pill per
platform; ✓ prefix and --on class indicate the subscribed state.
CSS (plugins/kanban/dashboard/dist/style.css):
- .hermes-kanban-home-subs flex row + .hermes-kanban-home-sub pill
style + --on subscribed variant (subtle ring-colored background).
Live-tested against a dashboard with TELEGRAM + DISCORD_BOT_TOKEN /
HOME_CHANNEL env vars set: drawer shows both pills, toggling each
flips its visual state AND writes/removes the correct kanban_notify_subs
row (verified via direct DB read).
Tests (tests/plugins/test_kanban_dashboard_plugin.py, 11 new, 53/53
pass total):
- home-channels lists only platforms with a home (slack with a
token but no home is excluded)
- no task_id -> all subscribed=false
- subscribe creates notify_sub row with correct chat/thread/platform
- subscribed=true reflected in subsequent GET
- idempotent re-subscribe
- unknown platform -> 404
- unknown task -> 404
- unsubscribe removes the row
- telegram + discord subscribe/unsubscribe independent
- zero homes -> empty list
2026-05-04 12:31:21 -07:00
|
|
|
)
|
|
|
|
|
return {"ok": True, "task_id": task_id, "home_channel": home}
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.delete("/tasks/{task_id}/home-subscribe/{platform}")
|
|
|
|
|
def unsubscribe_home(task_id: str, platform: str, board: Optional[str] = Query(None)):
|
|
|
|
|
"""Remove any notify subscription on *task_id* that matches *platform*'s home."""
|
|
|
|
|
homes = _configured_home_channels()
|
|
|
|
|
home = next((h for h in homes if h["platform"] == platform), None)
|
|
|
|
|
if not home:
|
|
|
|
|
raise HTTPException(
|
|
|
|
|
status_code=404,
|
|
|
|
|
detail=f"No home channel configured for platform {platform!r}.",
|
|
|
|
|
)
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
|
|
|
|
try:
|
|
|
|
|
kanban_db.remove_notify_sub(
|
|
|
|
|
conn,
|
|
|
|
|
task_id=task_id,
|
|
|
|
|
platform=platform,
|
|
|
|
|
chat_id=home["chat_id"],
|
|
|
|
|
thread_id=home["thread_id"] or None,
|
|
|
|
|
)
|
|
|
|
|
return {"ok": True, "task_id": task_id, "home_channel": home}
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Stats (per-profile / per-status counts + oldest-ready age)
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
@router.get("/stats")
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
def get_stats(board: Optional[str] = Query(None)):
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
"""Per-status + per-assignee counts + oldest-ready age.
|
|
|
|
|
|
|
|
|
|
Designed for the dashboard HUD and for router profiles that need to
|
|
|
|
|
answer "is this specialist overloaded?" without scanning the whole
|
|
|
|
|
board themselves.
|
|
|
|
|
"""
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
try:
|
|
|
|
|
return kanban_db.board_stats(conn)
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.get("/assignees")
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
def get_assignees(board: Optional[str] = Query(None)):
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
"""Known profiles + per-profile task counts.
|
|
|
|
|
|
|
|
|
|
Returns the union of ``~/.hermes/profiles/*`` on disk and every
|
|
|
|
|
distinct assignee currently used on the board. The dashboard uses
|
|
|
|
|
this to populate its assignee dropdown so a freshly-created profile
|
|
|
|
|
appears in the picker before it's been given any task.
|
|
|
|
|
"""
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
try:
|
|
|
|
|
return {"assignees": kanban_db.known_assignees(conn)}
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Worker log (read-only; file written by _default_spawn)
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
@router.get("/tasks/{task_id}/log")
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
def get_task_log(
|
|
|
|
|
task_id: str,
|
|
|
|
|
tail: Optional[int] = Query(None, ge=1, le=2_000_000),
|
|
|
|
|
board: Optional[str] = Query(None),
|
|
|
|
|
):
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
"""Return the worker's stdout/stderr log.
|
|
|
|
|
|
|
|
|
|
``tail`` caps the response size (bytes) so the dashboard drawer
|
|
|
|
|
doesn't paginate megabytes into the browser. Returns 404 if the task
|
|
|
|
|
has never spawned. The on-disk log is rotated at 2 MiB per
|
|
|
|
|
``_rotate_worker_log`` — a single ``.log.1`` is kept, no further
|
|
|
|
|
generations, so disk usage per task is bounded at ~4 MiB.
|
|
|
|
|
"""
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
try:
|
|
|
|
|
task = kanban_db.get_task(conn, task_id)
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
if task is None:
|
|
|
|
|
raise HTTPException(status_code=404, detail=f"task {task_id} not found")
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
content = kanban_db.read_worker_log(task_id, tail_bytes=tail, board=board)
|
|
|
|
|
log_path = kanban_db.worker_log_path(task_id, board=board)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
size = log_path.stat().st_size if log_path.exists() else 0
|
|
|
|
|
return {
|
|
|
|
|
"task_id": task_id,
|
|
|
|
|
"path": str(log_path),
|
|
|
|
|
"exists": content is not None,
|
|
|
|
|
"size_bytes": size,
|
|
|
|
|
"content": content or "",
|
|
|
|
|
# Truncated when the on-disk file was larger than the tail cap.
|
|
|
|
|
"truncated": bool(tail and size > tail),
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Dispatch nudge (optional quick-path so the UI doesn't wait 60 s)
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
@router.post("/dispatch")
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
def dispatch(
|
|
|
|
|
dry_run: bool = Query(False),
|
|
|
|
|
max_n: int = Query(8, alias="max"),
|
|
|
|
|
board: Optional[str] = Query(None),
|
|
|
|
|
):
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
conn = _conn(board=board)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
try:
|
|
|
|
|
result = kanban_db.dispatch_once(
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
conn, dry_run=dry_run, max_spawn=max_n, board=board,
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
)
|
|
|
|
|
# DispatchResult is a dataclass.
|
|
|
|
|
try:
|
|
|
|
|
return asdict(result)
|
|
|
|
|
except TypeError:
|
|
|
|
|
return {"result": str(result)}
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Boards CRUD (multi-project support)
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
class CreateBoardBody(BaseModel):
|
|
|
|
|
slug: str
|
|
|
|
|
name: Optional[str] = None
|
|
|
|
|
description: Optional[str] = None
|
|
|
|
|
icon: Optional[str] = None
|
|
|
|
|
color: Optional[str] = None
|
|
|
|
|
switch: bool = False
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class RenameBoardBody(BaseModel):
|
|
|
|
|
name: Optional[str] = None
|
|
|
|
|
description: Optional[str] = None
|
|
|
|
|
icon: Optional[str] = None
|
|
|
|
|
color: Optional[str] = None
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def _board_counts(slug: str) -> dict[str, int]:
|
|
|
|
|
"""Return ``{status: count}`` for a board. Safe on an empty DB."""
|
|
|
|
|
try:
|
|
|
|
|
path = kanban_db.kanban_db_path(board=slug)
|
|
|
|
|
if not path.exists():
|
|
|
|
|
return {}
|
|
|
|
|
conn = kanban_db.connect(board=slug)
|
|
|
|
|
try:
|
|
|
|
|
rows = conn.execute(
|
|
|
|
|
"SELECT status, COUNT(*) AS n FROM tasks GROUP BY status"
|
|
|
|
|
).fetchall()
|
|
|
|
|
return {r["status"]: int(r["n"]) for r in rows}
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
except Exception:
|
|
|
|
|
return {}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.get("/boards")
|
|
|
|
|
def list_boards(include_archived: bool = Query(False)):
|
|
|
|
|
"""Return every board on disk with task counts and the active slug."""
|
|
|
|
|
boards = kanban_db.list_boards(include_archived=include_archived)
|
|
|
|
|
current = kanban_db.get_current_board()
|
|
|
|
|
for b in boards:
|
|
|
|
|
b["is_current"] = (b["slug"] == current)
|
|
|
|
|
b["counts"] = _board_counts(b["slug"])
|
|
|
|
|
b["total"] = sum(b["counts"].values())
|
|
|
|
|
return {"boards": boards, "current": current}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.post("/boards")
|
|
|
|
|
def create_board_endpoint(payload: CreateBoardBody):
|
|
|
|
|
"""Create a new board. Idempotent — ``slug`` collision returns existing."""
|
|
|
|
|
try:
|
|
|
|
|
meta = kanban_db.create_board(
|
|
|
|
|
payload.slug,
|
|
|
|
|
name=payload.name,
|
|
|
|
|
description=payload.description,
|
|
|
|
|
icon=payload.icon,
|
|
|
|
|
color=payload.color,
|
|
|
|
|
)
|
|
|
|
|
except ValueError as exc:
|
|
|
|
|
raise HTTPException(status_code=400, detail=str(exc))
|
|
|
|
|
if payload.switch:
|
|
|
|
|
try:
|
|
|
|
|
kanban_db.set_current_board(meta["slug"])
|
|
|
|
|
except ValueError as exc:
|
|
|
|
|
raise HTTPException(status_code=400, detail=str(exc))
|
|
|
|
|
return {"board": meta, "current": kanban_db.get_current_board()}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.patch("/boards/{slug}")
|
|
|
|
|
def rename_board(slug: str, payload: RenameBoardBody):
|
|
|
|
|
"""Update a board's display metadata (slug is immutable — create a new one to rename the directory)."""
|
|
|
|
|
try:
|
|
|
|
|
normed = kanban_db._normalize_board_slug(slug)
|
|
|
|
|
except ValueError as exc:
|
|
|
|
|
raise HTTPException(status_code=400, detail=str(exc))
|
|
|
|
|
if not normed or not kanban_db.board_exists(normed):
|
|
|
|
|
raise HTTPException(status_code=404, detail=f"board {slug!r} does not exist")
|
|
|
|
|
meta = kanban_db.write_board_metadata(
|
|
|
|
|
normed,
|
|
|
|
|
name=payload.name,
|
|
|
|
|
description=payload.description,
|
|
|
|
|
icon=payload.icon,
|
|
|
|
|
color=payload.color,
|
|
|
|
|
)
|
|
|
|
|
return {"board": meta}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.delete("/boards/{slug}")
|
|
|
|
|
def delete_board(slug: str, delete: bool = Query(False, description="Hard-delete instead of archive")):
|
|
|
|
|
"""Archive (default) or hard-delete a board."""
|
|
|
|
|
try:
|
|
|
|
|
res = kanban_db.remove_board(slug, archive=not delete)
|
|
|
|
|
except ValueError as exc:
|
|
|
|
|
raise HTTPException(status_code=400, detail=str(exc))
|
|
|
|
|
return {"result": res, "current": kanban_db.get_current_board()}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.post("/boards/{slug}/switch")
|
|
|
|
|
def switch_board(slug: str):
|
|
|
|
|
"""Persist ``slug`` as the active board for subsequent CLI / slash calls.
|
|
|
|
|
|
|
|
|
|
Dashboard users pick boards via a client-side ``localStorage`` — this
|
|
|
|
|
endpoint is for ``/kanban boards switch`` parity so gateway slash
|
|
|
|
|
commands and the CLI share the same current-board pointer.
|
|
|
|
|
"""
|
|
|
|
|
try:
|
|
|
|
|
normed = kanban_db._normalize_board_slug(slug)
|
|
|
|
|
except ValueError as exc:
|
|
|
|
|
raise HTTPException(status_code=400, detail=str(exc))
|
|
|
|
|
if not normed or not kanban_db.board_exists(normed):
|
|
|
|
|
raise HTTPException(status_code=404, detail=f"board {slug!r} does not exist")
|
|
|
|
|
kanban_db.set_current_board(normed)
|
|
|
|
|
return {"current": normed}
|
|
|
|
|
|
|
|
|
|
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# WebSocket: /events?since=<event_id>
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
# Poll interval for the event tail loop. SQLite WAL + 300 ms polling is
|
|
|
|
|
# the simplest and most robust approach; it adds a fraction of a percent
|
|
|
|
|
# of CPU and has no shared state to synchronize across workers.
|
|
|
|
|
_EVENT_POLL_SECONDS = 0.3
|
|
|
|
|
|
|
|
|
|
|
feat(kanban): orchestrator-driven auto-decomposition on triage (#27572)
* feat(kanban): orchestrator-driven auto-decomposition on triage
Closes the core gap in the kanban system: dropping a one-liner into Triage
now decomposes it into a graph of child tasks routed to specialist
profiles by description, matching teknium's original vision ("main
orchestrator splits/creates actual tasks, doles them out to each agent").
The build
---------
- hermes_cli/profiles.py: new `description` + `description_auto` fields
on ProfileInfo, persisted in <profile_dir>/profile.yaml. Helpers
read_profile_meta / write_profile_meta. `create_profile` accepts
optional description.
- hermes_cli/profile_describer.py: new module — auto-generate a 1-2
sentence description from a profile's skills + model + name via the
auxiliary LLM (`auxiliary.profile_describer`).
- hermes_cli/main.py: new `hermes profile create --description ...`
flag; new `hermes profile describe [name] [--text ... | --auto |
--all --auto]` subcommand.
- hermes_cli/kanban_db.py: new `decompose_triage_task` atomic helper —
creates N child tasks, links the root as a child of every leaf
(root waits for the whole graph), flips root `triage -> todo` with
orchestrator assignee, records an audit comment + `decomposed` event
in a single write_txn.
- hermes_cli/kanban_decompose.py: new module — calls the auxiliary LLM
(`auxiliary.kanban_decomposer`) with the profile roster + descriptions
to produce a JSON task graph, then invokes the DB helper. Rewrites
unknown assignees to the configured `kanban.default_assignee` (or
the active default profile) so a task NEVER lands with assignee=None.
Falls back to specify-style single-task promotion when the LLM
returns `fanout: false`.
- hermes_cli/kanban.py: new `hermes kanban decompose [task_id | --all]`
CLI verb.
- hermes_cli/config.py: new DEFAULT_CONFIG keys —
kanban.orchestrator_profile, kanban.default_assignee,
kanban.auto_decompose (default True), kanban.auto_decompose_per_tick
(default 3), auxiliary.kanban_decomposer, auxiliary.profile_describer.
- gateway/run.py: kanban dispatcher watcher now runs auto-decompose
before each `_tick_once`, capped by `auto_decompose_per_tick` so a
bulk-load of triage tasks doesn't burst-spend the aux LLM.
- plugins/kanban/dashboard/plugin_api.py: new endpoints —
GET /profiles (list roster + descriptions),
PATCH /profiles/<name> (set description, user-authored),
POST /profiles/<name>/describe-auto (LLM-generate),
POST /tasks/<id>/decompose (run decomposer),
GET/PUT /orchestration (orchestrator/default-assignee/auto-decompose
pickers, with resolved fallbacks echoed back).
- plugins/kanban/dashboard/dist/index.js: new OrchestrationPanel
collapsible — dropdowns for orchestrator profile and default
assignee, auto-decompose toggle, per-profile description editor with
Save and Auto-generate buttons. New ⚗ Decompose button next to
✨ Specify on triage-column task drawers.
Behavior
--------
- A task in Triage gets fanned out into a small DAG of child tasks.
Children with no internal parents flip to `ready` immediately
(parallel dispatch). Children with sibling parents wait. The root
stays alive as a parent of every child — when the whole graph
finishes, it promotes to `ready` and the orchestrator profile wakes
back up to judge completion (the "adds more tasks until done" part
of the original vision).
- `kanban.orchestrator_profile` unset -> falls back to the default
profile (whichever `hermes` launches with no -p flag).
- `kanban.default_assignee` unset -> same fallback. Tasks NEVER end
up unassigned.
- `kanban.auto_decompose=true` (default) runs the decomposer
automatically on dispatcher ticks; manual `hermes kanban decompose`
is always available.
Tests
-----
- tests/hermes_cli/test_kanban_decompose_db.py — 7 tests for the
atomic DB helper (status transitions, dep graph, audit trail,
validation errors).
- tests/hermes_cli/test_kanban_decompose.py — 6 tests for the
decomposer module (fanout, no-fanout fallback, unknown-assignee
rewrite, malformed-JSON resilience, no-aux-client path).
- tests/hermes_cli/test_profile_describer.py — 10 tests for
profile.yaml r/w + the LLM auto-describer (yaml corrupt tolerance,
user-vs-auto description protection, --overwrite, fallback parsing).
E2E
---
- CLI end-to-end: created profiles with descriptions, dropped a triage
task, mocked the aux LLM with a 3-task graph -> verified all three
children were created with the right assignees, the dependency
edges matched the LLM's graph, root flipped to todo gated by every
child, audit comment + `decomposed` event recorded.
- Dashboard end-to-end: started the dashboard against an isolated
HERMES_HOME, verified all four new endpoints via curl (profile
listing, PATCH for description, PUT for orchestration settings,
POST for decompose). Opened the UI in the browser, confirmed the
OrchestrationPanel renders with all three pickers + the per-profile
description editor, typed a description, clicked Save, verified
~/.hermes/profile.yaml was written. Clicked Decompose on the triage
card and confirmed the inline error message surfaced as designed
("no auxiliary client configured").
* feat(kanban): surface decompose mode (Auto/Manual) as a one-click pill
The auto/manual toggle already existed as kanban.auto_decompose (default
true), but it was buried inside the collapsed Orchestration settings
panel — users couldn't tell at a glance which mode they were in. This
hoists it to a pill at the top of the kanban page so the state is always
visible and one click flips it.
UX
- New "⚗ Decompose: AUTO|MANUAL" pill in the kanban header. Emerald
styling when Auto is on (the default), muted/gray when Manual.
- Pill is visible both in the collapsed AND expanded Orchestration
settings views so context is preserved when the user opens the panel.
- Tooltip explains both states + what clicking does.
- Renamed the in-panel "Auto-decompose on triage / Enabled" checkbox
to "Decompose mode / Auto (default) | Manual" for language parity
with the pill.
Behavior preserved
- Default remains Auto (kanban.auto_decompose=true).
- Manual mode restores pre-PR behavior: triage tasks stay in triage
until the user clicks ⚗ Decompose on each card (or runs
`hermes kanban decompose <id>`).
Implementation
- plugins/kanban/dashboard/dist/index.js: load /orchestration on mount
(not just on expand) so the collapsed pill reflects real state.
Render mode pill in both collapsed and expanded headers. Reuses the
existing PUT /api/plugins/kanban/orchestration endpoint — no new
backend, no new tests required.
E2E verified
- Pill renders as "⚗ Decompose: AUTO" on page load (default).
- One click flips to "⚗ Decompose: MANUAL" with muted styling.
- config.yaml on disk shows auto_decompose: false after the flip.
- Second click round-trips back to Auto; config.yaml flips to true.
* feat(kanban): rename mode pill to "Orchestration: Auto/Manual"
Per Teknium feedback — "Decompose" was too implementation-specific.
"Orchestration" is the user-facing concept (the whole pitch is the
orchestrator profile routing work), and the pill is the front door to it.
- Pill text: "Orchestration: Auto" / "Orchestration: Manual" (title case,
no ⚗ prefix, no SHOUTY-CAPS for the mode value)
- In-panel checkbox label: "Orchestration mode" (was "Decompose mode")
- Tooltips updated to match
- No behavior change
* docs(kanban): document decompose, profile descriptions, orchestration mode
Brings the docs site up to parity with the PR. English build verified
locally (npx docusaurus build --locale en) — clean, no new broken links
or anchors. Pre-existing broken-link warnings (rl-training, llms.txt,
step-by-step-checklist, fallback-model) untouched.
- website/docs/reference/cli-commands.md
+ `hermes kanban decompose` action row in the action table, with
pointer to the Auto vs Manual orchestration section.
- website/docs/reference/profile-commands.md
+ `--description "<text>"` flag on `hermes profile create`.
+ Full `hermes profile describe` section: read, --text, --auto,
--overwrite, --all flags with examples.
- website/docs/user-guide/features/kanban.md (the big one)
+ Triage column intro rewritten around the Auto-decompose default
behavior, with pointer to the new Auto vs Manual section.
+ Status action row updated to mention both ⚗ Decompose and
✨ Specify on triage cards.
+ New "Auto vs Manual orchestration" section explaining the two
modes, how to flip them (pill, config), how routing-by-description
works, the no-None-assignee guarantee, plus a config knob table
(auto_decompose, auto_decompose_per_tick, orchestrator_profile,
default_assignee) and the two new auxiliary slots
(kanban_decomposer, profile_describer).
+ REST surface table gains 6 new endpoint rows: /tasks/:id/decompose,
/profiles (GET), /profiles/:name (PATCH), /profiles/:name/describe-auto,
/orchestration (GET + PUT).
- website/docs/user-guide/features/kanban-tutorial.md
+ Triage column blurb updated for Auto by default + Manual via the
pill, with cross-link to the Auto vs Manual orchestration section.
- website/docs/user-guide/profiles.md
+ Blank-profile flow now mentions --description and points to the
kanban routing model for context.
- website/docs/user-guide/configuration.md
+ `kanban_decomposer` and `profile_describer` added to the
`hermes model -> Configure auxiliary models` menu listing.
2026-05-17 13:54:12 -07:00
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Profile metadata & description editing (consumed by the kanban orchestrator)
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
class DescribeBody(BaseModel):
|
|
|
|
|
description: Optional[str] = None # explicit user-authored text
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class DescribeAutoBody(BaseModel):
|
|
|
|
|
overwrite: bool = False
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.get("/profiles")
|
|
|
|
|
def list_profile_roster():
|
|
|
|
|
"""Return every installed profile with its description.
|
|
|
|
|
|
|
|
|
|
Consumed by the dashboard's settings panel (orchestrator picker)
|
|
|
|
|
and the profile-description editing UI. Profiles without a
|
|
|
|
|
description still appear here — they're routable on name alone,
|
|
|
|
|
just less precisely.
|
|
|
|
|
"""
|
|
|
|
|
try:
|
|
|
|
|
from hermes_cli import profiles as profiles_mod
|
|
|
|
|
profiles = profiles_mod.list_profiles()
|
|
|
|
|
except Exception as exc:
|
|
|
|
|
raise HTTPException(status_code=500, detail=f"failed to list profiles: {exc}")
|
|
|
|
|
return {
|
|
|
|
|
"profiles": [
|
|
|
|
|
{
|
|
|
|
|
"name": p.name,
|
|
|
|
|
"is_default": bool(p.is_default),
|
|
|
|
|
"model": p.model or "",
|
|
|
|
|
"provider": p.provider or "",
|
|
|
|
|
"description": p.description or "",
|
|
|
|
|
"description_auto": bool(p.description_auto),
|
|
|
|
|
"skill_count": int(p.skill_count or 0),
|
|
|
|
|
}
|
|
|
|
|
for p in profiles
|
|
|
|
|
],
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.patch("/profiles/{profile_name}")
|
|
|
|
|
def update_profile_description(profile_name: str, payload: DescribeBody):
|
|
|
|
|
"""Set or clear the description of a profile.
|
|
|
|
|
|
|
|
|
|
Empty string clears the description; non-empty stores it as a
|
|
|
|
|
user-authored description (``description_auto: false``) so the
|
|
|
|
|
auto-describer won't overwrite it on a sweep without
|
|
|
|
|
``--overwrite``.
|
|
|
|
|
"""
|
|
|
|
|
try:
|
|
|
|
|
from hermes_cli import profiles as profiles_mod
|
|
|
|
|
canon = profiles_mod.normalize_profile_name(profile_name)
|
|
|
|
|
if canon == "default":
|
|
|
|
|
from hermes_constants import get_hermes_home # type: ignore
|
|
|
|
|
from pathlib import Path as _Path
|
|
|
|
|
profile_dir = _Path(get_hermes_home())
|
|
|
|
|
else:
|
|
|
|
|
profile_dir = profiles_mod.get_profile_dir(canon)
|
|
|
|
|
if not profile_dir.is_dir():
|
|
|
|
|
raise HTTPException(status_code=404, detail=f"profile '{profile_name}' not found")
|
|
|
|
|
text = (payload.description or "").strip()
|
|
|
|
|
profiles_mod.write_profile_meta(
|
|
|
|
|
profile_dir,
|
|
|
|
|
description=text,
|
|
|
|
|
description_auto=False,
|
|
|
|
|
)
|
|
|
|
|
except HTTPException:
|
|
|
|
|
raise
|
|
|
|
|
except Exception as exc:
|
|
|
|
|
raise HTTPException(status_code=500, detail=f"failed to update profile: {exc}")
|
|
|
|
|
return {"ok": True, "profile": canon, "description": text}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.post("/profiles/{profile_name}/describe-auto")
|
|
|
|
|
def auto_describe_profile(profile_name: str, payload: DescribeAutoBody):
|
|
|
|
|
"""Generate a description for the named profile via the auxiliary
|
|
|
|
|
LLM (``auxiliary.profile_describer``). Persists with
|
|
|
|
|
``description_auto: true`` so the dashboard can surface a "review"
|
|
|
|
|
badge.
|
|
|
|
|
|
|
|
|
|
Maps 1:1 to ``hermes profile describe <name> --auto``. Non-OK
|
|
|
|
|
outcomes are NOT HTTP errors — the UI renders the reason inline
|
|
|
|
|
(e.g. "no auxiliary client configured") so the operator can fix
|
|
|
|
|
config and retry without a page reload.
|
|
|
|
|
"""
|
|
|
|
|
try:
|
|
|
|
|
from hermes_cli import profile_describer # noqa: WPS433 (intentional)
|
|
|
|
|
outcome = profile_describer.describe_profile(
|
|
|
|
|
profile_name,
|
|
|
|
|
overwrite=bool(payload.overwrite),
|
|
|
|
|
)
|
|
|
|
|
except Exception as exc:
|
|
|
|
|
raise HTTPException(status_code=500, detail=f"describer crashed: {exc}")
|
|
|
|
|
return {
|
|
|
|
|
"ok": bool(outcome.ok),
|
|
|
|
|
"profile": outcome.profile_name,
|
|
|
|
|
"reason": outcome.reason,
|
|
|
|
|
"description": outcome.description,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Decompose endpoint (orchestrator-driven fan-out)
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
class DecomposeBody(BaseModel):
|
|
|
|
|
author: Optional[str] = None
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.post("/tasks/{task_id}/decompose")
|
|
|
|
|
def decompose_task_endpoint(
|
|
|
|
|
task_id: str,
|
|
|
|
|
payload: DecomposeBody,
|
|
|
|
|
board: Optional[str] = Query(None),
|
|
|
|
|
):
|
|
|
|
|
"""Fan a triage-column task out into a graph of child tasks via the
|
|
|
|
|
auxiliary LLM, routed to specialist profiles by description. Maps
|
|
|
|
|
1:1 to ``hermes kanban decompose <task_id>``.
|
|
|
|
|
|
|
|
|
|
Returns the outcome shape used by the CLI: ``{ok, task_id, reason,
|
|
|
|
|
fanout, child_ids, new_title}``. A non-OK outcome is NOT an HTTP
|
|
|
|
|
error — the UI renders the reason inline.
|
|
|
|
|
|
|
|
|
|
Runs in FastAPI's threadpool (sync ``def``) because the LLM call
|
|
|
|
|
can take minutes on reasoning models.
|
|
|
|
|
"""
|
|
|
|
|
board = _resolve_board(board)
|
|
|
|
|
prev_env = os.environ.get("HERMES_KANBAN_BOARD")
|
|
|
|
|
try:
|
|
|
|
|
os.environ["HERMES_KANBAN_BOARD"] = board or kanban_db.DEFAULT_BOARD
|
|
|
|
|
from hermes_cli import kanban_decompose # noqa: WPS433 (intentional)
|
|
|
|
|
outcome = kanban_decompose.decompose_task(
|
|
|
|
|
task_id,
|
|
|
|
|
author=(payload.author or None),
|
|
|
|
|
)
|
|
|
|
|
finally:
|
|
|
|
|
if prev_env is None:
|
|
|
|
|
os.environ.pop("HERMES_KANBAN_BOARD", None)
|
|
|
|
|
else:
|
|
|
|
|
os.environ["HERMES_KANBAN_BOARD"] = prev_env
|
|
|
|
|
|
|
|
|
|
return {
|
|
|
|
|
"ok": bool(outcome.ok),
|
|
|
|
|
"task_id": outcome.task_id,
|
|
|
|
|
"reason": outcome.reason,
|
|
|
|
|
"fanout": bool(outcome.fanout),
|
|
|
|
|
"child_ids": outcome.child_ids or [],
|
|
|
|
|
"new_title": outcome.new_title,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Orchestration settings (kanban.orchestrator_profile / default_assignee /
|
|
|
|
|
# auto_decompose) — surfaced to the dashboard's settings panel
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
class OrchestrationSettingsBody(BaseModel):
|
|
|
|
|
orchestrator_profile: Optional[str] = None
|
|
|
|
|
default_assignee: Optional[str] = None
|
|
|
|
|
auto_decompose: Optional[bool] = None
|
2026-05-18 20:04:26 -07:00
|
|
|
auto_promote_children: Optional[bool] = None
|
feat(kanban): orchestrator-driven auto-decomposition on triage (#27572)
* feat(kanban): orchestrator-driven auto-decomposition on triage
Closes the core gap in the kanban system: dropping a one-liner into Triage
now decomposes it into a graph of child tasks routed to specialist
profiles by description, matching teknium's original vision ("main
orchestrator splits/creates actual tasks, doles them out to each agent").
The build
---------
- hermes_cli/profiles.py: new `description` + `description_auto` fields
on ProfileInfo, persisted in <profile_dir>/profile.yaml. Helpers
read_profile_meta / write_profile_meta. `create_profile` accepts
optional description.
- hermes_cli/profile_describer.py: new module — auto-generate a 1-2
sentence description from a profile's skills + model + name via the
auxiliary LLM (`auxiliary.profile_describer`).
- hermes_cli/main.py: new `hermes profile create --description ...`
flag; new `hermes profile describe [name] [--text ... | --auto |
--all --auto]` subcommand.
- hermes_cli/kanban_db.py: new `decompose_triage_task` atomic helper —
creates N child tasks, links the root as a child of every leaf
(root waits for the whole graph), flips root `triage -> todo` with
orchestrator assignee, records an audit comment + `decomposed` event
in a single write_txn.
- hermes_cli/kanban_decompose.py: new module — calls the auxiliary LLM
(`auxiliary.kanban_decomposer`) with the profile roster + descriptions
to produce a JSON task graph, then invokes the DB helper. Rewrites
unknown assignees to the configured `kanban.default_assignee` (or
the active default profile) so a task NEVER lands with assignee=None.
Falls back to specify-style single-task promotion when the LLM
returns `fanout: false`.
- hermes_cli/kanban.py: new `hermes kanban decompose [task_id | --all]`
CLI verb.
- hermes_cli/config.py: new DEFAULT_CONFIG keys —
kanban.orchestrator_profile, kanban.default_assignee,
kanban.auto_decompose (default True), kanban.auto_decompose_per_tick
(default 3), auxiliary.kanban_decomposer, auxiliary.profile_describer.
- gateway/run.py: kanban dispatcher watcher now runs auto-decompose
before each `_tick_once`, capped by `auto_decompose_per_tick` so a
bulk-load of triage tasks doesn't burst-spend the aux LLM.
- plugins/kanban/dashboard/plugin_api.py: new endpoints —
GET /profiles (list roster + descriptions),
PATCH /profiles/<name> (set description, user-authored),
POST /profiles/<name>/describe-auto (LLM-generate),
POST /tasks/<id>/decompose (run decomposer),
GET/PUT /orchestration (orchestrator/default-assignee/auto-decompose
pickers, with resolved fallbacks echoed back).
- plugins/kanban/dashboard/dist/index.js: new OrchestrationPanel
collapsible — dropdowns for orchestrator profile and default
assignee, auto-decompose toggle, per-profile description editor with
Save and Auto-generate buttons. New ⚗ Decompose button next to
✨ Specify on triage-column task drawers.
Behavior
--------
- A task in Triage gets fanned out into a small DAG of child tasks.
Children with no internal parents flip to `ready` immediately
(parallel dispatch). Children with sibling parents wait. The root
stays alive as a parent of every child — when the whole graph
finishes, it promotes to `ready` and the orchestrator profile wakes
back up to judge completion (the "adds more tasks until done" part
of the original vision).
- `kanban.orchestrator_profile` unset -> falls back to the default
profile (whichever `hermes` launches with no -p flag).
- `kanban.default_assignee` unset -> same fallback. Tasks NEVER end
up unassigned.
- `kanban.auto_decompose=true` (default) runs the decomposer
automatically on dispatcher ticks; manual `hermes kanban decompose`
is always available.
Tests
-----
- tests/hermes_cli/test_kanban_decompose_db.py — 7 tests for the
atomic DB helper (status transitions, dep graph, audit trail,
validation errors).
- tests/hermes_cli/test_kanban_decompose.py — 6 tests for the
decomposer module (fanout, no-fanout fallback, unknown-assignee
rewrite, malformed-JSON resilience, no-aux-client path).
- tests/hermes_cli/test_profile_describer.py — 10 tests for
profile.yaml r/w + the LLM auto-describer (yaml corrupt tolerance,
user-vs-auto description protection, --overwrite, fallback parsing).
E2E
---
- CLI end-to-end: created profiles with descriptions, dropped a triage
task, mocked the aux LLM with a 3-task graph -> verified all three
children were created with the right assignees, the dependency
edges matched the LLM's graph, root flipped to todo gated by every
child, audit comment + `decomposed` event recorded.
- Dashboard end-to-end: started the dashboard against an isolated
HERMES_HOME, verified all four new endpoints via curl (profile
listing, PATCH for description, PUT for orchestration settings,
POST for decompose). Opened the UI in the browser, confirmed the
OrchestrationPanel renders with all three pickers + the per-profile
description editor, typed a description, clicked Save, verified
~/.hermes/profile.yaml was written. Clicked Decompose on the triage
card and confirmed the inline error message surfaced as designed
("no auxiliary client configured").
* feat(kanban): surface decompose mode (Auto/Manual) as a one-click pill
The auto/manual toggle already existed as kanban.auto_decompose (default
true), but it was buried inside the collapsed Orchestration settings
panel — users couldn't tell at a glance which mode they were in. This
hoists it to a pill at the top of the kanban page so the state is always
visible and one click flips it.
UX
- New "⚗ Decompose: AUTO|MANUAL" pill in the kanban header. Emerald
styling when Auto is on (the default), muted/gray when Manual.
- Pill is visible both in the collapsed AND expanded Orchestration
settings views so context is preserved when the user opens the panel.
- Tooltip explains both states + what clicking does.
- Renamed the in-panel "Auto-decompose on triage / Enabled" checkbox
to "Decompose mode / Auto (default) | Manual" for language parity
with the pill.
Behavior preserved
- Default remains Auto (kanban.auto_decompose=true).
- Manual mode restores pre-PR behavior: triage tasks stay in triage
until the user clicks ⚗ Decompose on each card (or runs
`hermes kanban decompose <id>`).
Implementation
- plugins/kanban/dashboard/dist/index.js: load /orchestration on mount
(not just on expand) so the collapsed pill reflects real state.
Render mode pill in both collapsed and expanded headers. Reuses the
existing PUT /api/plugins/kanban/orchestration endpoint — no new
backend, no new tests required.
E2E verified
- Pill renders as "⚗ Decompose: AUTO" on page load (default).
- One click flips to "⚗ Decompose: MANUAL" with muted styling.
- config.yaml on disk shows auto_decompose: false after the flip.
- Second click round-trips back to Auto; config.yaml flips to true.
* feat(kanban): rename mode pill to "Orchestration: Auto/Manual"
Per Teknium feedback — "Decompose" was too implementation-specific.
"Orchestration" is the user-facing concept (the whole pitch is the
orchestrator profile routing work), and the pill is the front door to it.
- Pill text: "Orchestration: Auto" / "Orchestration: Manual" (title case,
no ⚗ prefix, no SHOUTY-CAPS for the mode value)
- In-panel checkbox label: "Orchestration mode" (was "Decompose mode")
- Tooltips updated to match
- No behavior change
* docs(kanban): document decompose, profile descriptions, orchestration mode
Brings the docs site up to parity with the PR. English build verified
locally (npx docusaurus build --locale en) — clean, no new broken links
or anchors. Pre-existing broken-link warnings (rl-training, llms.txt,
step-by-step-checklist, fallback-model) untouched.
- website/docs/reference/cli-commands.md
+ `hermes kanban decompose` action row in the action table, with
pointer to the Auto vs Manual orchestration section.
- website/docs/reference/profile-commands.md
+ `--description "<text>"` flag on `hermes profile create`.
+ Full `hermes profile describe` section: read, --text, --auto,
--overwrite, --all flags with examples.
- website/docs/user-guide/features/kanban.md (the big one)
+ Triage column intro rewritten around the Auto-decompose default
behavior, with pointer to the new Auto vs Manual section.
+ Status action row updated to mention both ⚗ Decompose and
✨ Specify on triage cards.
+ New "Auto vs Manual orchestration" section explaining the two
modes, how to flip them (pill, config), how routing-by-description
works, the no-None-assignee guarantee, plus a config knob table
(auto_decompose, auto_decompose_per_tick, orchestrator_profile,
default_assignee) and the two new auxiliary slots
(kanban_decomposer, profile_describer).
+ REST surface table gains 6 new endpoint rows: /tasks/:id/decompose,
/profiles (GET), /profiles/:name (PATCH), /profiles/:name/describe-auto,
/orchestration (GET + PUT).
- website/docs/user-guide/features/kanban-tutorial.md
+ Triage column blurb updated for Auto by default + Manual via the
pill, with cross-link to the Auto vs Manual orchestration section.
- website/docs/user-guide/profiles.md
+ Blank-profile flow now mentions --description and points to the
kanban routing model for context.
- website/docs/user-guide/configuration.md
+ `kanban_decomposer` and `profile_describer` added to the
`hermes model -> Configure auxiliary models` menu listing.
2026-05-17 13:54:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.get("/orchestration")
|
|
|
|
|
def get_orchestration_settings():
|
|
|
|
|
"""Return the current kanban orchestration knobs from config.yaml
|
|
|
|
|
plus the resolved effective values (filling in fallbacks)."""
|
|
|
|
|
try:
|
|
|
|
|
from hermes_cli.config import load_config
|
|
|
|
|
cfg = load_config() or {}
|
|
|
|
|
except Exception:
|
|
|
|
|
cfg = {}
|
|
|
|
|
kanban_cfg = (cfg.get("kanban") or {}) if isinstance(cfg, dict) else {}
|
|
|
|
|
explicit_orch = (kanban_cfg.get("orchestrator_profile") or "").strip()
|
|
|
|
|
explicit_default = (kanban_cfg.get("default_assignee") or "").strip()
|
|
|
|
|
auto_decompose = bool(kanban_cfg.get("auto_decompose", True))
|
2026-05-18 20:04:26 -07:00
|
|
|
auto_promote_children = bool(kanban_cfg.get("auto_promote_children", True))
|
feat(kanban): orchestrator-driven auto-decomposition on triage (#27572)
* feat(kanban): orchestrator-driven auto-decomposition on triage
Closes the core gap in the kanban system: dropping a one-liner into Triage
now decomposes it into a graph of child tasks routed to specialist
profiles by description, matching teknium's original vision ("main
orchestrator splits/creates actual tasks, doles them out to each agent").
The build
---------
- hermes_cli/profiles.py: new `description` + `description_auto` fields
on ProfileInfo, persisted in <profile_dir>/profile.yaml. Helpers
read_profile_meta / write_profile_meta. `create_profile` accepts
optional description.
- hermes_cli/profile_describer.py: new module — auto-generate a 1-2
sentence description from a profile's skills + model + name via the
auxiliary LLM (`auxiliary.profile_describer`).
- hermes_cli/main.py: new `hermes profile create --description ...`
flag; new `hermes profile describe [name] [--text ... | --auto |
--all --auto]` subcommand.
- hermes_cli/kanban_db.py: new `decompose_triage_task` atomic helper —
creates N child tasks, links the root as a child of every leaf
(root waits for the whole graph), flips root `triage -> todo` with
orchestrator assignee, records an audit comment + `decomposed` event
in a single write_txn.
- hermes_cli/kanban_decompose.py: new module — calls the auxiliary LLM
(`auxiliary.kanban_decomposer`) with the profile roster + descriptions
to produce a JSON task graph, then invokes the DB helper. Rewrites
unknown assignees to the configured `kanban.default_assignee` (or
the active default profile) so a task NEVER lands with assignee=None.
Falls back to specify-style single-task promotion when the LLM
returns `fanout: false`.
- hermes_cli/kanban.py: new `hermes kanban decompose [task_id | --all]`
CLI verb.
- hermes_cli/config.py: new DEFAULT_CONFIG keys —
kanban.orchestrator_profile, kanban.default_assignee,
kanban.auto_decompose (default True), kanban.auto_decompose_per_tick
(default 3), auxiliary.kanban_decomposer, auxiliary.profile_describer.
- gateway/run.py: kanban dispatcher watcher now runs auto-decompose
before each `_tick_once`, capped by `auto_decompose_per_tick` so a
bulk-load of triage tasks doesn't burst-spend the aux LLM.
- plugins/kanban/dashboard/plugin_api.py: new endpoints —
GET /profiles (list roster + descriptions),
PATCH /profiles/<name> (set description, user-authored),
POST /profiles/<name>/describe-auto (LLM-generate),
POST /tasks/<id>/decompose (run decomposer),
GET/PUT /orchestration (orchestrator/default-assignee/auto-decompose
pickers, with resolved fallbacks echoed back).
- plugins/kanban/dashboard/dist/index.js: new OrchestrationPanel
collapsible — dropdowns for orchestrator profile and default
assignee, auto-decompose toggle, per-profile description editor with
Save and Auto-generate buttons. New ⚗ Decompose button next to
✨ Specify on triage-column task drawers.
Behavior
--------
- A task in Triage gets fanned out into a small DAG of child tasks.
Children with no internal parents flip to `ready` immediately
(parallel dispatch). Children with sibling parents wait. The root
stays alive as a parent of every child — when the whole graph
finishes, it promotes to `ready` and the orchestrator profile wakes
back up to judge completion (the "adds more tasks until done" part
of the original vision).
- `kanban.orchestrator_profile` unset -> falls back to the default
profile (whichever `hermes` launches with no -p flag).
- `kanban.default_assignee` unset -> same fallback. Tasks NEVER end
up unassigned.
- `kanban.auto_decompose=true` (default) runs the decomposer
automatically on dispatcher ticks; manual `hermes kanban decompose`
is always available.
Tests
-----
- tests/hermes_cli/test_kanban_decompose_db.py — 7 tests for the
atomic DB helper (status transitions, dep graph, audit trail,
validation errors).
- tests/hermes_cli/test_kanban_decompose.py — 6 tests for the
decomposer module (fanout, no-fanout fallback, unknown-assignee
rewrite, malformed-JSON resilience, no-aux-client path).
- tests/hermes_cli/test_profile_describer.py — 10 tests for
profile.yaml r/w + the LLM auto-describer (yaml corrupt tolerance,
user-vs-auto description protection, --overwrite, fallback parsing).
E2E
---
- CLI end-to-end: created profiles with descriptions, dropped a triage
task, mocked the aux LLM with a 3-task graph -> verified all three
children were created with the right assignees, the dependency
edges matched the LLM's graph, root flipped to todo gated by every
child, audit comment + `decomposed` event recorded.
- Dashboard end-to-end: started the dashboard against an isolated
HERMES_HOME, verified all four new endpoints via curl (profile
listing, PATCH for description, PUT for orchestration settings,
POST for decompose). Opened the UI in the browser, confirmed the
OrchestrationPanel renders with all three pickers + the per-profile
description editor, typed a description, clicked Save, verified
~/.hermes/profile.yaml was written. Clicked Decompose on the triage
card and confirmed the inline error message surfaced as designed
("no auxiliary client configured").
* feat(kanban): surface decompose mode (Auto/Manual) as a one-click pill
The auto/manual toggle already existed as kanban.auto_decompose (default
true), but it was buried inside the collapsed Orchestration settings
panel — users couldn't tell at a glance which mode they were in. This
hoists it to a pill at the top of the kanban page so the state is always
visible and one click flips it.
UX
- New "⚗ Decompose: AUTO|MANUAL" pill in the kanban header. Emerald
styling when Auto is on (the default), muted/gray when Manual.
- Pill is visible both in the collapsed AND expanded Orchestration
settings views so context is preserved when the user opens the panel.
- Tooltip explains both states + what clicking does.
- Renamed the in-panel "Auto-decompose on triage / Enabled" checkbox
to "Decompose mode / Auto (default) | Manual" for language parity
with the pill.
Behavior preserved
- Default remains Auto (kanban.auto_decompose=true).
- Manual mode restores pre-PR behavior: triage tasks stay in triage
until the user clicks ⚗ Decompose on each card (or runs
`hermes kanban decompose <id>`).
Implementation
- plugins/kanban/dashboard/dist/index.js: load /orchestration on mount
(not just on expand) so the collapsed pill reflects real state.
Render mode pill in both collapsed and expanded headers. Reuses the
existing PUT /api/plugins/kanban/orchestration endpoint — no new
backend, no new tests required.
E2E verified
- Pill renders as "⚗ Decompose: AUTO" on page load (default).
- One click flips to "⚗ Decompose: MANUAL" with muted styling.
- config.yaml on disk shows auto_decompose: false after the flip.
- Second click round-trips back to Auto; config.yaml flips to true.
* feat(kanban): rename mode pill to "Orchestration: Auto/Manual"
Per Teknium feedback — "Decompose" was too implementation-specific.
"Orchestration" is the user-facing concept (the whole pitch is the
orchestrator profile routing work), and the pill is the front door to it.
- Pill text: "Orchestration: Auto" / "Orchestration: Manual" (title case,
no ⚗ prefix, no SHOUTY-CAPS for the mode value)
- In-panel checkbox label: "Orchestration mode" (was "Decompose mode")
- Tooltips updated to match
- No behavior change
* docs(kanban): document decompose, profile descriptions, orchestration mode
Brings the docs site up to parity with the PR. English build verified
locally (npx docusaurus build --locale en) — clean, no new broken links
or anchors. Pre-existing broken-link warnings (rl-training, llms.txt,
step-by-step-checklist, fallback-model) untouched.
- website/docs/reference/cli-commands.md
+ `hermes kanban decompose` action row in the action table, with
pointer to the Auto vs Manual orchestration section.
- website/docs/reference/profile-commands.md
+ `--description "<text>"` flag on `hermes profile create`.
+ Full `hermes profile describe` section: read, --text, --auto,
--overwrite, --all flags with examples.
- website/docs/user-guide/features/kanban.md (the big one)
+ Triage column intro rewritten around the Auto-decompose default
behavior, with pointer to the new Auto vs Manual section.
+ Status action row updated to mention both ⚗ Decompose and
✨ Specify on triage cards.
+ New "Auto vs Manual orchestration" section explaining the two
modes, how to flip them (pill, config), how routing-by-description
works, the no-None-assignee guarantee, plus a config knob table
(auto_decompose, auto_decompose_per_tick, orchestrator_profile,
default_assignee) and the two new auxiliary slots
(kanban_decomposer, profile_describer).
+ REST surface table gains 6 new endpoint rows: /tasks/:id/decompose,
/profiles (GET), /profiles/:name (PATCH), /profiles/:name/describe-auto,
/orchestration (GET + PUT).
- website/docs/user-guide/features/kanban-tutorial.md
+ Triage column blurb updated for Auto by default + Manual via the
pill, with cross-link to the Auto vs Manual orchestration section.
- website/docs/user-guide/profiles.md
+ Blank-profile flow now mentions --description and points to the
kanban routing model for context.
- website/docs/user-guide/configuration.md
+ `kanban_decomposer` and `profile_describer` added to the
`hermes model -> Configure auxiliary models` menu listing.
2026-05-17 13:54:12 -07:00
|
|
|
|
|
|
|
|
# Resolve fallbacks the same way the decomposer does.
|
|
|
|
|
resolved_orch = explicit_orch
|
|
|
|
|
resolved_default = explicit_default
|
|
|
|
|
try:
|
|
|
|
|
from hermes_cli import profiles as profiles_mod
|
|
|
|
|
active_default = profiles_mod.get_active_profile_name() or "default"
|
|
|
|
|
if not resolved_orch or not profiles_mod.profile_exists(resolved_orch):
|
|
|
|
|
resolved_orch = active_default
|
|
|
|
|
if not resolved_default or not profiles_mod.profile_exists(resolved_default):
|
|
|
|
|
resolved_default = active_default
|
|
|
|
|
except Exception:
|
|
|
|
|
active_default = "default"
|
|
|
|
|
if not resolved_orch:
|
|
|
|
|
resolved_orch = active_default
|
|
|
|
|
if not resolved_default:
|
|
|
|
|
resolved_default = active_default
|
|
|
|
|
|
|
|
|
|
return {
|
|
|
|
|
"orchestrator_profile": explicit_orch,
|
|
|
|
|
"default_assignee": explicit_default,
|
|
|
|
|
"auto_decompose": auto_decompose,
|
2026-05-18 20:04:26 -07:00
|
|
|
"auto_promote_children": auto_promote_children,
|
feat(kanban): orchestrator-driven auto-decomposition on triage (#27572)
* feat(kanban): orchestrator-driven auto-decomposition on triage
Closes the core gap in the kanban system: dropping a one-liner into Triage
now decomposes it into a graph of child tasks routed to specialist
profiles by description, matching teknium's original vision ("main
orchestrator splits/creates actual tasks, doles them out to each agent").
The build
---------
- hermes_cli/profiles.py: new `description` + `description_auto` fields
on ProfileInfo, persisted in <profile_dir>/profile.yaml. Helpers
read_profile_meta / write_profile_meta. `create_profile` accepts
optional description.
- hermes_cli/profile_describer.py: new module — auto-generate a 1-2
sentence description from a profile's skills + model + name via the
auxiliary LLM (`auxiliary.profile_describer`).
- hermes_cli/main.py: new `hermes profile create --description ...`
flag; new `hermes profile describe [name] [--text ... | --auto |
--all --auto]` subcommand.
- hermes_cli/kanban_db.py: new `decompose_triage_task` atomic helper —
creates N child tasks, links the root as a child of every leaf
(root waits for the whole graph), flips root `triage -> todo` with
orchestrator assignee, records an audit comment + `decomposed` event
in a single write_txn.
- hermes_cli/kanban_decompose.py: new module — calls the auxiliary LLM
(`auxiliary.kanban_decomposer`) with the profile roster + descriptions
to produce a JSON task graph, then invokes the DB helper. Rewrites
unknown assignees to the configured `kanban.default_assignee` (or
the active default profile) so a task NEVER lands with assignee=None.
Falls back to specify-style single-task promotion when the LLM
returns `fanout: false`.
- hermes_cli/kanban.py: new `hermes kanban decompose [task_id | --all]`
CLI verb.
- hermes_cli/config.py: new DEFAULT_CONFIG keys —
kanban.orchestrator_profile, kanban.default_assignee,
kanban.auto_decompose (default True), kanban.auto_decompose_per_tick
(default 3), auxiliary.kanban_decomposer, auxiliary.profile_describer.
- gateway/run.py: kanban dispatcher watcher now runs auto-decompose
before each `_tick_once`, capped by `auto_decompose_per_tick` so a
bulk-load of triage tasks doesn't burst-spend the aux LLM.
- plugins/kanban/dashboard/plugin_api.py: new endpoints —
GET /profiles (list roster + descriptions),
PATCH /profiles/<name> (set description, user-authored),
POST /profiles/<name>/describe-auto (LLM-generate),
POST /tasks/<id>/decompose (run decomposer),
GET/PUT /orchestration (orchestrator/default-assignee/auto-decompose
pickers, with resolved fallbacks echoed back).
- plugins/kanban/dashboard/dist/index.js: new OrchestrationPanel
collapsible — dropdowns for orchestrator profile and default
assignee, auto-decompose toggle, per-profile description editor with
Save and Auto-generate buttons. New ⚗ Decompose button next to
✨ Specify on triage-column task drawers.
Behavior
--------
- A task in Triage gets fanned out into a small DAG of child tasks.
Children with no internal parents flip to `ready` immediately
(parallel dispatch). Children with sibling parents wait. The root
stays alive as a parent of every child — when the whole graph
finishes, it promotes to `ready` and the orchestrator profile wakes
back up to judge completion (the "adds more tasks until done" part
of the original vision).
- `kanban.orchestrator_profile` unset -> falls back to the default
profile (whichever `hermes` launches with no -p flag).
- `kanban.default_assignee` unset -> same fallback. Tasks NEVER end
up unassigned.
- `kanban.auto_decompose=true` (default) runs the decomposer
automatically on dispatcher ticks; manual `hermes kanban decompose`
is always available.
Tests
-----
- tests/hermes_cli/test_kanban_decompose_db.py — 7 tests for the
atomic DB helper (status transitions, dep graph, audit trail,
validation errors).
- tests/hermes_cli/test_kanban_decompose.py — 6 tests for the
decomposer module (fanout, no-fanout fallback, unknown-assignee
rewrite, malformed-JSON resilience, no-aux-client path).
- tests/hermes_cli/test_profile_describer.py — 10 tests for
profile.yaml r/w + the LLM auto-describer (yaml corrupt tolerance,
user-vs-auto description protection, --overwrite, fallback parsing).
E2E
---
- CLI end-to-end: created profiles with descriptions, dropped a triage
task, mocked the aux LLM with a 3-task graph -> verified all three
children were created with the right assignees, the dependency
edges matched the LLM's graph, root flipped to todo gated by every
child, audit comment + `decomposed` event recorded.
- Dashboard end-to-end: started the dashboard against an isolated
HERMES_HOME, verified all four new endpoints via curl (profile
listing, PATCH for description, PUT for orchestration settings,
POST for decompose). Opened the UI in the browser, confirmed the
OrchestrationPanel renders with all three pickers + the per-profile
description editor, typed a description, clicked Save, verified
~/.hermes/profile.yaml was written. Clicked Decompose on the triage
card and confirmed the inline error message surfaced as designed
("no auxiliary client configured").
* feat(kanban): surface decompose mode (Auto/Manual) as a one-click pill
The auto/manual toggle already existed as kanban.auto_decompose (default
true), but it was buried inside the collapsed Orchestration settings
panel — users couldn't tell at a glance which mode they were in. This
hoists it to a pill at the top of the kanban page so the state is always
visible and one click flips it.
UX
- New "⚗ Decompose: AUTO|MANUAL" pill in the kanban header. Emerald
styling when Auto is on (the default), muted/gray when Manual.
- Pill is visible both in the collapsed AND expanded Orchestration
settings views so context is preserved when the user opens the panel.
- Tooltip explains both states + what clicking does.
- Renamed the in-panel "Auto-decompose on triage / Enabled" checkbox
to "Decompose mode / Auto (default) | Manual" for language parity
with the pill.
Behavior preserved
- Default remains Auto (kanban.auto_decompose=true).
- Manual mode restores pre-PR behavior: triage tasks stay in triage
until the user clicks ⚗ Decompose on each card (or runs
`hermes kanban decompose <id>`).
Implementation
- plugins/kanban/dashboard/dist/index.js: load /orchestration on mount
(not just on expand) so the collapsed pill reflects real state.
Render mode pill in both collapsed and expanded headers. Reuses the
existing PUT /api/plugins/kanban/orchestration endpoint — no new
backend, no new tests required.
E2E verified
- Pill renders as "⚗ Decompose: AUTO" on page load (default).
- One click flips to "⚗ Decompose: MANUAL" with muted styling.
- config.yaml on disk shows auto_decompose: false after the flip.
- Second click round-trips back to Auto; config.yaml flips to true.
* feat(kanban): rename mode pill to "Orchestration: Auto/Manual"
Per Teknium feedback — "Decompose" was too implementation-specific.
"Orchestration" is the user-facing concept (the whole pitch is the
orchestrator profile routing work), and the pill is the front door to it.
- Pill text: "Orchestration: Auto" / "Orchestration: Manual" (title case,
no ⚗ prefix, no SHOUTY-CAPS for the mode value)
- In-panel checkbox label: "Orchestration mode" (was "Decompose mode")
- Tooltips updated to match
- No behavior change
* docs(kanban): document decompose, profile descriptions, orchestration mode
Brings the docs site up to parity with the PR. English build verified
locally (npx docusaurus build --locale en) — clean, no new broken links
or anchors. Pre-existing broken-link warnings (rl-training, llms.txt,
step-by-step-checklist, fallback-model) untouched.
- website/docs/reference/cli-commands.md
+ `hermes kanban decompose` action row in the action table, with
pointer to the Auto vs Manual orchestration section.
- website/docs/reference/profile-commands.md
+ `--description "<text>"` flag on `hermes profile create`.
+ Full `hermes profile describe` section: read, --text, --auto,
--overwrite, --all flags with examples.
- website/docs/user-guide/features/kanban.md (the big one)
+ Triage column intro rewritten around the Auto-decompose default
behavior, with pointer to the new Auto vs Manual section.
+ Status action row updated to mention both ⚗ Decompose and
✨ Specify on triage cards.
+ New "Auto vs Manual orchestration" section explaining the two
modes, how to flip them (pill, config), how routing-by-description
works, the no-None-assignee guarantee, plus a config knob table
(auto_decompose, auto_decompose_per_tick, orchestrator_profile,
default_assignee) and the two new auxiliary slots
(kanban_decomposer, profile_describer).
+ REST surface table gains 6 new endpoint rows: /tasks/:id/decompose,
/profiles (GET), /profiles/:name (PATCH), /profiles/:name/describe-auto,
/orchestration (GET + PUT).
- website/docs/user-guide/features/kanban-tutorial.md
+ Triage column blurb updated for Auto by default + Manual via the
pill, with cross-link to the Auto vs Manual orchestration section.
- website/docs/user-guide/profiles.md
+ Blank-profile flow now mentions --description and points to the
kanban routing model for context.
- website/docs/user-guide/configuration.md
+ `kanban_decomposer` and `profile_describer` added to the
`hermes model -> Configure auxiliary models` menu listing.
2026-05-17 13:54:12 -07:00
|
|
|
"resolved_orchestrator_profile": resolved_orch,
|
|
|
|
|
"resolved_default_assignee": resolved_default,
|
|
|
|
|
"active_profile": active_default,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@router.put("/orchestration")
|
|
|
|
|
def set_orchestration_settings(payload: OrchestrationSettingsBody):
|
|
|
|
|
"""Update the kanban orchestration knobs in ~/.hermes/config.yaml.
|
|
|
|
|
|
|
|
|
|
Each field is optional — only fields explicitly passed are
|
|
|
|
|
written. ``orchestrator_profile`` / ``default_assignee`` accept
|
|
|
|
|
empty strings to clear the override and fall back to the default
|
|
|
|
|
profile.
|
|
|
|
|
"""
|
|
|
|
|
try:
|
|
|
|
|
from hermes_cli.config import load_config, save_config
|
|
|
|
|
cfg = load_config() or {}
|
|
|
|
|
except Exception as exc:
|
|
|
|
|
raise HTTPException(status_code=500, detail=f"failed to load config: {exc}")
|
|
|
|
|
|
|
|
|
|
kanban_section = cfg.setdefault("kanban", {})
|
|
|
|
|
if not isinstance(kanban_section, dict):
|
|
|
|
|
kanban_section = {}
|
|
|
|
|
cfg["kanban"] = kanban_section
|
|
|
|
|
|
|
|
|
|
# Validate any non-empty profile names exist before saving.
|
|
|
|
|
try:
|
|
|
|
|
from hermes_cli import profiles as profiles_mod
|
|
|
|
|
except Exception:
|
|
|
|
|
profiles_mod = None # type: ignore
|
|
|
|
|
|
|
|
|
|
if payload.orchestrator_profile is not None:
|
|
|
|
|
name = (payload.orchestrator_profile or "").strip()
|
|
|
|
|
if name and profiles_mod is not None:
|
|
|
|
|
try:
|
|
|
|
|
if not profiles_mod.profile_exists(name):
|
|
|
|
|
raise HTTPException(
|
|
|
|
|
status_code=400,
|
|
|
|
|
detail=f"profile '{name}' does not exist",
|
|
|
|
|
)
|
|
|
|
|
except HTTPException:
|
|
|
|
|
raise
|
|
|
|
|
except Exception:
|
|
|
|
|
pass # fail open if the lookup itself errors
|
|
|
|
|
kanban_section["orchestrator_profile"] = name
|
|
|
|
|
|
|
|
|
|
if payload.default_assignee is not None:
|
|
|
|
|
name = (payload.default_assignee or "").strip()
|
|
|
|
|
if name and profiles_mod is not None:
|
|
|
|
|
try:
|
|
|
|
|
if not profiles_mod.profile_exists(name):
|
|
|
|
|
raise HTTPException(
|
|
|
|
|
status_code=400,
|
|
|
|
|
detail=f"profile '{name}' does not exist",
|
|
|
|
|
)
|
|
|
|
|
except HTTPException:
|
|
|
|
|
raise
|
|
|
|
|
except Exception:
|
|
|
|
|
pass
|
|
|
|
|
kanban_section["default_assignee"] = name
|
|
|
|
|
|
|
|
|
|
if payload.auto_decompose is not None:
|
|
|
|
|
kanban_section["auto_decompose"] = bool(payload.auto_decompose)
|
|
|
|
|
|
2026-05-18 20:04:26 -07:00
|
|
|
if payload.auto_promote_children is not None:
|
|
|
|
|
kanban_section["auto_promote_children"] = bool(payload.auto_promote_children)
|
|
|
|
|
|
feat(kanban): orchestrator-driven auto-decomposition on triage (#27572)
* feat(kanban): orchestrator-driven auto-decomposition on triage
Closes the core gap in the kanban system: dropping a one-liner into Triage
now decomposes it into a graph of child tasks routed to specialist
profiles by description, matching teknium's original vision ("main
orchestrator splits/creates actual tasks, doles them out to each agent").
The build
---------
- hermes_cli/profiles.py: new `description` + `description_auto` fields
on ProfileInfo, persisted in <profile_dir>/profile.yaml. Helpers
read_profile_meta / write_profile_meta. `create_profile` accepts
optional description.
- hermes_cli/profile_describer.py: new module — auto-generate a 1-2
sentence description from a profile's skills + model + name via the
auxiliary LLM (`auxiliary.profile_describer`).
- hermes_cli/main.py: new `hermes profile create --description ...`
flag; new `hermes profile describe [name] [--text ... | --auto |
--all --auto]` subcommand.
- hermes_cli/kanban_db.py: new `decompose_triage_task` atomic helper —
creates N child tasks, links the root as a child of every leaf
(root waits for the whole graph), flips root `triage -> todo` with
orchestrator assignee, records an audit comment + `decomposed` event
in a single write_txn.
- hermes_cli/kanban_decompose.py: new module — calls the auxiliary LLM
(`auxiliary.kanban_decomposer`) with the profile roster + descriptions
to produce a JSON task graph, then invokes the DB helper. Rewrites
unknown assignees to the configured `kanban.default_assignee` (or
the active default profile) so a task NEVER lands with assignee=None.
Falls back to specify-style single-task promotion when the LLM
returns `fanout: false`.
- hermes_cli/kanban.py: new `hermes kanban decompose [task_id | --all]`
CLI verb.
- hermes_cli/config.py: new DEFAULT_CONFIG keys —
kanban.orchestrator_profile, kanban.default_assignee,
kanban.auto_decompose (default True), kanban.auto_decompose_per_tick
(default 3), auxiliary.kanban_decomposer, auxiliary.profile_describer.
- gateway/run.py: kanban dispatcher watcher now runs auto-decompose
before each `_tick_once`, capped by `auto_decompose_per_tick` so a
bulk-load of triage tasks doesn't burst-spend the aux LLM.
- plugins/kanban/dashboard/plugin_api.py: new endpoints —
GET /profiles (list roster + descriptions),
PATCH /profiles/<name> (set description, user-authored),
POST /profiles/<name>/describe-auto (LLM-generate),
POST /tasks/<id>/decompose (run decomposer),
GET/PUT /orchestration (orchestrator/default-assignee/auto-decompose
pickers, with resolved fallbacks echoed back).
- plugins/kanban/dashboard/dist/index.js: new OrchestrationPanel
collapsible — dropdowns for orchestrator profile and default
assignee, auto-decompose toggle, per-profile description editor with
Save and Auto-generate buttons. New ⚗ Decompose button next to
✨ Specify on triage-column task drawers.
Behavior
--------
- A task in Triage gets fanned out into a small DAG of child tasks.
Children with no internal parents flip to `ready` immediately
(parallel dispatch). Children with sibling parents wait. The root
stays alive as a parent of every child — when the whole graph
finishes, it promotes to `ready` and the orchestrator profile wakes
back up to judge completion (the "adds more tasks until done" part
of the original vision).
- `kanban.orchestrator_profile` unset -> falls back to the default
profile (whichever `hermes` launches with no -p flag).
- `kanban.default_assignee` unset -> same fallback. Tasks NEVER end
up unassigned.
- `kanban.auto_decompose=true` (default) runs the decomposer
automatically on dispatcher ticks; manual `hermes kanban decompose`
is always available.
Tests
-----
- tests/hermes_cli/test_kanban_decompose_db.py — 7 tests for the
atomic DB helper (status transitions, dep graph, audit trail,
validation errors).
- tests/hermes_cli/test_kanban_decompose.py — 6 tests for the
decomposer module (fanout, no-fanout fallback, unknown-assignee
rewrite, malformed-JSON resilience, no-aux-client path).
- tests/hermes_cli/test_profile_describer.py — 10 tests for
profile.yaml r/w + the LLM auto-describer (yaml corrupt tolerance,
user-vs-auto description protection, --overwrite, fallback parsing).
E2E
---
- CLI end-to-end: created profiles with descriptions, dropped a triage
task, mocked the aux LLM with a 3-task graph -> verified all three
children were created with the right assignees, the dependency
edges matched the LLM's graph, root flipped to todo gated by every
child, audit comment + `decomposed` event recorded.
- Dashboard end-to-end: started the dashboard against an isolated
HERMES_HOME, verified all four new endpoints via curl (profile
listing, PATCH for description, PUT for orchestration settings,
POST for decompose). Opened the UI in the browser, confirmed the
OrchestrationPanel renders with all three pickers + the per-profile
description editor, typed a description, clicked Save, verified
~/.hermes/profile.yaml was written. Clicked Decompose on the triage
card and confirmed the inline error message surfaced as designed
("no auxiliary client configured").
* feat(kanban): surface decompose mode (Auto/Manual) as a one-click pill
The auto/manual toggle already existed as kanban.auto_decompose (default
true), but it was buried inside the collapsed Orchestration settings
panel — users couldn't tell at a glance which mode they were in. This
hoists it to a pill at the top of the kanban page so the state is always
visible and one click flips it.
UX
- New "⚗ Decompose: AUTO|MANUAL" pill in the kanban header. Emerald
styling when Auto is on (the default), muted/gray when Manual.
- Pill is visible both in the collapsed AND expanded Orchestration
settings views so context is preserved when the user opens the panel.
- Tooltip explains both states + what clicking does.
- Renamed the in-panel "Auto-decompose on triage / Enabled" checkbox
to "Decompose mode / Auto (default) | Manual" for language parity
with the pill.
Behavior preserved
- Default remains Auto (kanban.auto_decompose=true).
- Manual mode restores pre-PR behavior: triage tasks stay in triage
until the user clicks ⚗ Decompose on each card (or runs
`hermes kanban decompose <id>`).
Implementation
- plugins/kanban/dashboard/dist/index.js: load /orchestration on mount
(not just on expand) so the collapsed pill reflects real state.
Render mode pill in both collapsed and expanded headers. Reuses the
existing PUT /api/plugins/kanban/orchestration endpoint — no new
backend, no new tests required.
E2E verified
- Pill renders as "⚗ Decompose: AUTO" on page load (default).
- One click flips to "⚗ Decompose: MANUAL" with muted styling.
- config.yaml on disk shows auto_decompose: false after the flip.
- Second click round-trips back to Auto; config.yaml flips to true.
* feat(kanban): rename mode pill to "Orchestration: Auto/Manual"
Per Teknium feedback — "Decompose" was too implementation-specific.
"Orchestration" is the user-facing concept (the whole pitch is the
orchestrator profile routing work), and the pill is the front door to it.
- Pill text: "Orchestration: Auto" / "Orchestration: Manual" (title case,
no ⚗ prefix, no SHOUTY-CAPS for the mode value)
- In-panel checkbox label: "Orchestration mode" (was "Decompose mode")
- Tooltips updated to match
- No behavior change
* docs(kanban): document decompose, profile descriptions, orchestration mode
Brings the docs site up to parity with the PR. English build verified
locally (npx docusaurus build --locale en) — clean, no new broken links
or anchors. Pre-existing broken-link warnings (rl-training, llms.txt,
step-by-step-checklist, fallback-model) untouched.
- website/docs/reference/cli-commands.md
+ `hermes kanban decompose` action row in the action table, with
pointer to the Auto vs Manual orchestration section.
- website/docs/reference/profile-commands.md
+ `--description "<text>"` flag on `hermes profile create`.
+ Full `hermes profile describe` section: read, --text, --auto,
--overwrite, --all flags with examples.
- website/docs/user-guide/features/kanban.md (the big one)
+ Triage column intro rewritten around the Auto-decompose default
behavior, with pointer to the new Auto vs Manual section.
+ Status action row updated to mention both ⚗ Decompose and
✨ Specify on triage cards.
+ New "Auto vs Manual orchestration" section explaining the two
modes, how to flip them (pill, config), how routing-by-description
works, the no-None-assignee guarantee, plus a config knob table
(auto_decompose, auto_decompose_per_tick, orchestrator_profile,
default_assignee) and the two new auxiliary slots
(kanban_decomposer, profile_describer).
+ REST surface table gains 6 new endpoint rows: /tasks/:id/decompose,
/profiles (GET), /profiles/:name (PATCH), /profiles/:name/describe-auto,
/orchestration (GET + PUT).
- website/docs/user-guide/features/kanban-tutorial.md
+ Triage column blurb updated for Auto by default + Manual via the
pill, with cross-link to the Auto vs Manual orchestration section.
- website/docs/user-guide/profiles.md
+ Blank-profile flow now mentions --description and points to the
kanban routing model for context.
- website/docs/user-guide/configuration.md
+ `kanban_decomposer` and `profile_describer` added to the
`hermes model -> Configure auxiliary models` menu listing.
2026-05-17 13:54:12 -07:00
|
|
|
try:
|
|
|
|
|
save_config(cfg)
|
|
|
|
|
except Exception as exc:
|
|
|
|
|
raise HTTPException(status_code=500, detail=f"failed to save config: {exc}")
|
|
|
|
|
|
|
|
|
|
# Echo back the resolved state (callers usually re-render from it).
|
|
|
|
|
return get_orchestration_settings()
|
|
|
|
|
|
|
|
|
|
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
@router.websocket("/events")
|
|
|
|
|
async def stream_events(ws: WebSocket):
|
fix(dashboard): sanction plugin WS/upload auth via SDK helpers (gated mode)
Dashboard plugins (kanban, hermes-achievements) read
window.__HERMES_SESSION_TOKEN__ directly and hand-assembled WebSocket
URLs with ?token=. That works in loopback/--insecure mode but is
rejected on OAuth-gated deployments, where the session token is absent
and _ws_auth_ok only accepts single-use ?ticket= auth. The result was
401s on plugin REST calls and 1008/403 on the kanban live-events WS
whenever the dashboard ran behind OAuth (e.g. hosted Fly agents).
Make the plugin SDK the single sanctioned auth surface:
- web/src/lib/api.ts: add authedFetch() (raw Response for FormData
uploads / blob downloads, token-or-cookie auth, no throw / no 401
redirect) and buildWsUrl() (assembles a ws(s):// URL with the correct
auth param for the active mode — fresh single-use ticket in gated
mode, token in loopback).
- web/src/plugins/registry.ts: expose authedFetch, buildWsUrl,
buildWsAuthParam, and sdkVersion on window.__HERMES_PLUGIN_SDK__;
add SDK_CONTRACT_VERSION.
- web/src/plugins/sdk.d.ts: hand-authored typed contract for the
plugin SDK + registry globals (single source of truth for the
Window declarations).
- plugins/kanban + hermes-achievements dist bundles: stop reading the
session token directly; route uploads/downloads through
SDK.authedFetch and the live-events WS through SDK.buildWsUrl.
- plugins/kanban plugin_api.py: _ws_upgrade_authorized() delegates the
/events WS upgrade to the canonical web_server._ws_auth_ok gate, so
it transparently accepts loopback token / gated ticket / internal
credential and can never drift from core auth again.
- tests: guard test asserting no plugin dist reads
__HERMES_SESSION_TOKEN__ directly; kanban gated-ticket WS test.
Verified live on a gated staging Fly agent: kanban /events upgrades
101 with a minted ticket (ticket_len=43, ws_auth_ok=True) where the
old code got 403.
2026-06-04 09:17:59 +10:00
|
|
|
# Authorize the upgrade via the dashboard's canonical WS gate so the
|
|
|
|
|
# correct credential is accepted in every mode (loopback token / gated
|
|
|
|
|
# single-use ticket / server-internal credential). Browsers can't set
|
|
|
|
|
# Authorization on a WS upgrade, so the credential rides in the query
|
|
|
|
|
# string — the browser SDK's buildWsUrl() assembles it.
|
|
|
|
|
if not _ws_upgrade_authorized(ws):
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
await ws.close(code=http_status.WS_1008_POLICY_VIOLATION)
|
|
|
|
|
return
|
|
|
|
|
await ws.accept()
|
|
|
|
|
try:
|
|
|
|
|
since_raw = ws.query_params.get("since", "0")
|
|
|
|
|
try:
|
|
|
|
|
cursor = int(since_raw)
|
|
|
|
|
except ValueError:
|
|
|
|
|
cursor = 0
|
|
|
|
|
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
# Board selection — pinned at the WS handshake; re-subscribe to
|
|
|
|
|
# switch boards. Changing boards mid-stream would require
|
|
|
|
|
# reconciling two cursors, so the UI just opens a new WS on
|
|
|
|
|
# board change.
|
|
|
|
|
ws_board_raw = ws.query_params.get("board")
|
|
|
|
|
try:
|
|
|
|
|
ws_board = kanban_db._normalize_board_slug(ws_board_raw) if ws_board_raw else None
|
|
|
|
|
except ValueError:
|
|
|
|
|
ws_board = None
|
|
|
|
|
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
def _fetch_new(cursor_val: int) -> tuple[int, list[dict]]:
|
feat(kanban): multi-project boards — one install, many kanbans (#19653)
Adds first-class board support to kanban so users can separate unrelated
streams of work (projects, repos, domains) into isolated queues. Single-
project users stay on the 'default' board and see no UI change.
Isolation model
---------------
- Each board is a directory at `~/.hermes/kanban/boards/<slug>/` with
its own `kanban.db`, `workspaces/`, and `logs/`. The 'default' board
keeps its legacy path (`~/.hermes/kanban.db`) for back-compat — fresh
installs and pre-boards users get zero migration.
- Workers spawned by the dispatcher have `HERMES_KANBAN_BOARD` pinned in
their env alongside the existing `HERMES_KANBAN_DB` /
`HERMES_KANBAN_WORKSPACES_ROOT` pins, so workers physically cannot see
other boards' tasks.
- The gateway's single dispatcher loop now sweeps every board per tick;
per-tick cost is a few extra filesystem stats.
- CAS concurrency guarantees are preserved per-board (each board is its
own SQLite DB, same WAL+IMMEDIATE machinery as before).
CLI
---
hermes kanban boards list|create|switch|show|rename|rm
hermes kanban --board <slug> <any-subcommand>
Board resolution order: `--board` flag → `HERMES_KANBAN_BOARD` env →
`~/.hermes/kanban/current` file → `default`. Slug validation is strict:
lowercase alphanumerics + hyphens + underscores, 1-64 chars, starts with
alphanumeric. Uppercase is auto-downcased; slashes / dots / `..` /
control chars are rejected so boards can't name their way out of the
boards/ directory.
Passive discoverability: when more than one board exists, `hermes kanban
list` prints a one-line header ("Board: foo (2 other boards …)") so
users who stumble across multi-project never have to hunt for the
feature. Invisible for single-board installs.
Dashboard
---------
- New `BoardSwitcher` component at the top of the Kanban tab: dropdown
with all boards + task counts, `+ New board` button, `Archive`
button (non-default only). Hidden entirely when only `default` exists
and is empty — single-project users never see it.
- New `NewBoardDialog` modal: slug / display name / description / icon
+ "switch to this board after creating" checkbox.
- Selected board persists to `localStorage` so browser users don't
shift the CLI's active board out from under a terminal they left open.
- New `?board=<slug>` query param on every existing endpoint plus a
new `/boards` CRUD surface (`GET /boards`, `POST /boards`,
`PATCH /boards/<slug>`, `DELETE /boards/<slug>`,
`POST /boards/<slug>/switch`).
- Events WebSocket is pinned to a board at connection time; switching
opens a fresh WS against the new board.
Also fixes a pre-existing bug in the plugin's tenant / assignee
filters: the SDK's `Select` uses `onValueChange(value)`, not
native `onChange(event)`, so those filters silently didn't work.
New `selectChangeHandler` helper wires both signatures.
Tests
-----
49 new tests in `tests/hermes_cli/test_kanban_boards.py` covering:
slug validation (valid / invalid / auto-downcase), path resolution
(default = legacy path, named = `boards/<slug>/`, env var override),
current-board resolution chain (env > file > default), board CRUD +
archive / hard-delete, per-board connection isolation (tasks don't
leak), worker spawn env injection (`HERMES_KANBAN_BOARD`,
`HERMES_KANBAN_DB`, `HERMES_KANBAN_WORKSPACES_ROOT` all point at the
right board), and end-to-end CLI surface.
Regression surface: all 264 pre-existing kanban tests continue to pass.
Live-tested via the dashboard: created 3 boards (default,
hermes-agent, atm10-server), created tasks on each via both CLI
(`--board <slug> create`) and dashboard (inline create on the Ready
column), confirmed zero cross-board leakage, confirmed `BoardSwitcher`
+ `NewBoardDialog` work end-to-end in the browser.
2026-05-04 04:42:38 -07:00
|
|
|
conn = kanban_db.connect(board=ws_board)
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
try:
|
|
|
|
|
rows = conn.execute(
|
|
|
|
|
"SELECT id, task_id, run_id, kind, payload, created_at "
|
|
|
|
|
"FROM task_events WHERE id > ? ORDER BY id ASC LIMIT 200",
|
|
|
|
|
(cursor_val,),
|
|
|
|
|
).fetchall()
|
|
|
|
|
out: list[dict] = []
|
|
|
|
|
new_cursor = cursor_val
|
|
|
|
|
for r in rows:
|
|
|
|
|
try:
|
|
|
|
|
payload = json.loads(r["payload"]) if r["payload"] else None
|
|
|
|
|
except Exception:
|
|
|
|
|
payload = None
|
|
|
|
|
out.append({
|
|
|
|
|
"id": r["id"],
|
|
|
|
|
"task_id": r["task_id"],
|
|
|
|
|
"run_id": r["run_id"],
|
|
|
|
|
"kind": r["kind"],
|
|
|
|
|
"payload": payload,
|
|
|
|
|
"created_at": r["created_at"],
|
|
|
|
|
})
|
|
|
|
|
new_cursor = r["id"]
|
|
|
|
|
return new_cursor, out
|
|
|
|
|
finally:
|
|
|
|
|
conn.close()
|
|
|
|
|
|
|
|
|
|
while True:
|
|
|
|
|
cursor, events = await asyncio.to_thread(_fetch_new, cursor)
|
|
|
|
|
if events:
|
|
|
|
|
await ws.send_json({"events": events, "cursor": cursor})
|
|
|
|
|
await asyncio.sleep(_EVENT_POLL_SECONDS)
|
|
|
|
|
except WebSocketDisconnect:
|
|
|
|
|
return
|
2026-05-07 01:11:28 +02:00
|
|
|
except asyncio.CancelledError:
|
|
|
|
|
# Normal shutdown path: dashboard process exit (Ctrl-C) cancels the
|
|
|
|
|
# websocket task while it is sleeping in the poll loop.
|
|
|
|
|
# CancelledError is a BaseException in 3.8+ so the bare Exception
|
|
|
|
|
# handler below would not catch it; without this clause Uvicorn
|
|
|
|
|
# surfaces the cancellation as an application traceback. Quiet it.
|
|
|
|
|
return
|
feat(kanban): durable multi-profile collaboration board (#17805)
Salvage of PR #16100 onto current main (after emozilla's #17514 fix
that unblocks plugin Pydantic body validation). History preserved on
the standing `feat/kanban-standing` branch; this squashes the 22
iterative commits into one clean landing.
What this lands:
- SQLite kernel (hermes_cli/kanban_db.py) — durable task board with
tasks, task_links, task_runs, task_comments, task_events,
kanban_notify_subs tables. WAL mode, atomic claim via CAS,
tenant-namespaced, skills JSON array per task, max-runtime timeouts,
worker heartbeats, idempotency keys, circuit breaker on repeated
spawn failures, crash detection via /proc/<pid>/status, run history
preserved across attempts.
- Dispatcher — runs inside the gateway by default
(`kanban.dispatch_in_gateway: true`). Ticks every 60s, reclaims
stale claims, promotes ready tasks, spawns `hermes -p <assignee>
chat -q "work kanban task <id>"` with HERMES_KANBAN_TASK +
HERMES_KANBAN_WORKSPACE env. Auto-loads `--skills kanban-worker`
plus any per-task skills. Health telemetry warns on stuck ready
queue.
- Structured tool surface (tools/kanban_tools.py) — 7 tools
(kanban_show, kanban_complete, kanban_block, kanban_heartbeat,
kanban_comment, kanban_create, kanban_link). Gated on
HERMES_KANBAN_TASK via check_fn so zero schema footprint in normal
sessions.
- System-prompt guidance (agent/prompt_builder.py KANBAN_GUIDANCE)
injected only when kanban tools are active.
- Dashboard plugin (plugins/kanban/dashboard/) — Linear-style board
UI: triage/todo/ready/running/blocked/done columns, drag-drop,
inline create, task drawer with markdown, comments, run history,
dependency editor, bulk ops, lanes-by-profile grouping, WS-driven
live refresh. Matches active dashboard theme via CSS variables.
- CLI — `hermes kanban init|create|list|show|assign|link|unlink|
claim|comment|complete|block|unblock|archive|tail|dispatch|context|
init|gc|watch|stats|notify|log|heartbeat|runs|assignees` +
`/kanban` slash in-session.
- Worker + orchestrator skills (skills/devops/kanban-worker +
kanban-orchestrator) — pattern library for good summary/metadata
shapes, retry diagnostics, block-reason examples, fan-out patterns.
- Per-task force-loaded skills — `--skill <name>` (repeatable),
stored as JSON, threaded through to dispatcher argv as one
`--skills X` pair per skill alongside the built-in kanban-worker.
Dashboard + CLI + tool parity.
- Deprecation of standalone `hermes kanban daemon` — stub exits 2
with migration guidance; `--force` escape hatch for headless hosts.
- Docs (website/docs/user-guide/features/kanban.md + kanban-tutorial.md)
with 11 dashboard screenshots walking through four user stories
(Solo Dev, Fleet Farming, Role Pipeline, Circuit Breaker).
- Tests (251 passing): kernel schema + migration + CAS atomicity,
dispatcher logic, circuit breaker, crash detection, max-runtime
timeouts, claim lifecycle, tenant isolation, idempotency keys, per-
task skills round-trip + validation + dispatcher argv, tool surface
(7 tools × round-trip + error paths), dashboard REST (CRUD + bulk
+ links + warnings), gateway-embedded dispatcher (config gate, env
override, graceful shutdown), CLI deprecation stub, migration from
legacy schemas.
Gateway integration:
- GatewayRunner._kanban_dispatcher_watcher — new asyncio background
task, symmetric with _kanban_notifier_watcher. Runs dispatch_once
via asyncio.to_thread so SQLite WAL never blocks the loop. Sleeps
in 1s slices for snappy shutdown. Respects HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
env override for debugging.
- Config: new `kanban` section in DEFAULT_CONFIG with
`dispatch_in_gateway: true` (default) + `dispatch_interval_seconds: 60`.
Additive — no \_config_version bump needed.
Forward-compat:
- workflow_template_id / current_step_key columns on tasks (v1 writes
NULL; v2 will use them for routing).
- task_runs holds claim machinery (claim_lock, claim_expires,
worker_pid, last_heartbeat_at) so multi-attempt history is first-
class from day one.
Closes #16102.
Co-authored-by: emozilla <emozilla@nousresearch.com>
2026-04-30 13:36:47 -07:00
|
|
|
except Exception as exc: # defensive: never crash the dashboard worker
|
|
|
|
|
log.warning("Kanban event stream error: %s", exc)
|
|
|
|
|
try:
|
|
|
|
|
await ws.close()
|
|
|
|
|
except Exception:
|
|
|
|
|
pass
|