autopilot

Autopilot

$deep-interview -> $ralplan -> $ultragoal

The chain is not a list of optional hints and Autopilot is not an alias for direct execution. Autopilot supervises each child stage in one recoverable session, carries durable artifacts forward, and continues through implementation verification until the requested outcome is complete or a genuine blocker is recorded.

<Use_When>

• The user explicitly invokes $autopilot.
• The user asks for end-to-end autonomous delivery from an idea, issue, or requirements seed.
• The work needs requirements clarification, consensus planning, durable execution, and evidence-backed completion as one supervised workflow. </Use_When>

<Default_Chain> Run or resume these stages in order:

1. deep-interview — clarify intent, scope, non-goals, constraints, acceptance criteria, and unresolved decisions. Produce a durable requirements/specification handoff. Deep Interview is a real stage; do not replace it with a one-question check or skip it merely because the task looks actionable.
2. ralplan — turn the clarified requirements into an execution-ready consensus plan with architecture, sequencing, test, and verification guidance. Preserve review evidence as lifecycle evidence, not host-issued security authority.
3. ultragoal — execute the approved plan through durable goals and ledger receipts, implementation, focused verification, cleanup, review, and terminal evidence.

$team, $code-review, and $ultraqa may be used inside the supervised execution when the active Ultragoal plan or verification boundary requires them. They do not replace or weaken the defining three-stage chain.

When review or QA proves the requirements or plan wrong, keep Autopilot active, return its supervised phase to ralplan, attach the findings, and continue through ultragoal again. Implementation-only review fixes may remain within Ultragoal's blocker/review loop. </Default_Chain>

<Execution_Policy>

• Autopilot MUST begin at deep-interview for a new run and MUST preserve the phase order deep-interview -> ralplan -> ultragoal.
• Child stages are supervised phases, not peer workflow activations. Keep mode:"autopilot" active and update current_phase rather than replacing Autopilot with standalone child state.
• Use the current CLI state SSOT (omx state ... --json) and the current session-scoped state root. Do not create a second writer or revive legacy root-state authority.
• Local artifacts, prompts, trackers, transcripts, environment values, and role labels are lifecycle evidence only. Do not reintroduce the retired unrecoverable host-receipt lock or terminalize the workflow because host provenance is unavailable.
• Authority-decreasing operations are always recoverable: $cancel, state clear, hook disable/uninstall recovery, and stale-state repair must remain available without completion receipts or child-stage approval.
• Continue automatically through safe, reversible stage transitions. Stop only for an explicit user cancellation, a human-only dependency, or a verified terminal result. </Execution_Policy>

<State_Management> Autopilot state is session-scoped and owned by the canonical state writer. A new run records at least:

{
  "mode": "autopilot",
  "active": true,
  "current_phase": "deep-interview",
  "iteration": 1,
  "phase_cycle": ["deep-interview", "ralplan", "ultragoal"],
  "handoff_artifacts": {
    "deep_interview": null,
    "ralplan": null,
    "ultragoal": null
  },
  "return_to_ralplan_reason": null
}

Start or update state only through the CLI-first state surface:

omx state write --input '{"mode":"autopilot","active":true,"current_phase":"deep-interview","state":{"phase_cycle":["deep-interview","ralplan","ultragoal"],"handoff_artifacts":{"deep_interview":null,"ralplan":null,"ultragoal":null},"return_to_ralplan_reason":null}}' --json