Mission Control — Kanban Board Plan

Goal

Add a first-class Kanban Board to the Mission Control app that gives MP and Max Ops one clear execution surface for what is waiting, active, blocked, in review, approved, and shipped.

This should not be just another visual task list. It should become the daily execution board for campaigns, client work, internal builds, automations, approvals, and delegated agent work.

Recommended product direction

Build the Kanban board as a unified operator layer over existing Mission Control data:

• Airtable Tasks table
• Airtable Projects table
• Airtable Content Queue table
• Airtable Approvals table
• Airtable Assets table
• Airtable Workflow Runs table

Mission Control remains the operator UI. Airtable remains the source of truth unless/until we intentionally migrate data storage.

Why this matters

Right now Mission Control has separate pages for Tasks, Projects, Content Queue, Assets, Approvals, and Workflow Runs. That is useful, but MP’s day-to-day question is usually not “which table is this in?”

The real question is:

What needs attention, what is moving, what is blocked, and what can ship?

The Kanban board answers that directly.

Core board lanes

Recommended default lanes:

1. Inbox

- Raw ideas, incoming tasks, voice-note requests, campaign ideas, loose opportunities.

- Nothing here is committed yet.

2. Planned

- Chosen work that has a next action but is not actively being executed.

- Useful for this week / near-term work.

3. In Progress

- Work actively being executed by Max, Jessica, a sub-agent, MP, or another owner.

- Should be limited to prevent overload.

4. Blocked

- Waiting on access, decision, approval, client info, pricing, login, API key, or external dependency.

- This should be one of the most important lanes.

5. Review / Approval

- Creative, copy, campaign plans, generated assets, external posts, spend, automation changes.

- Anything that cannot ship without MP/human sign-off.

6. Ready to Ship

- Approved or complete items that only need scheduling, posting, sending, exporting, or launch.

7. Done / Shipped

- Completed work.

- Should include shipped date and output link when possible.

Optional specialized views

The same board data should be filterable into views:

Daily Command Board

Shows only today/this week/high-priority items.

Campaign Board

Filters to one campaign, such as Florida Renu Father’s Day.

Business Board

Filters by business:

• Florida Renu
• Chris Headshots
• Paradise Collection
• R. Allan Media
• PosePerfect Mat
• AI Infrastructure

Approval Board

Shows only review/approval/blocked items.

Agent Board

Groups by owner:

• MP
• Max Ops
• Jessica
• Specialist Agent
• Client / External

Card design

Each Kanban card should show enough context to act without opening 5 pages.

Minimum fields

• Title
• Business / project
• Status / lane
• Priority
• Owner
• Due date or target date
• Source table/type: Task, Project, Content, Approval, Asset, Workflow Run
• Next action
• Blocker / decision needed
• Linked record ID

Useful optional fields

• Campaign
• Platform: IG, FB, GBP, YouTube, email, etc.
• Approval status
• Asset preview thumbnail
• Output link
• Related brief/doc link
• Created date
• Last updated date
• Tags
• Automation run status

Card actions

Phase 1 can be mostly read-only with simple links. Phase 2 should add real actions.

Phase 1 actions

• Open source record/page
• Copy summary
• Filter by owner/business/status
• Search board
• Show/hide done

Phase 2 actions

• Move card between lanes
• Update priority
• Assign owner
• Add next action
• Mark blocked with reason
• Mark ready for approval
• Mark shipped/done

Phase 3 actions

• Create new card from Mission Control
• Convert inbox item into task/content/approval
• Create approval request
• Trigger Max/Jessica workflow
• Launch campaign workflow
• Schedule approved content

Implementation architecture

Option A — Fastest: use existing Airtable Tasks table only

Build /kanban from the existing Tasks table.

Pros:

• Fastest to build.
• Uses existing fields/statuses.
• Minimal schema risk.

Cons:

• Content, assets, approvals, and workflow runs still live separately.
• Less powerful as a true operator board.

Best use:

• Quick MVP.

Option B — Recommended: unified virtual Kanban

Build /kanban as a normalized view that pulls from multiple Airtable tables and maps them into one common card shape.

Example source mapping:

• Tasks → task cards
• Projects → project cards
• Content Queue → content cards
• Assets → creative cards
• Approvals → approval cards
• Workflow Runs → automation/run cards

Pros:

• Matches how MP actually works.
• One board for daily execution.
• Avoids forcing everything into Tasks.

Cons:

• More mapping logic.
• Drag/writeback requires per-table update rules.

Best use:

• Mission Control as a real operator console.

Option C — New dedicated Kanban Items table

Create a new Airtable table called Kanban Items that links to source records.

Pros:

• Cleanest long-term data model.
• Easy to manage lanes, ordering, WIP limits, custom views.

Cons:

• Requires Airtable schema changes.
• Risk of duplicate truth if not designed carefully.

Best use:

• If we want Kanban to become the main operating layer long-term.

Recommendation

Use Option B first: unified virtual Kanban from existing tables.

Then add a Kanban Items table later only if we need custom ordering, swimlanes, or more advanced board behavior.

This keeps momentum high and avoids schema churn.

Technical implementation plan

Step 1 — Add route and nav item

Add new app route:

mission-control-app/src/app/kanban/page.tsx

Add nav item in:

mission-control-app/src/lib/mission-control-data.ts

Suggested nav label:

• Label: Kanban
• Short label: KB
• Description: Unified execution board across tasks, projects, content, assets, approvals, and workflow runs.

Step 2 — Create normalized card type

Create a helper file:

mission-control-app/src/lib/kanban.ts

Example type:

```ts

export type KanbanCard = {

id: string;

source: "task" | "project" | "content" | "asset" | "approval" | "workflowRun";

sourceRecordId: string;

title: string;

lane: KanbanLane;

priority?: string;

owner?: string;

business?: string;

campaign?: string;

dueDate?: string;

nextAction?: string;

blocker?: string;

status?: string;

href: string;

};

```

Step 3 — Map statuses into lanes

Use a lane mapper so each table can keep its own statuses while the Kanban stays consistent.

Example mapping:

• Inbox, Idea, Draft → Inbox
• Planned, Queued, Scheduled → Planned
• In Progress, Running, Production → In Progress
• Blocked, At Risk, Failed, Error, On Hold → Blocked
• Review, Approval Needed, Needs Approval → Review / Approval
• Ready, Approved → Ready to Ship
• Done, Delivered, Published, Success, Shipped → Done / Shipped

Step 4 — Build read-only MVP UI

Page sections:

• Header: Mission Control Kanban
• Filter chips: Business, Owner, Source, Priority, Show Done
• Board columns
• Cards with title, source badge, business, owner, priority, next action, due date
• Empty states
• Airtable error box if fetch fails

Implementation can mirror the existing /tasks board style but with normalized cards.

Step 5 — Add filtering/search

Since this requires client-side state, split into:

• src/app/kanban/page.tsx server component for fetching records
• src/app/kanban/kanban-board.tsx client component for filters/search/show-done

Step 6 — Add writeback actions

Add server actions or API route:

src/app/kanban/actions.ts

Actions:

• moveKanbanCard(card, lane)
• updatePriority(card, priority)
• updateOwner(card, owner)
• updateNextAction(card, nextAction)

Each action maps back to the correct Airtable table and field names.

Step 7 — Drag and drop

Start with button-based lane changes first. Add drag/drop later if desired.

Possible approaches:

• Lightweight custom HTML drag/drop
• Add @dnd-kit/core package for proper drag/drop UX

Recommendation: use buttons first, then add drag/drop once writeback is proven.

Field/writeback mapping

Tasks

• Lane → Status
• Priority → Priority
• Owner → Assigned To
• Next action → Notes or Next Action if field exists

Projects

• Lane → Status
• Owner → Owner if field exists
• Next action → Next Action or Notes

Content Queue

• Lane → Status
• Platform → Platform
• Campaign → Campaign
• Due date → Published Date or scheduled date field

Assets

• Lane → Status
• Approval → Approval Status if available
• Output → asset link/attachment field

Approvals

• Lane → Status
• Decision → approval result
• Owner → approver/requester field

Workflow Runs

• Lane → Run Status
• Error/blocker → Error
• Output → result/summary field

How MP would use it

Morning use

Open Mission Control → Kanban.

Check:

1. Blocked

2. Review / Approval

3. In Progress

4. Ready to Ship

The board answers:

• What do I need to approve?
• What is Max/Jessica working on?
• What is stuck?
• What can ship today?

During work sessions

Use it as the active execution surface:

• Move campaign items from Planned → In Progress.
• Move creative assets to Review / Approval.
• Move approved content to Ready to Ship.
• Move posted/sent work to Done / Shipped.

For campaign launches

Example: Florida Renu Father’s Day campaign

• Brief → Planned
• Creative assets → In Progress
• Contact sheet / approval deck → Review / Approval
• Approved posts → Ready to Ship
• Scheduled/published posts → Done / Shipped
• Pricing uncertainty → Blocked

For Max/Jessica coordination

Jessica can use the board to:

• Monitor active lanes
• Escalate blocked items
• Prepare approval summaries
• Keep campaign tasks moving
• Update docs after completion

Max uses it to:

• Prioritize strategy
• Decide next moves
• Delegate sub-agent work
• Keep execution from fragmenting across chats/files

Board rules

To keep it useful:

1. In Progress should stay small. Ideally 3–7 items max.

2. Blocked must have a blocker reason. No vague blocked cards.

3. Review / Approval must say exactly what decision is needed.

4. Ready to Ship must have an output link or clear final action.

5. Done / Shipped must include shipped date or proof when possible.

6. Inbox should be triaged daily or weekly.

MVP build scope

Recommended first build:

• /kanban route
• Top nav link
• Unified read-only board from Tasks, Projects, Content Queue, Assets, Approvals, Workflow Runs
• Status-to-lane mapping
• Search/filter by business, owner, source, priority
• Card links back to source pages
• Show/hide Done lane

Do not build drag/drop first. Get the unified view correct first.

Phase 2 scope

• Update lane/status from board
• Add quick edit for priority/owner/next action
• Add create-card button
• Add Approval-only view
• Add Campaign view
• Add WIP count warnings

Phase 3 scope

• Drag/drop
• Custom ordering
• Kanban Items table if needed
• Saved views
• Agent assignment actions
• Command Desk integration: “Create Kanban card from this chat”
• Daily brief integration: “Top board changes since yesterday”

Suggested first implementation sequence

1. Build read-only /kanban page.

2. Normalize all existing table records into cards.

3. Add filters/search.

4. Test with current Airtable data.

5. Add a Florida Renu Father’s Day filtered view/use case.

6. Add writeback only after we confirm the field mapping is safe.

Final recommendation

Build the Kanban board as Mission Control’s execution cockpit — a unified, filtered, operator-first layer over the existing Airtable-backed system.

Start read-only, prove the view is useful, then add update/writeback. This avoids breaking Airtable while giving MP immediate clarity on what matters next.