Run lifecycle

Orcho treats agent work as a lifecycle.

The lifecycle can be lighter or heavier depending on the selected work kind, but the core idea stays the same: each phase has a job, writes artifacts, and hands a typed result to the next phase.

Before the first phase

Orcho can stop before plan if the checkout already contains uncommitted changes. That is not a failure. It is intake.

Pre-run intake — uncommitted changes in checkout

What do you want to do?

1) include   Seed the isolated run with the current diff.
2) exclude   Start from HEAD; leave checkout changes untouched.
3) commit    Commit the current checkout first.
4) halt      Stop before the run starts.

This is where Orcho differs from simply asking a worker agent to continue in the current directory. The operator chooses whether existing work belongs to the new delivery run. Orcho should not blur previous edits, new task context, and future evidence into one unreadable pile.

The same principle appears again at the end of the run. If the target checkout changes while an isolated run is working, delivery pauses before applying the retained diff. Read Delivery control for the final apply, approve, retry, skip, and halt paths.

Common phases

Phase	Purpose
plan	Turn the task into an implementation contract.
implement	Apply the change in the project worktree.
review_changes	Inspect the diff for bugs, risks, and contract drift.
repair_changes	Fix accepted review findings.
final_acceptance	Decide whether the run is ready to deliver.
commit_delivery	Apply or park the delivery decision.

Delivery control

The lifecycle does not end when the worker produces a patch. It ends when Orcho decides what should happen to that patch:

• apply it to the project checkout;
• commit it as an accepted delivery;
• keep it in the retained run and start a correction follow-up;
• skip delivery while preserving artifacts;
• halt the run because the delivery gate is blocked.

That final phase is where Orcho keeps the delivery record honest. A rejected final acceptance can still be overridden by an operator, but the run keeps the gate result. A dirty target checkout can pause delivery until the operator cleans it and retries.

For concrete CLI examples, read Delivery control.

Why lifecycle matters

Without lifecycle, the only signal is whatever the worker agent said last.

With lifecycle, Orcho can distinguish:

• work that was attempted;
• work that changed files;
• work that passed review;
• work that has required verification receipts;
• work that is blocked by final acceptance;
• work that needs operator input.

That distinction is the product.

When operator input is required, read it as a handoff, not as a crash. The run has reached a typed decision point with allowed actions, findings, and a resume path. Handoffs and advisors explains those decision points.

Lighter and deeper runs

Orcho supports different workflow depths. A quick task should not pay for an enterprise-shaped process. A risky change should not be treated like a quick text edit.

The public docs use this mental model:

small task → fewer gates
feature → full lifecycle
complex feature → deeper review, repair, and acceptance

The exact profile names are reference material; the operating model is the thing to understand first.

For a layered view of a deeper feature-shaped run, read Run anatomy.