Missions

Overview

A Mission is a higher-altitude workflow than a Loop: instead of a flat list of stages, it decomposes work into milestones, each holding a directed acyclic graph of features, with a validation checkpoint at the end of every milestone. The orchestrator drives one feature at a time through the same goal worker the Loop engine uses, then runs a validation worker before advancing to the next milestone.

Like Loops, missions are persisted in SQLite and run on the headless server. They keep working while the TUI is closed, survive process restarts (via lease/heartbeat), and emit bus events for the TUI to subscribe to.

Concepts

Mission schema

All persisted types are defined in packages/nikcli/src/mission/schema.ts as zod schemas. The shape is deliberately close to the Loop schema so the two engines can share tooling.

Feature

Milestone

Mission

Lifecycle

A mission moves through these states as the orchestrator walks it. The full MissionStatus schema in packages/nikcli/src/mission/schema.ts also carries planning and ready for the brief-to-milestones phase; the states below are the ones you see in the TUI and in bus events.

1. running — the orchestrator is actively driving features and validation.
2. paused — held by user request. No new features start; in-flight work is not aborted.
3. frozen — held automatically when a feature or validation worker has been aborted by a timeout or external error. Use mission resume to continue.
4. complete — every milestone reached done and the final validation (if any) passed.
5. error — a feature or the validation worker surfaced an unrecoverable error.

Per-feature timeouts

A hung feature can never hold the single-flight slot forever. Each feature run is capped (DEFAULT_FEATURE_TIMEOUT_MS = 60min), bridged to prompt.cancel on expiry. Bounds:

Validation policy

When every feature in a milestone has settled, the orchestrator runs a validation worker according to the milestone's validation policy. The validation worker is itself a goal command targeting the mission's validation model (or the worker model if unset).

CLI subcommands

nikcli mission is a thin headless wrapper over the orchestrator. It accepts a brief from a file or flag, generates a draft plan, and lets you start, pause, resume, or cancel execution.

# Draft a mission from a brief file and start it
nikcli mission new -f ./brief.md --agent build --model anthropic/claude-sonnet-4.5
nikcli mission start mss_abc123

# Watch progress
nikcli mission get mss_abc123

# Pause and resume
nikcli mission pause mss_abc123
nikcli mission resume mss_abc123

# Cancel
nikcli mission cancel mss_abc123

Bus events

The orchestrator publishes typed bus events for the TUI, mobile, and SDK clients to subscribe to. They live next to the orchestrator in packages/nikcli/src/mission/orchestrator.ts.

TUI surface

The TUI mission feature-plugin lives in packages/tui/src/feature-plugins/mission/. It mirrors the loop plugin and exposes:

• Mission home view — list of all missions with status chips, last run time, and quick actions (start, pause, resume, cancel).
• Mission detail view — per-milestone tree, per-feature rows, current feature highlight, validation status, and the live session id of the active worker.
• Draft dialog — paste a brief, pick an agent and a model, and create a mission without leaving the TUI.
• Validation review dialog — approve or reject user-test milestones. Approval advances the mission; rejection marks the milestone blocked.

The plugin subscribes to the bus events above and batches updates into Solid signals. The same source of truth is consumed by the mobile app and the web app.

Failure modes

Source anchors