Mission Control

Documents

K

Spec: Mission Control Kanban Board

Design DocCreated Apr 2, 2026Updated Apr 1, 20269 min readFull screen ↗
Artifact Preview

Spec: Mission Control Kanban Board

All specs are artifacts. This document follows [ARTIFACT-GUIDE.md](/Users/vinny/.openclaw/workspace/ARTIFACT-GUIDE.md) for writing quality, exec summary rules, and source linking rules.

1. Problem Statement and Goal

Pete has no single place to see what is in play, what needs his attention, and what is done. The current Mission Control tasks page has placeholder data and columns that do not reflect the Pete-Vinny-David workflow. There is no visible boundary between "agents can keep working" and "Pete needs to review or approve something." This means Pete either gets interrupted constantly or things stall silently.

The goal is a chat-first kanban board where Pete captures and manages work through Discord conversation, with a web dashboard for bird's-eye visibility and basic direct manipulation.

2. Success Metric

Pete can open the MC Tasks page and within 5 seconds answer:

  1. What needs my attention right now?
  2. What is being worked on without me?
  3. What got done recently?

Pete can say "track this: fix Gmail model routing" in chat and see it appear on the board without opening MC.

3. Current State

Mission Control already has a tasks page with a kanban board.

What exists and works:

  • Five columns: Backlog, Next, In Progress, Blocked, Done
  • Data model: id, title, description, priority, tags, status, projectId,

createdAt, updatedAt

  • Drag-and-drop between columns
  • Click-to-edit modal (title, description, priority, tags, status, project)
  • API persistence (PUT /api/tasks reads/writes data/tasks.json)
  • Browser localStorage cache for offline resilience
  • Chat capture via "track this:" and "/mc-task" commands (existing

[mission-control-task-capture](skills/mission-control-task-capture/SKILL.md) skill)

What is missing:

  • Columns do not match the actual workflow (no review gate)
  • No way to distinguish what kind of activity is in progress
  • No assignee concept
  • No chat-driven task movement or status queries
  • Task descriptions are one-liners, not living documents
  • 6 stale sample tasks from March
  • A separate "Projects in Play" artifact exists that should migrate

to the board

4. Platform Capabilities

Mission Control is a Next.js app running locally on port 3100. Flat JSON file for storage. Existing API supports full CRUD.

OpenClaw agents can call the MC API directly. The chat capture skill already creates tasks from Discord messages via a Node script.

Chat-driven commands work through AGENTS.md automated workflow rules. When Pete says a trigger phrase, Vinny interprets it and calls the MC API. No new platform capability needed for this.

5. Community Patterns

mission control. Uses Inbox, Assigned, In Progress, Review, Done. Includes agent assignment. Closest to what we need.

with agent-to-agent handoff. Overkill for this scope.

Recommends mixing kanban with agent health visibility. Good idea for later, not this scope.

Documents Inbox, Assigned, In Progress, Review, Done as the standard pattern for human-in-the-loop workflows.

The community consensus: a Review column is the standard pattern for agent workflows with a human gate.

6. Options

Remap columns to match the actual workflow:

ColumnMeaningWho acts
BacklogCaptured ideas, not yet prioritizedAnyone adds
Up NextPrioritized, ready to startPete prioritizes
In ProgressSomeone is actively workingVinny or David
Needs ReviewWaiting on Pete to review, approve, or decidePete
DoneCompleted and acceptedAuto-archive later

Chat interaction model (Phase 1):

ActionHow
Create a task"track this: ..." in Discord (existing)
Move a task"move [task name] to up next"
Check status"what's on the board?" or "what needs my review?"
Get detail"what's the status on [task name]?"

Vinny interprets natural language and calls the MC API. No rigid command syntax. If the reference is ambiguous, Vinny asks.

Board interaction (keep existing, minor upgrades):

  • Drag between columns (already works)
  • Click card to see full detail and edit (already works)
  • Reorder cards within a column by drag (already works)

New data model fields:

  • assignee: free text (Pete, Vinny, David)
  • blocked: boolean flag with visual indicator (red left border)
  • Activity tags: spec, build, research to show what kind of work

is happening

Task descriptions become living documents. Not one-line summaries. The description accumulates context: original idea from chat, key decisions, links to specs/artifacts, blockers, and resolution notes. Vinny updates the description as conversations evolve.

Automatic lifecycle movement. Vinny moves cards based on what happens:

  • Spec written: tag with spec, link artifact in description
  • Pete approves spec: move to In Progress, retag to build
  • David finishes: move to Needs Review
  • Pete accepts: move to Done

Pete can always override by dragging on the board.

Blocked is a flag, not a column. A task can be blocked in any column. Red left border or icon on the card. Optional blocked reason in the description.

Projects as tags. No separate project system. Use consistent tag names like mission-control, job-search, linkedin. The existing tag field handles this.

  • Complexity: Low-medium. Column remap, 2 new fields, chat commands via

AGENTS.md rules, task description convention.

  • Reliability: High. Same persistence, same API.

Option B: Board-only with review gate

Same column changes as Option A, but no chat interaction. All task management through the web UI.

  • Complexity: Low. Just column/field changes.
  • Problem: Misses the AI-first value. Pete would have to context-switch

to MC for every task action.

Option C: Full workflow engine

Formal state machine with enforced transitions, webhooks, notifications.

  • Complexity: High.
  • Problem: Overkill. Pete drags freely. Vinny handles lifecycle.

7. Recommendation

Option A. Chat-first with basic board interactivity. The board shows the state, chat drives the action. This matches how Pete already works: conversations in Discord produce decisions and tasks. The board is the dashboard, not the input layer.

Start with the chat commands in Phase 1 (create, move, query). Add more board features later only if Pete finds himself wanting them.

8. Security Considerations

  • No new external access. Everything stays local and behind Tailscale.
  • Task data remains in a flat JSON file on the Mac mini.
  • Chat commands go through the existing AGENTS.md rule system, same as

"track this:" today.

  • No authentication changes. MC is accessible via Tailscale or localhost.

9. Implementation Scope

David builds:

Data model changes (lib/tasks.ts):

  • Change TaskStatus: "backlog" | "up-next" | "in-progress" | "needs-review" | "done"
  • Add optional assignee field (string)
  • Add optional blocked flag (boolean)
  • Update taskColumns array with new definitions
  • Remove sample/seed tasks (empty array default)
  • Write a migration in the API load path: rename "next" to "up-next",

convert any "blocked" status tasks to their previous column with blocked: true

UI changes (board):

  • Render new 5-column layout
  • Blocked indicator on cards (red left border or icon)
  • Assignee display on cards (small text below title)
  • Activity tags visually distinct from project tags (different color or

prefix)

  • "Needs Review" column with subtle accent highlight
  • Click-to-view detail: description rendered as markdown (already partial,

verify it works for longer content)

  • Remove "Reset sample board" button

UI changes (editor modal):

  • Add assignee field (dropdown or free text: Pete, Vinny, David)
  • Add blocked toggle
  • Ensure description field handles multi-paragraph markdown

Chat commands (Vinny-side, AGENTS.md rules):

  • "move [task name/fragment] to [column]": Vinny calls MC API to update

status

  • "what's on the board?" / "show me the board": Vinny reads tasks and

summarizes by column

  • "what needs my review?": Vinny filters for Needs Review column
  • "what's blocked?": Vinny filters for blocked flag
  • Natural language task references: Vinny matches by title substring,

asks if ambiguous

Data migration (one-time):

  • Migrate projects_in_play_2026_04_01.md items into tasks.json as real

tasks with appropriate columns, tags, and descriptions

  • Projects become tags on tasks, not separate entities
  • Archive the projects artifact after migration

No changes to:

  • Existing "track this:" capture (still creates Backlog tasks)
  • Artifacts page or other MC pages
  • Persistence model (flat JSON)
  • Authentication

10. Validation Criteria

  1. Open MC Tasks page. See five columns: Backlog, Up Next, In Progress,

Needs Review, Done.

  1. Create a task via "track this: test task" in Discord. Verify it appears

in Backlog on the board.

  1. Say "move test task to up next" in chat. Verify the card moves.
  2. Say "what needs my review?" in chat. Get a summary of Needs Review

column.

  1. Assign a task to "Vinny" via the editor. Verify assignee shows on card.
  2. Toggle blocked on a task. Verify red indicator regardless of column.
  3. Add tags spec and mission-control. Verify activity tag is visually

distinct from project tag.

  1. Click a card with a multi-paragraph description. Verify markdown renders

cleanly in detail view.

  1. Drag a card between columns on the board. Verify it persists after

page refresh.

  1. Open the board via Tailscale URL on phone. Verify basic usability.
  2. Verify projects from the old Projects in Play doc exist as tasks with

correct tags and descriptions.

11. Category

Tool (new functional capability in Mission Control + chat interaction rules)

12. Context Loading

David needs to read:

  • mission-control/lib/tasks.ts (data model, columns, types)
  • mission-control/components/tasks/TasksWorkspace.tsx (main board)
  • mission-control/components/tasks/TaskBoardColumn.tsx (column renderer)
  • mission-control/components/tasks/TaskCard.tsx (card renderer)
  • mission-control/components/tasks/TaskEditorModal.tsx (editor modal)
  • mission-control/data/tasks.json (current task data)
  • artifacts/projects_in_play_2026_04_01.md (for migration)
  • skills/mission-control-task-capture/SKILL.md (existing capture flow)
  • AGENTS.md automated workflows section (for chat command rules)

13. Guardrails

  • Do not add authentication or access control to MC in this scope
  • Do not build a separate projects system. Projects are tags.
  • Do not enforce state machine transitions. Pete drags freely.
  • Do not add real-time sync, websockets, or polling. Manual refresh is

fine for the board.

  • Do not change the persistence model (flat JSON stays)
  • Do not remove the artifacts page or any other MC pages
  • Do not add Discord notifications for task state changes
  • Do not build chat commands that modify multiple tasks at once
  • Keep the existing light-mode styling
  • Chat commands must confirm the action before executing if the task match

is ambiguous (more than one title match)

14. Handoff

David delivers:

  • Updated board code, MC service rebuilt and restarted
  • Projects in Play items migrated to tasks.json
  • Chat command rules added to AGENTS.md
  • Confirmation in #david with summary of changes
  • Pete verifies by:
  1. Opening MC Tasks at Tailscale URL
  2. Testing "track this:" and "move to" commands in #vinny
  3. Checking that migrated project tasks appear with correct context