5 Commits

Author	SHA1	Message	Date
Teknium	5ec6baa400	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
Teknium	986ec04048	docs: document /kanban slash command (#19584) ... * docs: document /kanban slash command The kanban user guide and slash-commands reference only mentioned the /kanban slash command in passing. Add a proper section covering: - CLI and gateway both expose the full hermes kanban surface via hermes_cli.kanban.run_slash (identical argument surface) - Mid-run usage: /kanban bypasses the running-agent guard, so reads and writes land immediately while an agent is still in a turn - Auto-subscribe on /kanban create from the gateway — originating chat is subscribed to terminal events, with a worked example - Output truncation (~3800 chars) in messaging - Autocomplete hint list vs full subcommand surface Also adds /kanban rows to both slash-command tables (CLI + messaging) in reference/slash-commands.md and moves it into the 'works in both' notes bucket. * docs(kanban): frame the model's tool surface as primary, CLI as the human surface The kanban user guide and CLI reference read as if you drive the board by running `hermes kanban` commands everywhere. In practice: - **You** (human, scripts, cron, dashboard) use the `hermes kanban …` CLI, the `/kanban …` slash command, or the REST/dashboard. - **Workers** spawned by the dispatcher use a dedicated `kanban_*` toolset (`kanban_show`, `kanban_complete`, `kanban_block`, `kanban_heartbeat`, `kanban_comment`, `kanban_create`, `kanban_link`) and never shell out to the CLI. Changes to `user-guide/features/kanban.md`: - New 'Two surfaces' intro distinguishes the two front doors up front. - Quick-start section re-labelled so each step says who is running it (you vs. orchestrator vs. worker). - 'How workers interact with the board' rewritten: - Lead with "Workers do not shell out to `hermes kanban`." - Tool table extended with required params. - Concrete worker-turn example (`kanban_show` → `kanban_heartbeat` → `kanban_complete`) and an orchestrator fan-out example (`kanban_create` x N with `parents=[...]`). - Moved 'Why tools not CLI' from a defensive aside to a clean follow-up section. - 'Worker skill' section explicitly says the lifecycle is taught in tool calls, not CLI commands. - 'Pinning extra skills' reordered — orchestrator tool form first (the usual case), human/CLI second, dashboard third. - 'Orchestrator skill' now shows a canonical `kanban_create` / `kanban_link` / `kanban_complete` tool-call sequence instead of only describing what the skill teaches. - CLI-command-reference heading now clarifies this is the human surface, with a cross-link to the tool-surface section. - 'Runs — one row per attempt' structured-handoff example replaced: the primary example is now `kanban_complete(summary=..., metadata=...)` (what a worker actually does), with the CLI form retained as "when you, the human, need to close a task a worker can't." Changes to `reference/cli-commands.md`: - `hermes kanban` intro marks itself as the human / scripting surface and links out to the worker tool surface. - Corrected `comment <id>` description — the next worker reads it via `kanban_show()`, not by running `hermes kanban show`. * docs(kanban-tutorial): reframe worker actions as tool calls Honest answer to Teknium's follow-up: no, the first pass missed the tutorial. The four stories all showed `hermes kanban claim / complete / block / unblock` as if the backend-dev, pm, and reviewer personas were humans running CLI commands. In a real hermes kanban run those agents are dispatcher-spawned workers driving the board through the `kanban_*` tool surface. Changes: - Setup intro now distinguishes the three surfaces up front (dashboard / CLI for you, `kanban_*` tools for workers) and establishes the convention: `bash` blocks are commands *you* run, `# worker tool calls` blocks are what the agent emits. - Story 1 (solo dev schema): 'Claim the schema task, do the work, hand off' block replaced with the dispatcher spawning the backend-dev worker and a `kanban_show → kanban_heartbeat → kanban_complete` tool-call sequence. The 'On the CLI' `hermes kanban show / runs` block re-labelled as 'you peeking at the board' to keep it correct as a human inspection step. - Story 2 (fleet farming): note about structured handoff updated from `--summary` / `--metadata` CLI flags to `kanban_complete(summary=..., metadata=...)` tool form. - Story 3 (role pipeline): the big PM/engineer/reviewer block fully rewritten as three worker tool-call sequences — PM worker completes spec, engineer worker blocks, human/reviewer `hermes kanban unblock` (or `/kanban unblock`), engineer worker respawns and completes. The respawn-as-new-run mechanic is now explicit. - Reviewer paragraph: `build_worker_context` replaced with `kanban_show()` — that's the tool that delivers the parent handoff to the model. - Structured handoff section heading and body updated: `--summary`/`--metadata` → `summary`/`metadata` (tool params), with a note that the tool surface doesn't expose a bulk variant for the same reason the CLI refuses multi-task `complete`. Story 4 (circuit breaker) unchanged — its workers fail to spawn, so there are no tool calls to show; the `hermes kanban create` and `hermes kanban runs` commands in it are correctly human-driven.	2026-05-04 03:05:34 -07:00
Teknium	c868425467	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
Teknium	06f81752ed	Revert "feat(kanban): durable multi-profile collaboration board (#16081)" (#16098) ... This reverts commit 15937a6b46.	2026-04-26 08:29:37 -07:00
Teknium	15937a6b46	feat(kanban): durable multi-profile collaboration board (#16081) ... New `hermes kanban` CLI subcommand + `/kanban` slash command + skills for worker and orchestrator profiles. SQLite-backed task board (~/.hermes/kanban.db) shared across all profiles on the host. Zero changes to run_agent.py, no new core tools, no tool-schema bloat. Motivation: delegate_task is a function call — sync fork/join, anonymous subagent, no resumability, no human-in-the-loop. Kanban is the durable shape needed for research triage, scheduled ops, digital twins, engineering pipelines, and fleet work. They coexist (workers may call delegate_task internally). What this adds - hermes_cli/kanban_db.py — schema, CAS claim, dependency resolution, dispatcher, workspace resolution, worker-context builder. - hermes_cli/kanban.py — 15-verb CLI surface and shared run_slash() entry point used by both CLI and gateway. - skills/devops/kanban-worker — how a profile should work a claimed task. - skills/devops/kanban-orchestrator — "you are a dispatcher, not a worker" template with anti-temptation rules. - /kanban slash command wired into cli.py and gateway/run.py. Bypasses the running-agent guard (board writes don't touch agent state), so /kanban unblock can free a stuck worker mid-conversation. - Design spec at docs/hermes-kanban-v1-spec.pdf — comparative analysis vs Cline Kanban, Paperclip, NanoClaw, Gemini Enterprise; 8 patterns; 4 user stories; implementation plan; concurrency correctness. - Docs: website/docs/user-guide/features/kanban.md, CLI reference updated, sidebar entry added. Architecture highlights - Three planes: control (user + gateway), state (board + dispatcher), execution (pool of profile processes). - Every worker is a full OS process, spawned as `hermes -p <profile>`. No in-process subagent swarms — solves NanoClaw's SDK-lifecycle failure class. - Atomic claim via SQLite CAS in a BEGIN IMMEDIATE transaction; stale claims reclaimed 15 min after their TTL expires. - Tenant namespacing via one nullable column — one specialist fleet can serve many businesses with data isolation by workspace path. Tests: 60 targeted tests (schema, CAS atomicity, dependency resolution, dispatcher, workspace kinds, tenancy, CLI + slash surface). All pass hermetic via scripts/run_tests.sh.	2026-04-26 08:24:26 -07:00