Missions Board
Run your mission portfolio from the Kanban board — create, transition, dispatch, and complete missions with an enforced definition of done.
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.
The Missions Board is a Pro surface — see Tiers: Pro & Ultra.
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, a fleet preset that does not fit its operations) — report-only, opened as a panel
Create a mission
- Click New Mission on the board.
- Give it a name (a lowercase, hyphenated identifier), a one-line description, and optionally a priority, dependencies, and a project grouping.
- 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 + New Operation, and a Details disclosure with the mission's Timeline and Files
The Operations row lists each operation as a pill carrying its status: click one to open its brief, right-click for its actions. + New Operation sits at the end of the row on any mission that has not reached a terminal state, and takes a name, a brief stating the operation's scope and what counts as done, and a starting status — planned by default, which is what a fleet pairs against. The mission's row in the sidebar tree offers the same action; both go through one dialog, so an operation created either way lands identically as a folder in the mission's operations container.
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
Drag the card. The four columns are drop zones, and so is the Archive drawer's toggle row — which accepts a drop even while the drawer is collapsed. This is the quickest gesture and the one to reach for.
Two other paths reach the same handlers: the card's action menu (Move to Planned / Active / Completed, Cancel with a reason, Archive, Delete) and the Mission Control status control.
A drop is never the last word. Because a drag is easier to trigger by accident than a menu click, every drop confirms first — and the dialogs that already guard a transition still interrupt it: dropping on Active opens the Manual-or-Fleet chooser, dropping on Cancelled asks for a reason, and dropping on Completed meets the completion gate exactly as the menu does.
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 open operations. One fleet per mission — dispatching again opens the existing workspace instead of starting a second fleet.
The chooser previews what Fleet would produce — N terminals · M operations — before you commit to it, so the fleet's size is never a surprise.
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.
Size the fleet
Operations are the sizing lever. A fleet defaults to one commander plus one terminal per open operation — planned and active both count. A mission with no operations falls back to your saved default for fleet launches, and its commander decomposes the mission and spawns workers as it creates operations. So the highest-leverage thing you can do before dispatching is pre-stage the operations you already know about: the fleet then comes up paired instead of empty.
You can override that in three places, in ascending order of authority:
| Where | What it does |
|---|---|
| The mission's Fleet field | A durable per-mission preset — the total terminal count, commander included. Set it once and every dispatch of that mission uses it, including a scheduled one. It is one of the mission's control fields, so it reads the same from the missions log and from the dossier's frontmatter, whichever you edit. Leave it empty to size from operations |
| The count in the launch dialog | Wins over both the preset and the derived size, for this launch only |
| Match operations, in the same dialog | The toggle that decides whether the count follows the operations at all. Off, you pin a number yourself and a one-click Match operations · N button appears whenever your number and the derived one disagree |
A derived size is capped: it will not propose more workers than the missions.maxWorkers configuration key allows (see the configuration reference), and when the cap bites, the dialog says what the size would have been. A number you authored is never silently rewritten — it warns and launches. The board's lint reports the same mismatches ahead of time: a Fleet preset that outruns the worker cap, one that undershoots the open operations, and one that is not a usable count at all.
The fleet plan
The dialog shows the pairing as a table — one row per terminal — before anything spawns. The same object names the panes, binds the operations, and briefs the commander, so what you approve is what stands up.
- One row is the commander, marked with a star. Click any other row to move the star there; the commander owns no operation, and the one it held is released back to the pool.
- Every other row picks its operation from the mission's open ones. Assigning an operation another row already holds moves it — one operation, one agent, enforced here rather than discovered after the terminals have spawned.
- A row with no operation is a floater — a worker the commander assigns at runtime.
- A line under the table states the mismatch plainly: how many operations are assigned, which are orphaned, and how many floaters there are. Orphans and floaters are legitimate outcomes, not errors — the point is that you meet them before launching rather than in a summary afterwards.
Operations can change between opening the dialog and launching — an agent may create or close one. A slot whose operation has gone terminal becomes a floater and is reported, never silently bound to nothing.
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 region of the dossier is machine-owned, and it is exactly where "edit freely" would trap you. The ## Operations section between the MISSION_OPERATIONS begin and end markers is rendered from the operations on disk on every reconcile — its own footer says so. Words written inside it are overwritten without warning. It exists so that an agent handed only the dossier — a grounded session, a scheduled dispatch, anyone reading with the app closed — can see that the mission has operations at all.
The direction is one-way for a reason: an operation's folder name carries its status, so there is exactly one authority and nothing to reconcile. To change an operation's state you rename or transition the folder; to say something about an operation in prose, write it outside the markers or in the operation's own brief.
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
- Run a mission — the same controls, walked end to end on one real mission
- Terminals — where a dispatched fleet lives, and how to watch and pause it
- Autonomy & controls — how far a dispatched agent may reach, and every switch that turns it down
- The operator model — the division of labor missions are built on
- The agent roster — the specialists mission work draws on