missions

This server is the agent door to the missions cockpit — the registry the Missions Board sits on. Its 12 tools cover the full portfolio surface: create and list missions, read one in full, transition lifecycle states, group missions into projects, attach and list mission documents, read the event timeline, create and transition operations inside a mission, 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.

Prerequisites

No keys and no model cost — this is registry access over your own files and the local missions database. 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).

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