feat(kanban): durable multi-profile collaboration board by teknium1 · Pull Request #16081 · NousResearch/hermes-agent

teknium1 · 2026-04-26T14:30:17Z

Hermes Kanban — durable multi-profile collaboration board

Summary

Adds a first-class multi-agent collaboration surface to Hermes: a durable SQLite-backed task board (~/.hermes/kanban.db) shared across all profiles on the host, a cron-driven dispatcher that atomically claims ready tasks and spawns the assigned profile in an isolated workspace, and a /kanban slash command wired into both the interactive CLI and the gateway.

Zero changes to run_agent.py. No new core tools. No tool-schema bloat on any API call. Every worker is a full OS process — no in-process subagent swarms, no SDK-lifecycle fragility.

Motivation

delegate_task is a synchronous function call: fork → join, anonymous subagent, no resumability, no human-in-the-loop. It's correct for short reasoning subtasks; it is the wrong shape for the workloads users actually asked for in the Nous Discord design thread:

Research triage — N parallel researchers + analyst + writer, human-in-the-loop for ambiguity.
Scheduled recurring workflows — daily AI-funding briefs that accumulate into an Obsidian vault.
Digital twins — named inbox-triage / ops-review profiles with persistent memory over weeks.
Engineering pipelines — decompose → parallel worktrees → review → iterate → PR.
Fleet work — one specialist profile managing 50 Instagram accounts, each with its own workspace.

Kanban is the shape that covers all four user-story types. They coexist with delegate_task: a kanban worker may call delegate_task internally for reasoning within its own run. The single test: does this handoff need to outlive a single API loop and be visible to others?

Design rationale, full comparison with Cline Kanban / Paperclip / NanoClaw / Google Gemini Enterprise, concurrency correctness argument, and implementation plan live in docs/hermes-kanban-v1-spec.pdf (committed with the PR).

What landed

Core (new files)

hermes_cli/kanban_db.py (1067 lines) — WAL-mode SQLite schema (tasks, task_links, task_comments, task_events), atomic claim via CAS inside BEGIN IMMEDIATE, stale-claim recovery, dependency resolution (todo → ready on parent done), workspace resolution (scratch / dir:<path> / worktree), worker-context builder, dispatcher.
hermes_cli/kanban.py (662 lines) — 15-verb argparse CLI surface plus run_slash() entry point shared by both CLI and gateway handlers.
skills/devops/kanban-worker/SKILL.md — how a profile claims context, does work in its workspace, blocks on ambiguity, completes with a result, and delegates follow-ups.
skills/devops/kanban-orchestrator/SKILL.md — "you are a dispatcher, not a worker" template with explicit anti-temptation rules and a decomposition playbook, addressing the sudo_relax Discord feedback ("my orchestrator does the work itself").

Wiring (touched files)

hermes_cli/commands.py — one CommandDef("kanban", …) entry. Propagates automatically to Telegram menu, Slack subcommand routing, CLI autocomplete, /help.
hermes_cli/main.py — cmd_kanban handler + build_parser hookup, following the cmd_webhook pattern.
cli.py — _handle_kanban_command delegates to run_slash.
gateway/run.py — async _handle_kanban_command runs the same run_slash on a thread and returns the formatted output, with the running-agent guard bypassed (board writes don't touch agent state, and /kanban unblock is often the only way to free a stuck worker mid-chat).

Docs

docs/hermes-kanban-v1-spec.pdf — full design spec (14 sections, TikZ diagrams, tables, bibliography).
website/docs/user-guide/features/kanban.md — user-facing guide.
website/docs/reference/cli-commands.md — full CLI reference table.
website/sidebars.ts — sidebar entry in the Automation category.

Architecture in one picture

                   ┌───────────────────────────┐
                   │   USER / GATEWAY          │   control plane
                   │   /kanban create | list…  │
                   └────────────┬──────────────┘
                                │
                   ┌────────────▼──────────────┐
                   │  ~/.hermes/kanban.db      │   state plane
                   │  tasks, links, comments,  │
                   │  events  (WAL)            │
                   └────────────┬──────────────┘
                                │  cron every 60s
                   ┌────────────▼──────────────┐
                   │  DISPATCHER               │
                   │  1. reclaim stale claims  │
                   │  2. todo → ready          │
                   │  3. atomic CAS claim      │
                   │  4. spawn worker proc     │
                   └────────────┬──────────────┘
                                │
      ┌─────────────────┬───────┴────────┬─────────────────┐
      ▼                 ▼                ▼                 ▼
  profile:planner  profile:researcher  profile:reviewer  profile:ops   execution
  (own HERMES_HOME, memory, skills; own workspace per task)            plane

Collaboration patterns covered

Eight, all expressible with the base primitives (tasks + links + comments + assignee + workspace):

Fan-out — N siblings, same role.
Pipeline — role-specialized chain.
Voting / quorum — N siblings + one aggregator linked from all N.
Long-running journal — same profile + shared dir workspace + cron.
Human-in-the-loop triage — block → comment → unblock → re-spawn.
@mention — inline routing from prose (parser hook; UX addition).
Thread-scoped workspace — /kanban here pins dir to current gateway thread.
Fleet farming — one profile, N tasks, one workspace per subject (50-account RPA without RPA tooling).

Tests

tests/hermes_cli/test_kanban_db.py   — 42 tests (schema, CAS atomicity including
                                        a multi-thread race, cycle detection,
                                        dependency cascade, fan-in, stale reclaim,
                                        workspace resolution, tenancy)
tests/hermes_cli/test_kanban_cli.py  — 18 tests (run_slash end-to-end, JSON
                                        output, tenant filter, assign reassign,
                                        link/unlink cycle, registry integration)

All 60 tests pass under scripts/run_tests.sh (hermetic, 4 xdist workers, TZ=UTC, LANG=C.UTF-8).

scripts/run_tests.sh tests/hermes_cli/test_kanban_db.py \
                     tests/hermes_cli/test_kanban_cli.py \
                     tests/hermes_cli/test_commands.py
============================= 176 passed in 2.06s ==============================

test_commands.py runs clean too — no regressions in the central registry wiring.

Pre-existing test_discord_slash_commands.py::test_auto_thread_* failures on origin/main are unrelated (verified by stashing all Kanban changes and running them on a clean checkout — they fail identically).

Out-of-scope (deliberately)

Kernel stays small. All of the following are user-space — expressible as profiles, skills, or plugins on top of the primitives this PR lands:

"Smart routing" / auto-assignment → a router profile, not a dispatcher feature.
Per-agent budgets → a plugin that wraps spawn.
Governance / approval gates → reuse existing tools/approval.py.
Fleet dashboards → a dashboard plugin that reads the board.
Org-chart / reporting lines → profile naming convention.

This is the NanoClaw lesson in reverse: keep the kernel small, push ornaments to user-space, never depend on upstream SDK lifecycle primitives we don't own.

Credits

User stories and design input from the Nous Discord design thread: Teknium, waxhy, A Real Icehole, Keimpe, LLM.STORE, caco, hunter_cat, djm, ionmanden, psbd, Aiz, Rikllo, sudo_relax, neo2k8. P6 borrowed from Google's Gemini CLI subagent @name syntax; P7 from psbd; P8 from neo2k8.

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.

# Conflicts: # gateway/run.py

…)" (#16098) This reverts commit 15937a6.

…#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.

…Research#16081)" (NousResearch#16098) This reverts commit 3857c68.

…#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.

…Research#16081)" (NousResearch#16098) This reverts commit 15937a6.

…#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.

…Research#16081)" (NousResearch#16098) This reverts commit 39c1e9d.

Extends the previous commit to cover the remaining additive-column index that sits on the same migration trap: - ``task_events.run_id`` -> ``idx_events_run`` was still in SCHEMA_SQL. A legacy ``task_events`` table predating NousResearch#17805 (no ``run_id``) would still abort ``executescript`` before ``_migrate_add_optional_columns`` could add the column. Hoisted out of SCHEMA_SQL and made unconditional in the migration alongside the other three indexes. - Removed the now-redundant ``CREATE INDEX idx_tasks_idempotency`` that was nested inside the ``if "idempotency_key" not in cols`` branch. The unconditional create lower in the function makes it idempotent on both fresh and legacy DBs. - Strengthened the regression test to cover all four indexes (``idx_tasks_session_id``, ``idx_tasks_tenant``, ``idx_tasks_idempotency``, ``idx_events_run``) and to seed a pre-NousResearch#17805 ``task_events`` shape that exercises the ``run_id`` migration path. The result: every ``CREATE INDEX`` that depends on an additive column now runs after the migration ensures the column exists. Verified against a realistic pre-NousResearch#16081 board fixture (tasks + task_events both legacy shape) — origin/main reproduces ``no such column: session_id``; this branch migrates cleanly and creates all four indexes.

Extends the previous commit to cover the remaining additive-column index that sits on the same migration trap: - ``task_events.run_id`` -> ``idx_events_run`` was still in SCHEMA_SQL. A legacy ``task_events`` table predating #17805 (no ``run_id``) would still abort ``executescript`` before ``_migrate_add_optional_columns`` could add the column. Hoisted out of SCHEMA_SQL and made unconditional in the migration alongside the other three indexes. - Removed the now-redundant ``CREATE INDEX idx_tasks_idempotency`` that was nested inside the ``if "idempotency_key" not in cols`` branch. The unconditional create lower in the function makes it idempotent on both fresh and legacy DBs. - Strengthened the regression test to cover all four indexes (``idx_tasks_session_id``, ``idx_tasks_tenant``, ``idx_tasks_idempotency``, ``idx_events_run``) and to seed a pre-#17805 ``task_events`` shape that exercises the ``run_id`` migration path. The result: every ``CREATE INDEX`` that depends on an additive column now runs after the migration ensures the column exists. Verified against a realistic pre-#16081 board fixture (tasks + task_events both legacy shape) — origin/main reproduces ``no such column: session_id``; this branch migrates cleanly and creates all four indexes.

Extends the previous commit to cover the remaining additive-column index that sits on the same migration trap: - ``task_events.run_id`` -> ``idx_events_run`` was still in SCHEMA_SQL. A legacy ``task_events`` table predating NousResearch#17805 (no ``run_id``) would still abort ``executescript`` before ``_migrate_add_optional_columns`` could add the column. Hoisted out of SCHEMA_SQL and made unconditional in the migration alongside the other three indexes. - Removed the now-redundant ``CREATE INDEX idx_tasks_idempotency`` that was nested inside the ``if "idempotency_key" not in cols`` branch. The unconditional create lower in the function makes it idempotent on both fresh and legacy DBs. - Strengthened the regression test to cover all four indexes (``idx_tasks_session_id``, ``idx_tasks_tenant``, ``idx_tasks_idempotency``, ``idx_events_run``) and to seed a pre-NousResearch#17805 ``task_events`` shape that exercises the ``run_id`` migration path. The result: every ``CREATE INDEX`` that depends on an additive column now runs after the migration ensures the column exists. Verified against a realistic pre-NousResearch#16081 board fixture (tasks + task_events both legacy shape) — origin/main reproduces ``no such column: session_id``; this branch migrates cleanly and creates all four indexes. #AI commit#

Extends the previous commit to cover the remaining additive-column index that sits on the same migration trap: - ``task_events.run_id`` -> ``idx_events_run`` was still in SCHEMA_SQL. A legacy ``task_events`` table predating NousResearch#17805 (no ``run_id``) would still abort ``executescript`` before ``_migrate_add_optional_columns`` could add the column. Hoisted out of SCHEMA_SQL and made unconditional in the migration alongside the other three indexes. - Removed the now-redundant ``CREATE INDEX idx_tasks_idempotency`` that was nested inside the ``if "idempotency_key" not in cols`` branch. The unconditional create lower in the function makes it idempotent on both fresh and legacy DBs. - Strengthened the regression test to cover all four indexes (``idx_tasks_session_id``, ``idx_tasks_tenant``, ``idx_tasks_idempotency``, ``idx_events_run``) and to seed a pre-NousResearch#17805 ``task_events`` shape that exercises the ``run_id`` migration path. The result: every ``CREATE INDEX`` that depends on an additive column now runs after the migration ensures the column exists. Verified against a realistic pre-NousResearch#16081 board fixture (tasks + task_events both legacy shape) — origin/main reproduces ``no such column: session_id``; this branch migrates cleanly and creates all four indexes.

…#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.

…Research#16081)" (NousResearch#16098) This reverts commit 15937a6.

Extends the previous commit to cover the remaining additive-column index that sits on the same migration trap: - ``task_events.run_id`` -> ``idx_events_run`` was still in SCHEMA_SQL. A legacy ``task_events`` table predating NousResearch#17805 (no ``run_id``) would still abort ``executescript`` before ``_migrate_add_optional_columns`` could add the column. Hoisted out of SCHEMA_SQL and made unconditional in the migration alongside the other three indexes. - Removed the now-redundant ``CREATE INDEX idx_tasks_idempotency`` that was nested inside the ``if "idempotency_key" not in cols`` branch. The unconditional create lower in the function makes it idempotent on both fresh and legacy DBs. - Strengthened the regression test to cover all four indexes (``idx_tasks_session_id``, ``idx_tasks_tenant``, ``idx_tasks_idempotency``, ``idx_events_run``) and to seed a pre-NousResearch#17805 ``task_events`` shape that exercises the ``run_id`` migration path. The result: every ``CREATE INDEX`` that depends on an additive column now runs after the migration ensures the column exists. Verified against a realistic pre-NousResearch#16081 board fixture (tasks + task_events both legacy shape) — origin/main reproduces ``no such column: session_id``; this branch migrates cleanly and creates all four indexes.

alt-glitch added type/feature New feature or request P3 Low — cosmetic, nice to have comp/cli CLI entry point, hermes_cli/, setup wizard comp/gateway Gateway runner, session dispatch, delivery comp/cron Cron scheduler and job management labels Apr 26, 2026

Merge remote-tracking branch 'origin/main' into hermes/hermes-4dde9557

5a2038e

# Conflicts: # gateway/run.py

teknium1 merged commit 15937a6 into main Apr 26, 2026
4 checks passed

teknium1 deleted the hermes/hermes-4dde9557 branch April 26, 2026 15:24

teknium1 mentioned this pull request Apr 26, 2026

Revert "feat(kanban): durable multi-profile collaboration board (#16081)" #16098

Merged

teknium1 added a commit that referenced this pull request Apr 26, 2026

Revert "feat(kanban): durable multi-profile collaboration board (#16081…

06f8175

…)" (#16098) This reverts commit 15937a6.

ulasbilgen pushed a commit to ulasbilgen/hermes-adhd-agent that referenced this pull request May 1, 2026

Revert "feat(kanban): durable multi-profile collaboration board (Nous…

17b4f70

…Research#16081)" (NousResearch#16098) This reverts commit 3857c68.

02356abc pushed a commit to 02356abc/hermes-agent that referenced this pull request May 14, 2026

Revert "feat(kanban): durable multi-profile collaboration board (Nous…

2ce0f36

…Research#16081)" (NousResearch#16098) This reverts commit 15937a6.

dannyJ848 pushed a commit to dannyJ848/hermes-agent that referenced this pull request May 17, 2026

Revert "feat(kanban): durable multi-profile collaboration board (Nous…

10c9b5a

…Research#16081)" (NousResearch#16098) This reverts commit 39c1e9d.

kshitijk4poor mentioned this pull request May 19, 2026

fix(kanban): hoist all additive-column indexes out of SCHEMA_SQL (#28461) #28781

Merged

gweeteve pushed a commit to gweeteve/hermes-agent that referenced this pull request Jun 2, 2026

Revert "feat(kanban): durable multi-profile collaboration board (Nous…

87a77dc

…Research#16081)" (NousResearch#16098) This reverts commit 15937a6.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(kanban): durable multi-profile collaboration board#16081

feat(kanban): durable multi-profile collaboration board#16081
teknium1 merged 2 commits into
mainfrom
hermes/hermes-4dde9557

teknium1 commented Apr 26, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

teknium1 commented Apr 26, 2026

Hermes Kanban — durable multi-profile collaboration board

Summary

Motivation

What landed

Architecture in one picture

Collaboration patterns covered

Tests

Out-of-scope (deliberately)

Credits

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants