kanban-orchestratorlisted

# Kanban Orchestrator — Decomposition Playbook ## When to use the kanban board (vs `/goal` vs answering directly) File a kanban task when ANY of these are true: 1. **Multiple lanes are needed.** Research + implementation + review = three workers, ideally in parallel. 2. **The work should survive a daemon restart.** SQLite-backed; the dispatcher resumes on next tick. 3. **The user might want to interject mid-flight.** Comment, block, redirect — kanban gives you the surface. 4. **Subtasks can run in parallel.** Fan-out for speed (bounded by `max_concurrent_workers`, default 2). 5. **Iteration is expected.** Reviewer lane loops on implementer output via parent/child links. 6. **The audit trail matters.** `task_events` rows persist forever. Use **`/goal`** when it's a single multi-step task that benefits from continuous turn-by-turn iteration with one brain (it's the Ralph loop — same session, same cache, same context). Just **answer directly** when it's a one-shot reasoning task. Kanban + goal both add latency (60s dispatcher tick, fresh subprocess, no shared cache); skip the overhead when nothing's gained. ## The anti-temptation rules The agent's natural instinct is "I'll just do this quickly." That's almost always wrong when you're playing orchestrator. Enforce on yourself: - **Don't execute the work yourself when you've decided the board is right.** If you find yourself shelling out to `vexis-kanban` to mark a task done that you also did the work for inside the same t