CI autopilot

--no-interactive is the unattended run shape.

It is useful when a project already has a trusted profile, stable verification gates, authenticated worker runtimes, and a delivery policy that should run without a human watching the terminal.

tuned project + explicit profile + --no-interactive
  -> no stdin prompts
  -> configured defaults and policies decide routine paths
  -> eligible handoff retry may use CI advice once
  -> unsafe or ambiguous paths stop with a typed reason

Do not read this as blind automation. Read it as bounded autonomy under a declared policy.

First useful command

Use a concrete profile in CI:

orcho run \
  --project ~/www/my-workspace/my-project \
  --task-file .orcho/tasks/add-login-validation.md \
  --profile feature \
  --mode pro \
  --no-interactive \
  --output summary

For cross-project CI, make the participant set explicit:

orcho cross \
  --projects api:/repo/api web:/repo/web \
  --task-file .orcho/tasks/align-user-contract.md \
  --profile feature \
  --no-interactive \
  --output summary

On a fresh run, a non-interactive context should not rely on a terminal picker. Pass --profile explicitly. Use --profile auto-detect only when the auto-detect threshold and fallback behavior are already part of the project policy.

What the flag changes

--no-interactive removes stdin prompts from the run lifecycle.

Surface	Interactive run	Non-interactive run
Profile selection	Can show a work-kind picker.	Requires an explicit profile unless advisor policy is used.
Pre-run dirty checkout	Can ask include, exclude, commit, or halt.	Uses `pre_run_dirty.non_interactive_default`.
Phase handoff	Can show a handoff menu.	Persists the handoff or uses eligible CI advice under policy.
Delivery decision	Can ask apply, approve, fix, skip, or halt.	Uses delivery config or parks/blocks when policy says so.
Required verification	Human can react at the prompt.	Missing or failed required receipts block delivery.

The important point is that --no-interactive does not erase decisions. It moves them into declared policy and durable run state.

CI advice on handoffs

When a run pauses on a rejected or incomplete phase handoff, CI cannot ask the operator what to do. Orcho can run a prompt-free advice sub-flow for eligible cases:

phase rejected
  -> build handoff context
  -> ask advisor for the smallest honest retry feedback
  -> evaluate safety gates
  -> write ci_agent provenance
  -> retry through the normal handoff resume path

The current safe default is one CI advisor retry. It is intentionally narrow.

The retry can proceed only when the recommendation is retry_feedback, the confidence is not low, budget remains, the expected files stay in scope, the finding is not repeating, and no destructive marker is detected.

What CI cannot decide

CI autopilot should stop rather than hide risk.

Stop reason	Why it stops
waiver	CI must not accept known risk on behalf of the operator.
destructive action	The recommendation mentions destructive work such as hard resets or data deletion.
out of scope	The expected files do not fit the plan’s owned files or allowed modifications.
low confidence	The advisor itself is not confident enough.
repeated blocker	The same blocking finding repeats instead of improving.
budget exhausted	The bounded retry budget is spent.
release rejected	Final acceptance did not approve the delivery.
required receipts missing	Verification policy says the evidence is not strong enough.

Those stops are not failures of the concept. They are the boundary that makes unattended execution usable.

Project maturity checklist

Use CI autopilot after the project has these pieces:

Requirement	Why it matters
Explicit profile	CI should know the work shape before the run starts.
Authenticated runtimes	Worker CLI commands must run without interactive login.
Project tuning	Orcho needs project facts, paths, and verification expectations.
Required tests	Final acceptance needs receipts it can trust.
Dirty-checkout policy	CI needs a deterministic answer before worktree creation.
Delivery policy	CI needs to know whether to apply, approve, defer, skip, or block.
Accounting enabled when useful	Unwatched runs still need cost and usage visibility.

For early experimentation, run the same task interactively first. CI autopilot is strongest after the project has already taught Orcho how work should be judged.

Config surfaces

The mode is controlled by more than the CLI flag.

{
  "pre_run_dirty": {
    "non_interactive_default": "halt"
  },
  "commit": {
    "auto_in_ci": "approve"
  },
  "accounting": {
    "enabled": true
  }
}

Treat those as policy, not convenience toggles. A CI job that starts from a dirty checkout, accepts a weak release, or applies a diff without receipts is not autonomous; it is under-specified.

CI vs MCP captain

CI autopilot and MCP captain mode solve different control problems.

Mode	Best for
CLI with `--no-interactive`	Repeatable unattended runs in tuned projects.
MCP captain mode	A client actively observes, diagnoses, and asks the operator for decisions.

Both rely on the same principle: Orcho owns lifecycle state, decisions, and evidence. The difference is whether a human-facing client is present during the run.