Create a hamgoose mission. Use this to START a mission for the user.

Guided setup protocol:

1. If the user has not stated a clear goal, ask for it (one short question).

2. Ask ONCE whether they have rules/constraints worth recording (e.g. concurrency limits, provider/model for workers, git on/off, validation toggles). If they say none, proceed with defaults - do not interrogate.

3. Pass their rules VERBATIM in rules (persisted on the mission; shown in plan and status; given to every worker as context).

4. Translate rules into config overrides with this map:

   • "max N concurrent agents/workers/subagents" -> {"execution": {"max_concurrent_workers": N}}

   • "one worker at a time" / "sequential" -> {"execution": {"max_concurrent_workers": 1}}

   • "same for validators" -> {"validator": {"provider": ..., "model": ...}}

   • "use / for planning" -> {"planner": {"provider": ..., "model": ...}}

   • "no git / no worktrees" -> {"git": {"enabled": false, "use_worktrees": false}}

   • "skip user-facing testing" -> {"validation": {"user_testing": false}}

   • "no scrutiny validation" -> {"validation": {"scrutiny": false}} Note: workers are always isolated goose run leaf processes (never nested delegation); max_concurrent_workers caps how many run simultaneously.

Returns the mission id, a readiness report and next steps. Next: mission_plan, present the plan, get approval, mission_approve, mission_run.

Generate the structured dependency-aware plan and present it for approval. No implementation happens until mission_approve is called.

If the planner returns an empty plan (goal too vague), retry mission_plan - or pass your OWN decomposition (JSON string or list): features='[{"id":"F001","title":"...","description":"...","milestone":"MS01", "dependencies":[],"acceptance_criteria":["..."],"expected_paths":["..."]}]' milestones='[{"id":"MS01","objective":"...","completion_criteria":["..."]}]'.

Approve the plan and begin dependency-aware execution. Safe to call only once, from AWAITING_APPROVAL.

Advance the mission control loop (schedule, dispatch isolated workers, validate, correct). Resumable - call again to continue an in-progress mission. max_steps counts DISPATCHES; auto-retries inside a dispatch consume the feature's attempt budget, not a step. If your client sandbox times this call out, the loop keeps running server-side: poll mission_events instead of re-issuing. The response ends with a RUN REPORT (dispatches done, queued work) plus a STATE proof line.

Pause an active mission. No new workers are launched while paused.

Resume a paused/blocked mission, reconciling repository and worker state.

Steer a running mission without rebuilding the plan. Optionally reprioritize a specific feature by id and priority.

Replan the remaining work around a new constraint. Preserves valid completed work, marks invalidated work superseded, and bumps the plan revision.

Cancel a mission and clean up its worktrees.

Manually retry a failed/blocked feature. The retry counts toward the feature's attempt budget (attempts + manual_retries >= max_attempts stops further automated retries).

Record work on a feature that was implemented OUTSIDE the worker pipeline (by you, the lead agent, or a human). Use this instead of editing mission state files by hand. Verifies the commit exists, runs the feature's validation_commands, runs a real scrutiny validation on the diff, appends proper events, and continues the normal milestone flow.

Args: summary: what was implemented and why it meets the acceptance criteria. commit: the git hash of the implementation (required for git missions). changed_files: JSON list of paths (auto-derived from the commit if omitted). tests: JSON list of verification commands you ran and their outcome.

NOTE (H1): this runs a REAL scrutiny validation and can take minutes. If your client sandbox times the call out, the completion still proceeds server-side - verify via mission_events / mission_status instead of re-calling blindly.

Run a validator now (scrutiny | user_testing | final). Returns a structured verdict.

H10: apply the config deltas recorded at mission create when the model preflight flagged the worker model (e.g. worker_timeout>=900 for SMALL-OUTPUT-BUDGET models). One call; the applied values are echoed.

H11 housekeeping: list terminal and long-stale missions that clutter mission_list. With archive=true, non-terminal stale missions older than max_age_days are cancelled (their data and event history are kept). Terminal missions are never re-touched.

Mission control status for a mission.

The current plan for a mission.

Readiness/preflight report for a mission.

List all missions in the repository.

Recent mission events (append-only event log).