missions

This server is the agent door to the missions cockpit — the registry the Missions Board sits on. Its 14 tools cover the full portfolio surface: create and list missions, read one in full, transition lifecycle states, group missions into projects, list a mission's documents, read the event timeline, create and transition operations inside a mission, delete an empty mission or a finished operation, and lint the registry for inconsistencies.

The design fact that shapes every tool here: the files are the source of truth. A mission lives as a folder and dossier on disk under your documents tree; the database behind the board is a rebuildable projection of those files. So mission_create scaffolds a real folder you can open and read, transitions rename it through its lifecycle with contents preserved, and mission_lint exists precisely to catch file-vs-registry drift before it confuses anyone. Agents and the board work the same registry — a mission an agent opens mid-session appears on your Kanban immediately, subject to the same enforced lifecycle and definition of done. The server also connects to the terminal control plane, which is how dispatching a mission can stand up a live commander-and-workers fleet in the Terminals view.

How your agents use it

• "Open a mission for the documentation overhaul." — mission_create scaffolds the folder and dossier; mission_transition moves it to active when work starts, and through the completion gate when it is done.
• "Brief me on this mission." — mission_get for the current state, mission_documents for the working files, mission_events for the timeline of what has happened.
• "Split the work into operations." — operation_create per workstream inside the mission folder, operation_transition as each one moves from planned to completed.

What an agent may delete

Neither "agents cannot delete missions" nor "agents can delete any mission" is true, and the shape in between is deliberate. mission_delete is a cleanup verb for a mission that never really started: it refuses anything carrying operations or Success Conditions, a live fleet, a dependent mission, or a Calendar entry pointing at it — and says which. Real work is retired with mission_transition instead (cancel or archive), which keeps the history. operation_delete refuses an active operation until it is transitioned first.

Both are stopped by the same pause that stops everything else on the terminal plane, both are recorded in the audit log, and both move the folder to your operating system's trash rather than erasing it — so a deletion you did not want is a restore, not a rebuild.

Prerequisites

Command Center must be running. This server holds no state of its own; it reaches the registry through the same local control endpoint the terminal plane uses, so with the app closed there is nothing to answer. No keys and no model cost.

Subscription. Missions are part of Pro. Without an active subscription the reading half keeps answering — list, read one in full, documents, events, lint — while creating, transitioning, grouping and deleting are refused with a result naming the tier it needs and where to upgrade. Both paid tiers pass; Tiers covers what each includes.

Dispatching a fleet from a mission additionally requires the terminal control plane to be enabled (see cc-terminals and the configuration reference).

Tool reference

Tool	Parameters	What it does
mission_create	name*: string, description: string, priority: string, depends_on: string, project: string, lifecycle: string, created_by: string	Create a mission DB-FIRST. The deterministic materializer writes the MISSIONS_LOG registry block + the mission folder + dossier + operations container (create-only); the reconciler then projects + logs it. No byte-exact hand-crafting. Returns the slug.
operation_create	mission*: string, name*: string, brief: string, status: string, created_by: string	Create an operation DB-FIRST under a mission (folder + brief, create-only). Returns the operation id '<mission>/<op>'.
mission_list	created_after: string, created_before: string	List all missions (projection rows: slug, lifecycle, priority, goals met, ordinal, …).
mission_get	slug*: string	Get one mission's full detail — the mission row + its operations + its goals.
mission_documents	slug*: string	List the files the reconciler picked up under a mission (dossier/brief/output/…, op-linked).
mission_events	slug*: string, limit: integer	A mission's event timeline (newest first) — status changes, op statuses, goals met, docs added.
mission_transition	mission*: string, to*: string, reason: string, force: boolean	Transition a mission's lifecycle (planned/active/completed/cancelled/archived) — the guarded Rust verb: folder rename + terminal snapshot/stub + section relocate + an actor-attributed Timeline event. A move to 'completed' is GATED on all Success Conditions met + all operations terminal; on a gate error, surface the unmet list to the operator and only retry with force=true if they approve (a forced completion is audited as completion_forced).
operation_transition	mission*: string, op*: string, to*: string	Transition an operation's status (planned/active/completed/failed) — the coupled folder+brief rename + frontmatter sync + an actor-attributed Timeline event. Replaces the error-prone manual double-rename.
mission_lint	—	The registry-health lint (report-only): per-mission findings — uuid mismatches (log/db vs dossier), unknown/void depends-on refs, blocks over the offload budget, missing ops containers, stale overview conflicts, missing Lifecycle fields — plus the whole-log token estimate vs its budget. Never mutates.
project_create	name*: string, description: string, priority: string, lifecycle: string, created_by: string	Create a PROJECT DB-FIRST (Phase 3) — a grouping entity for related missions. Writes the PROJECTS_LOG block + the project folder + dossier; the reconciler projects it. Missions ASSOCIATE to a project (via mission_set_project or the mission's project field), never fold in. Returns the slug.
project_list	—	List all projects (the grouping registry: slug, lifecycle, priority, associated-mission count).
mission_set_project	mission*: string, project: string	Associate a mission with a project, or clear it (empty project). Writes the mission's **Project:** field; the reconciler resolves it to the immutable project uuid (rename-stable).
mission_delete	mission*: string	Delete an EMPTY mission (no operations AND no Success Conditions) — the throwaway-cleanup verb. REFUSES (structured DELETE_REFUSED) when the mission is NOT empty (cancel or archive it via mission_transition instead — recoverable, keeps history), has a live fleet, has a dependent mission, or is referenced by a Calendar entry. Recoverable OS trash; pause-gated + audited.
operation_delete	mission*: string, op*: string	Delete an operation (trash its folder, recoverable). REFUSES an active operation (transition it to planned/failed/completed first). Pause-gated + audited.

Where to go next

• Missions Board — the Kanban over this registry, and the enforced definition of done
• Missions, operations & the fleet — the model: missions, operations, commanders, workers
• cc-terminals — the plane a dispatched fleet runs on