Missions Board

The Missions Board is the cockpit for everything the mission model describes: a live Kanban of your mission portfolio, with a control strip for every lifecycle action. This page is the how-to for operating it. For the mental model — what missions, operations, and fleets are — read the concept page first.

Open it from the sidebar: Missions Board. The view holds the board itself plus tabs for the strategic files (Active Directives, Strategic Context, the Missions Log) and Session Digests; a sidebar tree lists each mission with its dossier, documents, and operations, with lifecycle filter pills and right-click menus for document and operation actions.

Read the board

Four columns — Planned · Active · Completed · Cancelled — plus a collapsible Archive drawer. Each card shows:

• the mission name and a priority marker
• a goals meter (n/m met) — how many success conditions are checked off
• an operations breakdown — a per-status dot legend, expandable to the operation list
• a BLOCKED pill when a dependency is unfinished
• a lint badge when the registry-health check has findings (stale missions, archival due, oversized log entries) — report-only, opened as a panel

Create a mission

1. Click New Mission on the board.
2. Give it a name (a lowercase, hyphenated identifier), a one-line description, and optionally a priority, dependencies, and a project grouping.
3. The mission appears in Planned — and gets a working folder on disk immediately, with its dossier and an operations container. You can pre-stage operations and planning documents before the mission ever activates.

Then spend one deliberate minute on the Success Conditions: open the dossier and write the definition of done as a checklist, each item with an — evidence: note describing what proves it. These checkboxes are not decoration — they are the completion gate (below), and well-written conditions are the highest-leverage input you give a mission.

Mission Control: the control strip

Selecting a mission surfaces the Mission Control bar — the single control surface for that mission:

• Status — move the mission through its lifecycle
• Priority, project, and dependency chips (dependencies show live state: satisfied, blocking, or void)
• Rename inline — the folder, registry, and history all follow; nothing is orphaned by a rename
• Dispatch — appears when the mission is active with no fleet running (see below)
• Operations metric tiles, and a Details disclosure with the mission's Timeline and Files

The Timeline is a durable event history: every status change, operation transition, goal met, document added, and forced completion is recorded per mission and viewable inline. Files lists the documents accumulated in the mission's folder.

Move a mission through its lifecycle

Use the card's action menu (Move to Planned / Active / Completed, Cancel with a reason, Archive, Delete) or the Mission Control status control. The lifecycle is planned → active → completed or cancelled, with Archive as a filing action that moves the folder off the board while keeping the mission's record and history — nothing is ever deleted by a transition, and a terminal mission can be re-activated later.

Completion is gated. A mission cannot move to Completed until every success condition is checked and every operation has reached a terminal state. If the gate fails, the error names exactly what is unmet. You can force-complete past the gate — the override is recorded in the Timeline as a forced completion, so it is always visible that the gate was overridden.

Activate vs. Dispatch

Two deliberately distinct verbs:

• Activate flips the mission's lifecycle to active. Moving a planned mission to active opens a chooser: Manual activates without standing anything up — right when you drive the mission yourself, or hand pieces to individual agents as you go.
• Dispatch (the Fleet choice, or the Dispatch button on an already-active mission) stands up a working fleet: a terminal workspace with one commander session and worker sessions, grounded with the mission and paired with its planned operations. One fleet per mission — dispatching again opens the existing workspace instead of starting a second fleet.

The fleet then runs in the Terminals view, where you watch it live, take over any pane, or pause all agent activity with one control. A practical maturity note, stated plainly: the board, the mission records, and single-agent mission work are everyday surfaces; the fully hands-off fleet run is designed and built, and it is best run with you watching in the Terminals view.

The files are the record

The board is a projection of plain Markdown on disk — the missions registry and each mission's folder. That has three practical consequences:

• Edit files directly whenever you like. You or an agent can change a mission's status field, add an operation folder, or update the dossier in any editor; the board catches up within a moment.
• The projection is disposable. The board's database can be deleted and is rebuilt from the files on the next start. You never repair a database — the Markdown is the truth.
• Edit one narrative surface at a time. A mission's overview text exists in the registry block and the dossier, kept in sync. If both are edited between syncs, the conflict is flagged on the Timeline instead of either side being overwritten — resolve it by picking one.

One hygiene rule for hand-editing the registry files: use an editor that preserves Unix (LF) line endings. The registry parsers are tolerant, but Windows-style line endings in the log files are the one editing habit worth avoiding.

Where to go next

• Missions, operations & the fleet — the mental model behind the board
• Terminals — where a dispatched fleet lives, and how to watch and pause it
• The operator model — the division of labor missions are built on
• The agent roster — the specialists mission work draws on