omp

📋 Kanban under OMP

Kanban options for the OMP runtime — pi-kanban session observability, pi-board task boards, @dustinbyrne/kb autonomous worktree boards, @pi-unipi/kanboard doc boards, the Hermes status board, and the cronsban gateway — with the Pi/OMP boundary for each.

Several different things are called “kanban” in this workspace, and they solve different problems. Pick by the data you want on the board, keep each plugin’s Pi-facing contract Pi-named, and adapt only at the OMP boundary (see Pi Plugin Compatibility ). For the end-to-end operating loop use the OMP + Kanban + Crons Swarm Quick-Start ; for the full gateway design, the Cronsban Full Blueprint .

Which kanban?#

Option Board shows Use when Data / storage
pi-kanban Pi sessions, todos, subagents, observability You want to watch the agent work live Reads Pi session JSONL + companion data; web/app via SSE
pi-board Real tasks, sprints, WIP limits, stats You manage planned work as a task board .pi/board.db; WebUI http://localhost:3333 (PI_BOARD_PORT)
@dustinbyrne/kb Autonomous tasks executed by agent teams in git worktrees You want the board to schedule, execute, review, and optionally merge work Dashboard /kb; default port 4040; worktrees; auto-merge is on by default
@pi-unipi/kanboard Specs, plans, milestones from .unipi/docs/ You drive the unipi document workflow Parses .unipi/docs/; HTTP 8165–8175; needs @pi-unipi/core
Hermes Kanban Generated public task status You want a safe published status summary Generated from Nexus kanban.json; read-only
Cronsban gateway Durable queued / autonomous jobs You need crash-safe queued work, not just a view SQLite WAL queue + event log

These are complementary, not interchangeable. Run more than one only with clear ownership of ports and state.

pi-kanban (session / subagent observability)#

Web dashboard for the Pi coding agent itself — sessions, todos, subagents, and observability. The package manifest declares extensions: ["./extensions"]. It is a viewer of agent state, not a task tracker.

Commands:

/kanban start | stop | restart | status | open web|app
/kanban session open | pin | sticky-pin | unpin | view-doc | link-doc
npx pi-kanban            # standalone, no live session needed

Companion extensions it renders (install for the full picture):

pi install npm:pi-subagents                         # named subagent sessions
pi install npm:@juicesharp/rpiv-todo               # todos shown as kanban columns
pi install npm:@juicesharp/rpiv-ask-user-question  # interactive Q&A cards

Pi-facing surface (keep as-is)#

  • Install with pi install npm:pi-kanban; resources load from the package’s ./extensions dir.
  • Reads Pi session state (session JSONL) plus companion-extension data.
  • Configuration knobs stay PI_*.

OMP boundary (adapt only here)#

  • Session discovery is the load-bearing knob. OMP sessions live in ~/.omp/agent (PI_CODING_AGENT_DIR); pi-kanban shows nothing useful unless it reads that path. Verify it actually does — do not assume path parity with ~/.pi. If it hardcodes the Pi default, add an explicit sync/adapter.
  • Install into ~/.omp/plugins.
  • pi-subagents spawns child sessions: never let them default-spawn pi. Route the spawn command through /home/mc/.local/bin/omp-plugin-env --allow-home so children run under OMP.
  • Keep the web/app server on localhost; remote access requires HTTPS + auth. Treat session content as private — never auto-publish it (it can contain secrets).

Verify#

  • Extension loads: /kanban status reports running.
  • /kanban open web lists OMP sessions (proves session-dir wiring), not an empty board.
  • rpiv-todo items appear as columns; pi-subagents sessions appear under their parent.
  • Spawned subagents are OMP processes (check session dir / ps), not pi.
  • Dashboard is reachable only locally; no session text leaks to public surfaces.

@dustinbyrne/kb (autonomous worktree execution board)#

This is the one to consider when “kanban” means the board drives the work, not just observes it. You add high-level task ideas; a triage agent turns them into specs, a scheduler orders dependencies, executor/reviewer agents work in isolated git worktrees, and completed work can be squash-merged back automatically.

Commands:

pi install npm:@dustinbyrne/kb
/kb              # start on default port 4040
/kb stop         # stop it
/kb 8080         # run on a custom port

Why it was not the first default recommendation: it is load-bearing automation. Unlike pi-kanban, which mainly observes sessions, @dustinbyrne/kb can spawn multiple agents, create worktrees, infer dependencies, let agents create follow-up tasks, and auto-merge completed work. That is powerful, but under OMP it needs a source/config review before installation.

For the high-autonomy setup path, see KB under OMP .

Pi-facing surface (keep as-is)#

  • Install with pi install npm:@dustinbyrne/kb; the package manifest loads ./dist/extension.js.
  • Keep the /kb command and Pi package naming.
  • Treat package docs that say “pi” as the upstream plugin contract.

OMP boundary (prove before enabling automation)#

  • Install into ~/.omp/plugins.
  • Any triage/executor/reviewer/follow-up agent spawn must use /home/mc/.local/bin/omp-plugin-env --allow-home, not a hardcoded pi.
  • Keep the dashboard on localhost unless HTTPS + auth are in front of it.
  • Disable auto-merge or use manual review until the source confirms the merge policy, worktree cleanup, and spawn command are OMP-safe.
  • Do not install from the package page blindly; Pi packages execute code and this one is designed to influence repo state.

Verify#

  • /kb starts on the expected local port.
  • A test task creates an OMP-backed worktree/session, not a Pi child process.
  • Dependency ordering is visible before execution starts.
  • Auto-merge policy is explicit and tested with a disposable branch before use on live work.
  • Worktree cleanup does not remove unrelated user work.

@pi-unipi/kanboard (document workflow board)#

A different tool that shares the word “kanban”: it visualizes a document workflow, not runtime sessions. An HTTP server (htmx/Alpine) plus a TUI overlay render specs, plans, milestones, and related docs parsed from .unipi/docs/ as cards. Commands /unipi:kanboard and /unipi:kanboard-doctor; default ports 8165–8175; PID file .unipi/kanboard.pid; depends on @pi-unipi/core.

  • Pi-facing: pi install npm:@pi-unipi/kanboard; reads cwd-relative .unipi/docs/; @earendil-works/pi-* peers.
  • OMP boundary: install into ~/.omp/plugins; run OMP with --allow-home so cwd (and .unipi/docs/ + the PID file) stay anchored under ~; keep the port local. No spawn override needed — it only reads and serves.
  • Caveat: it shows nothing unless the workspace actually uses the .unipi/docs/ layout. Adopt it only if you use the unipi document workflow.

Boundary recap#

Every option keeps its Pi-facing contract Pi-named. The only OMP-specific adaptation is at the boundary:

install         → ~/.omp/plugins
sessions        → PI_CODING_AGENT_DIR=/home/mc/.omp/agent
child spawns    → /home/mc/.local/bin/omp-plugin-env --allow-home
stable cwd/env  → omp --allow-home   (+ PI_DISCORD_ENV_FILE=/home/mc/.env where relevant)

Sources: https://pi.dev/packages/pi-kanban , https://pi.dev/packages/@dustinbyrne/kb , https://pi.dev/packages/@pi-unipi/kanboard , https://pi.dev/packages/pi-board , /home/mc/wiki/content/omp/kanban-crons-swarm.md, /home/mc/wiki/content/omp/plugin-compatibility.md, /home/mc/docs/omp-coms.md, /home/mc/docs/omp-pi-plugin-cheatsheet.md.