Mission Control v2 Architecture

Executive Summary

Mission Control v2 replaces the current task-board-as-runtime model with a proper operating ledger. First-class records for requests, tasks, runs, checkpoints, artifacts, decisions, evals, and layered memory give agents and Pete a shared, auditable state machine instead of scattered JSON files and chat history. The current app shell, local-first bias, and project/task surfaces are preserved; the state model underneath gets rebuilt.

Bottom line

Mission Control v2 should stop pretending a task board is an agent runtime. The current app is a solid local-first shell, but the source of truth is still basically tasks.json plus UI state. v2 should introduce a real operating ledger with first-class records for requests, tasks, runs, checkpoints, artifacts, decisions, evals, and layered memory.

Keep the current app shell, local-first bias, and project/task surfaces. Rebuild the state model underneath.

What exists today

Current Mission Control is a Next.js local-first app with:

• UI shell and navigation
• Dashboard, Tasks, Projects, Automation, Tools, Settings pages
• durable local JSON stores for data/tasks.json and data/projects.json
• basic API routes at app/api/tasks/route.ts and app/api/projects/route.ts
• a lock + atomic write pattern in lib/tasks-store.ts and lib/projects-store.ts
• a narrow markdown renderer in components/tasks/TaskMarkdown.tsx

That is useful. It is not yet an agent operating system.

v2 design principles

1. Conversation is not state

• Discord is the work surface.
• Mission Control is the durable record.
• No task or run should depend on finding the right Discord message later.

1. Runs are the runtime primitive

• A task may have multiple runs.
• A run is the unit of execution, traceability, checkpointing, and eval.

1. Artifacts are first-class

• Outputs should not be buried in chat.
• Every substantial output gets an artifact record, storage path, preview metadata, and lineage.

1. Checkpointing is policy-driven

• Pause on ambiguity, side effects, low confidence, conflict, or explicit approval gates.

1. Memory is layered

• Scratchpad, operational state, decisions, curated memory, and source knowledge are different things and need different write permissions.

1. Local-first remains the default

• JSON files are acceptable for v2 phase 1.
• Do not introduce heavy infra before the state model is correct.

Recommended system shape

Layer 1: Interaction surfaces

• Discord
• intake
• status nudges
• checkpoint asks
• completion summaries
• artifact summary cards
• Mission Control UI
• review console
• artifact browser
• run timeline
• decision ledger
• eval review

Layer 2: Application services

These can start as simple TypeScript modules behind API routes.

• request-service
• task-service
• run-service
• checkpoint-service
• artifact-service
• decision-service
• eval-service
• memory-service
• timeline-service

Layer 3: Canonical local stores

Recommended initial layout:

mission-control/
  data-v2/
    requests.json
    tasks.json
    runs.json
    checkpoints.json
    artifacts.json
    decisions.json
    evals.json
    memory-entries.json
    timeline-events.json
    views/
      artifact-previews/
      artifact-thumbnails/
      artifact-pdfs/

Each file can use the same lock + atomic replace pattern already used by the task store.

Layer 4: File-backed artifact storage

Recommended initial layout:

mission-control/artifacts/
  by-id/
    artifact_xxx/
      source.md
      preview.html
      snapshot.png
      snapshot.pdf
      meta.json

Do not rely on Discord attachments as the only artifact store. Discord is a delivery surface, not the archive.

Core object graph

Request
  -> Task[]
Task
  -> Run[]
Run
  -> Checkpoint[]
Run
  -> Artifact[]
Run
  -> Eval[]
Artifact
  -> Decision[]
Decision
  -> Memory write candidates

This is the main change from v1. Projects and kanban lanes become views over these objects, not the backbone.

Runtime flow

1. Intake

A user asks for something in Discord or a cron trigger fires.

Mission Control creates:

• request
• one or more task records
• a briefing packet snapshot for the assigned agent

2. Dispatch

Vinny assigns a task to Wendy or David.

Mission Control creates:

• run with assigned agent, objective, constraints, and time budget
• initial timeline event
• packet version attached to the run

3. Execution

The agent works.

Mission Control records:

• run status changes
• tool-level or summary-level events
• produced artifacts
• assumptions
• blockers
• checkpoint requests

4. Review

If the run needs human judgment or a policy pause, Mission Control opens a checkpoint.

Discord receives a concise summary with buttons or a short answer prompt. Mission Control retains the full evidence set.

5. Completion

On completion, Mission Control stores:

• completion summary
• recommendation
• final artifacts
• any linked decisions
• eval results
• suggested memory writes

6. After-action

The system may:

• promote selected facts into curated memory
• queue follow-up tasks
• mark the request resolved or partially resolved

Mission Control UI v2

Do not replace the whole product shell. Extend it.

Keep

• Sidebar and overall shell
• local-first API/store pattern
• tasks and projects as operating views

Add

1. Requests page

• new intake queue
• by source: Discord, cron, manual, imported
• filters: untriaged, active, waiting, resolved

1. Runs page

• active runs
• latest checkpoint
• assigned agent
• duration, time budget, confidence, last event

1. Artifacts page

• artifact cards with preview type
• summary, owner run, source task, linked decision
• mobile-friendly preview status

1. Decisions page

• decision log with rationale and reversibility
• links to evidence and revisit dates

1. Evals page

• pass/fail and scored reviews
• recurring failure modes
• agent-by-agent reliability trends

1. Task detail v2

• current task state
• active run
• artifacts
• checkpoints
• decision history

Dashboard changes

The dashboard should answer:

• What is currently running?
• What is blocked on Pete?
• What artifacts were produced today?
• Which decisions were made?
• Where are repeated failures happening?

Artifact Review UX, opinionated design

This is the new pain point, so it needs its own concrete answer.

Problem

Long markdown artifacts are miserable in Discord, especially on mobile. Raw .md attachments are not meaningfully reviewable there.

v2 artifact delivery contract

For every artifact above a small threshold, generate four outputs:

1. source.md or source file
2. preview.html rendered from markdown
3. snapshot.png first-page or summary snapshot for quick scan in Discord
4. snapshot.pdf printable full version for high-fidelity review

Also store a compact artifact-summary-card object with:

• title
• one-sentence summary
• key takeaways
• estimated read time
• word count
• linked task/run
• preview availability flags

Discord delivery pattern

Never dump giant bodies by default.

Standard pattern

1. Send a short completion summary
2. Attach or link a visual preview
3. Offer access paths:

• inline summary
• image preview
• PDF attachment
• Mission Control link for full interactive read

Message format

• Message 1: 5 to 10 line summary card
• Message 2: image preview or PDF if useful
• Message 3 only if needed: thread reply with chunked sections

Chunking rules

• Post only summary + top findings in the main channel
• Put long text into a thread if Pete explicitly wants it in Discord
• Chunk by semantic section, not arbitrary character count
• Prefix each chunk with Part 1/4, Part 2/4, etc.

Best mobile option

Discord mobile does not reliably render attached markdown. So the best path is:

• generate PNG summary snapshot for immediate scan
• attach PDF for readable full document
• include a link to rendered HTML when available

Rendered markdown on mobile

The practical routes are:

Option A: Local HTML preview page inside Mission Control, best long-term

• artifact gets a route like /artifacts/[id]
• server renders markdown to HTML
• page has clean typography and phone layout
• if Pete opens the link on mobile, he gets an actual readable page

This is the best answer if local network access is workable.

Option B: Static HTML export saved beside the artifact, good phase 1

• generate preview.html
• serve it from a simple route or file server
• works even before a rich artifact page exists

Option C: PDF only, acceptable fallback

• readable on mobile
• worse for skimming and inline navigation than HTML
• better than raw markdown by a mile

Mission Control laptop rendering

Mission Control should provide a real document reader, not a textarea pretending to be one.

Artifact detail layout

Left rail:

• title
• type
• owner run
• task
• decision links
• created time
• tags
• preview actions

Main pane:

• rendered markdown or document body
• sticky table of contents for headings
• code blocks, lists, links, callouts
• inline citations or source links

Right rail:

• summary
• key decisions
• eval status
• follow-up actions
• version history

Required controls

• rendered view / raw view toggle
• open PDF
• copy summary
• copy citation
• compare versions
• mark as reviewed
• promote to decision or memory

Recommended implementation phases

Phase 0: salvage current app shell

Keep:

• app shell
• nav patterns
• JSON stores
• local APIs

Do not keep as canonical runtime model:

• tasks-only data model
• task notes as artifact substitute
• dashboard cards that are not backed by real ledger objects

Phase 1: ship the ledger under the current UI

Add canonical stores and APIs for:

• requests
• runs
• artifacts
• checkpoints
• decisions
• evals
• memory entries
• timeline events

Leave current Tasks and Projects views intact, but start linking tasks to runs and artifacts.

Phase 2: ship artifact review

Add:

• artifact renderer service
• artifact page
• PNG and PDF generation pipeline
• Discord summary-card delivery contract

Phase 3: replace task board semantics

Tasks become work units with state linked to runs and decisions. The kanban becomes a view over canonical task state, not the record itself.

Memory vs artifact boundary in the data model

Design constraint

Memory and artifacts serve different purposes and must remain separate in the data model, not just by convention.

• Memory entries (memory-entries.json) store durable facts: decisions, preferences, SOPs, validated truths. They are the system of record.
• Artifacts (artifacts.json + artifacts/by-id/) store reviewable work products: drafts, analyses, proposals, specs, evidence.

Storage separation

These are not different views of the same data. They are different record types with different lifecycles:

Promotion workflow

When an artifact leads to a decision or confirmed fact:

1. The reviewing agent (usually Vinny) creates a new memory entry with the distilled fact.
2. The memory entry records promoted_from: { artifact_id, run_id } as provenance.
3. The artifact's status updates to accepted or superseded.
4. The artifact itself is not modified; the memory entry is the new truth.

Memory entry schema (proposed)

{
  "id": "mem_xxx",
  "tier": "preference | operational | decision | curated",
  "content": "Pete prefers light mode for Mission Control",
  "source": {
    "type": "observation | artifact_promotion | direct_input",
    "artifact_id": null,
    "run_id": null,
    "timestamp": "ISO-8601"
  },
  "supersedes": null,
  "created_by": "vinny",
  "created_at": "ISO-8601",
  "confidence": "high | medium",
  "tags": []
}

Implementation note (doc only, not yet built)

This schema and the promotion workflow are spec. Implementation is deferred until the MC v2 ledger phase begins. Current agents follow the classification rule defined in AGENTS.md using existing storage (MEMORY.md, memory/*.md, artifacts/by-id/).

Where the codebase should change first

1. State model refactor start point

Start in mission-control/lib/tasks-store.ts.

Why:

• it already has the right durability pattern
• it is small and understandable
• it can be copied into v2 stores for new objects

Create parallel stores first, do not mutate the existing task store until the new ledger is proven.

2. Artifact renderer start point

Start from mission-control/components/tasks/TaskMarkdown.tsx, but do not keep it as the long-term renderer.

Why:

• it proves there is already appetite for markdown rendering
• it is currently too limited for real artifacts
• it can be generalized into an ArtifactRenderer and ArtifactSummaryCard

3. UI insertion point

The safest first UI addition is a new /artifacts page and simple artifact API route.

Why:

• no destructive migration needed
• easy to test in parallel with existing Tasks and Projects
• directly addresses Pete's review pain

Opinionated recommendation

Do not start with a database migration or a full UI rewrite. Start with a parallel v2 ledger plus artifact rendering. That gives Pete visible value fast and sets the right foundation.

Best next implementation step

Build this exact slice first:

1. lib/mc2/ types + stores for runs, artifacts, and timeline-events
2. /api/artifacts and /api/runs
3. artifact generation contract: source.md, preview.html, snapshot.png, snapshot.pdf
4. /artifacts page with card list and detail reader
5. Discord delivery helper that posts summary + preview, not giant markdown

That is the shortest path from current shell to a real agent-ops system.