Missions & Tasks

What it is

The execution backbone. A mission is a single deliverable that Genesis plans, decomposes into tasks, and runs to completion; a task is the atomic unit an agent or coder executes. Human approval gates inside the pipeline surface as decisions.

Operator surface

MCP tools cover the full lifecycle:

  • Mission lifecycle — mission_create, mission_get, mission_list, mission_decompose, mission_status, mission_pipeline_status.
  • Task review & approval — mission_tasks_list, mission_tasks_approve / mission_approve_tasks, mission_task_add.
  • Task-level control — task_create, task_get, task_list, task_update, task_retry, task_reset_retry, task_cancel, task_delete.
  • Decisions (human approval gates) — decision_list, decision_get, decision_respond, decision_acknowledge, decision_bulk_acknowledge, decision_stats.
  • Runs & changements (acceptance layer) — mission_run_start, mission_run_get, mission_run_accept, mission_run_discard, mission_revert_preview, mission_revert, mission_changement_stack. See Workflows §2.13 for the full run/accept/revert model.

The REST surface is MissionsController / TasksController / DecisionsController, and missions render on the dashboard mission pages.

How it works

A mission moves through Pending → Planning (decomposition) → InProgress → PendingReview → Completed / Failed, with Paused as a resumable side state and Cancelled as an early exit; Completed, Failed, and Cancelled are terminal. The Mission entity records its track, kind, project / matter linkage, token / cost rollups, selected model / provider, and integration-branch metadata. A mission's plan can come from LLM decomposition or from a published Workflow compiled into it — the lifecycle above is the same either way; only the plan's source varies.

Decomposition is LLM-driven and resolves the Missions:Decomposition site preset — which may route to a containerized coder that adds tasks via mission_task_add. Tasks (TaskDefinition + TaskEvent) are dispatched to agents / coders, and gate steps pause behind pending Decision rows resolved with decision_respond (approve / skip / fail). Mission and task state changes flow through an event queue (MissionEventQueue) consumed by the agent dispatcher.

Illegal status transitions are refused, not silently ignored. The Mission aggregate owns which transitions are legal, so asking for one it does not allow (e.g. Failed → InProgress, or any change out of a terminal status) is rejected rather than dropped into a no-op success. Over REST the status endpoint returns 409 with code mission.status.invalid-transition and a body carrying currentStatus, requestedStatus, and legalTransitions; the mission_status MCP tool returns a structured INVALID_STATE_TRANSITION error with the same three fields — so an agent or operator learns what it may do instead of receiving a success for a change that never applied. The legal-transition list is derived from the aggregate's own guards, so it cannot drift from the real rules.

Completed is terminal, with exactly one sanctioned exit: starting a fresh run on a completed mission reopens it to InProgress via an explicit reopen intent (ReopenForRun). The generic status-update path still refuses Completed → InProgress; reopening for a run is the only way a mission leaves Completed.

Missions are the substrate that Workflows compile into and that Agents drive; see those guides for the orchestration internals.