Support for the new Hermes Kanban

[fecolinhares]

Hermes Agent just release a new feature called Hermes Kanban, that would be a great feature to support it on the Hermes WebUI https://hermes-agent.nousresearch.com/docs/user-guide/features/kanban

[nesquena]

Agreed, thanks! Another possibility is we can simply add an easy way to get dashboard booted up and running since it's built into Hermes agent, perhaps it's best to just make it really easy to switch to access Kanban from our webUI rather than try to reinvent the wheel. But open to opinions

[nesquena-hermes]

Filed for tracking — agreed this fits the Hermes-agent feature-mirror pattern (we already track Plugins, Skills, MCP servers, Tasks via similar surfaces). Labeling as enhancement + gateway + cli-parity and parking in Backlog (Icebox) for now alongside the other Hermes-agent-feature-mirror requests (#733 MCP server, #1257 LLM Wiki, #1459 Dashboard link).

Two scope notes for whoever picks this up:

1. Read-only first. The Hermes Kanban surface has read/write/move semantics. The first WebUI integration should be read-only (board view + cards as drilldown links into the relevant Hermes session) — that delivers most of the value at ~10% of the implementation surface. Editing semantics are easier to add later than to undo.

2. Profile-aware. Like every Hermes-agent feature mirror (Plugins, Skills, MCP), the kanban data lives under get_hermes_home() (profile-scoped). The WebUI integration must use the same profile-resolution path the rest of the UI uses, not the process-global one — otherwise switching profiles would silently break the board.

When this picks up steam (or someone wants to land it), the right shape is probably a new Kanban left-rail tab that proxies GET /api/kanban/* to the upstream agent's existing endpoints with profile + auth gating, plus a 30s poll for updates (matches our existing pattern in Insights / Sessions). No new endpoint family, no new background process. Estimated ~250-400 LOC + tests.

Not on a milestone deadline — Icebox until there's clear demand for it from multiple reporters or a contributor wants to take it on.

[ai-ag2026]

I have a local prototype of a native WebUI Kanban integration and can split it into small PRs if that direction sounds useful.

Based on the scope notes above, I would start conservatively:

1. Read-only backend bridge under /api/kanban/*, backed by Hermes Agent's hermes_cli.kanban_db so ~/.hermes/kanban.db remains the only source of truth.
2. Native WebUI left-rail panel using the existing vanilla JS/CSS style, not an iframe and not the Agent Dashboard React bundle.
3. Read-only task drilldown for comments/events/links/runs/logs.
4. Defer write semantics (create/edit/move/bulk actions) to later PRs after the read-only shape is reviewed.

This keeps the first PR small and aligned with the profile-aware feature-mirror pattern already used elsewhere in WebUI.

Proposed first PR test coverage:

python -m pytest tests/test_kanban_bridge.py -q -o 'addopts='
python -m py_compile api/kanban_bridge.py api/routes.py

[nesquena-hermes]

@ai-ag2026 — that decomposition aligns well with the scope notes above. Read-only-first + native left-rail panel + deferred writes is exactly the right shape for the first PR, and using hermes_cli.kanban_db as the data source (rather than reimplementing storage) keeps ~/.hermes/kanban.db as the single source of truth, which is the profile-isolation behavior the rest of the WebUI feature-mirrors (Plugins, Skills, MCP) already follow.

A few things worth pinning down before the first PR lands so the review is mechanical rather than directional:

1. Profile resolution path. The bridge must use whatever profile-aware path resolution the existing WebUI uses (e.g. get_hermes_home() from the active profile context), not a process-global resolution. The kanban.db location follows from that. If you're tempted to import directly from hermes_cli.kanban_db, double-check it doesn't cache a path at module import time — that would break profile switching silently.

2. Concurrency with the agent. If the agent is also writing to kanban.db (it almost certainly is — that's the whole point), the WebUI bridge must open SQLite in read-only mode (mode=ro or ?immutable=0&mode=ro URI) and use WAL-aware connection settings so it doesn't block agent writes or see torn reads. Worth a regression test that opens a concurrent writer and verifies the bridge sees consistent rows.

3. Polling cadence. 30s matches Insights/Sessions — good. Make it configurable via the same mechanism (whatever poll-interval setting Insights uses) so users with huge boards aren't hammered.

4. Drilldown link target. "Cards as drilldown links into the relevant Hermes session" needs a concrete contract: does the kanban schema have a session_id column, or do we resolve via task→run→session? If the latter, the bridge endpoint should return the resolved session ID (not force the client to do a second hop) so the cardlink stays a single-click action.

5. Test coverage. The two commands you listed cover the bridge itself; please also add a JS-level test that the new left-rail tab renders the board structure correctly when /api/kanban/* returns the canonical shape. The WebUI front-end has existing test patterns for that — tests/test_static_* style.

Splitting into small PRs is the right call. Suggested order:

• PR 1 — api/kanban_bridge.py + tests/test_kanban_bridge.py (read-only, board list + card list, profile-aware, no UI yet).
• PR 2 — Left-rail panel UI in vanilla JS/CSS, consuming PR 1's endpoints. No drilldown.
• PR 3 — Card drilldown (comments/events/links/runs/logs read-only views).
• PR 4+ — Write semantics (create/edit/move) only after the read-only shape is settled and reviewed.

If PR 1 stays under ~250 LOC + tests it'll be easy to review. Looking forward to seeing it.

[nesquena-hermes]

Closing as fully shipped — Kanban v1 launched in v0.51.0

The native Hermes Kanban integration shipped in v0.51.0 (2026-05-05). Going beyond the read-only-first scope discussed in the thread:

What's in v0.51.0

Surface	Status
Kanban left-rail tab	✅ live (visible alongside Chat / Tasks / Skills / Memory / Spaces / Agent Profiles / Todos / Insights / Settings)
/api/kanban/* server bridge	✅ shipped (api/kanban_bridge.py, ~49KB)
Read-only board view	✅
Read-only task drilldown (comments / events / links / runs / logs)	✅
Write semantics MVP (create / edit / move)	✅ shipped beyond the original "read-only first" scope
Multi-board management	✅ shipped in PR #1675
SSE live event stream	✅ shipped in PR #1675
Profile-aware (get_hermes_home_for_profile())	✅
~/.hermes/kanban.db as single source of truth	✅ (uses hermes_cli.kanban_db)
Concurrency-safe (read-only SQLite mode + WAL)	✅

Constituent PRs

• PR feat(kanban): multi-board management + SSE live event stream #1675 — multi-board management + SSE live event stream (the v0.51.0 capstone)
• PR feat: harden Kanban review feedback #1660 — review-feedback hardening pass by @ai-ag2026
• Plus the original implementation series: read-only API bridge → native panel → task detail → write MVP → dashboard parity → polish

Tests

tests/test_kanban_bridge.py (~46KB) and tests/test_kanban_ui_static.py (~21KB) pin the API contract and UI shapes.

Thanks to @ai-ag2026 for the original 4-step decomposition that scoped the work cleanly, @nesquena for the upstream Kanban architecture this builds on, and everyone who reviewed the constituent PRs.

Closing as fully resolved. Bug reports against the live Kanban panel should land as new issues.