Your first run

A first Orcho run should be a mono-run: one project, one task, one delivery surface. This keeps the first proof understandable.

The profile for this run is the semantic wrapper around the lifecycle. It says how much planning, review, repair, final acceptance, and evidence this first task should require.

What Orcho does

For a normal feature-style run, Orcho moves through a lifecycle like this:

task
  ↓
plan
  ↓
implement
  ↓
review
  ↓
repair, if needed
  ↓
final acceptance
  ↓
delivery decision

Each phase writes durable artifacts under the run directory. The terminal output is the strongest way to understand the run as it happens; the run directory is the durable source of truth afterwards.

What to choose for the task

Pick something small but real:

• a validation rule;
• a missing error branch;
• a focused test addition;
• a small documentation correction with verification.

Avoid the first-run trap: do not start with a broad refactor or multi-repo feature. You want the lifecycle to be obvious before you add topology.

What “done” means

An Orcho run is not done because a worker produced text. It is done only after the lifecycle reaches a terminal state and the final surfaces agree on what happened.

The important questions are:

• Did the plan match the requested task?
• Did the implementation touch the expected files?
• Did review find blockers?
• Were required checks run?
• Did final acceptance approve or reject?
• Is there a correction or delivery decision pending?

Those answers live in status and evidence.