Watch the run

The live CLI stream is the strongest first way to see an Orcho run. This page is about that one surface: what the terminal shows while the run is still alive, and how to read its phase anatomy instead of treating it as a chat scroll. The other two surfaces — live via MCP, and the recorded result after the run — are linked above and kept separate on purpose.

What the live stream is made of

A live run is not a wall of agent prose. It streams in a fixed anatomy: an opening envelope, the pipeline map, one block per phase, and a closing rollup. Learn those four parts and the stream becomes readable.

1. The opening envelope

Before any code is touched, the run prints its operating envelope. Read this first — it is the whole shape of the run in one screen.

real feature runopening envelope

Orcho Run  20260628_000813  feature
Project  /repo/orcho-core
Task     ADR 0117 — Separate verification cost from blocking tier
Plugin   orcho-core
Skills   14: orcho-core-cli-ux, orcho-core-quality-gates, ...

Verification
mode      pro
envs      core-local
policy    declared in contract (require, suggest, warn)
effect    require receipts; missing/failed resolved at gate time
gates     gate               timing           run     policy   kind
          env-provenance     after_implement  auto    warn     cheap
          run-state-unit     after_implement  auto    require  unknown
          broad-non-e2e      after_implement  auto    require  unknown
          e2e                operator         manual  suggest  unknown

Agents
PLAN              Claude  high
IMPLEMENT         Claude  high
REVIEW_CHANGES    Codex   medium
REPAIR_CHANGES    Claude  medium
FINAL_ACCEPTANCE  Codex   low

State
session  auto  rounds=1  plan=yes
output   /repo/workspace/runspace/runs/20260628_000813/output.log
events   /repo/workspace/runspace/runs/20260628_000813/events.jsonl

Read it as the plan of record: Profile, verification policy, required gates, agent split, and artifact paths are all declared before implementation starts.
Why it beats a transcript: You see which gates are required and where evidence will land without reconstructing it from chat history.

2. The pipeline map

Right after the envelope, the run prints its pipeline. This one line is the map of every phase you are about to watch stream by.

the map of the runpipeline DSL

Pipeline
⟳² (▶ plan [Claude] → · validate_plan [Codex]) → · implement [Claude]
  → ⟳² (· review_changes [Codex] → · repair_changes [Claude])
  → · final_acceptance [Codex]

Planning and validation can loop, implementation is a separate delivery phase, review and repair can loop, and final acceptance is its own gate.

⟳² bounded loop▶ active phase· phase in chain[Claude] worker runtime[Codex] review runtime

3. Each phase as it streams

The body of the run is one block per phase, in pipeline order. Every block has the same anatomy, so you always know where you are:

a phase banner — which phase is active and which runtime is speaking;
the phase body — what that phase did (edits, plan, findings);
for a gate phase, a verdict — approved or rejected, plus the blocker and the required fix when it rejects.

sanitized feature runphases in order

[PLAN] Claude
proposed contract: owned files api/auth.py, tests/test_auth.py
✓ plan accepted

[VALIDATE_PLAN] Codex
verdict  APPROVED

[IMPLEMENT] Claude
edited api/auth.py and tests/test_auth.py

[REVIEW_CHANGES] Codex
verdict   REJECTED
blocker   missing negative-path test
fix       add regression coverage for invalid input

[REPAIR_CHANGES] Claude
added the missing negative-path test

[FINAL_ACCEPTANCE] Codex
verdict     APPROVED
ship_ready  yes

The banner tells you altitude: [REVIEW_CHANGES] Codex means the review gate is running on the review runtime — not the worker still editing.
A rejection is a state, not an error: REJECTED names a concrete blocker and routes into REPAIR_CHANGES. A ⟳² loop means review and repair can repeat before the run moves on.

The deep, section-by-section read of a finished run lives in Feature run anatomy. This page is the lighter, live version of the same structure.

4. The closing rollup

When the run ends, the stream closes with a rollup: the final verdict, usage and cost, and the artifact paths. That rollup is the handoff from watching to inspecting — the same paths you re-open in Read the result.

Run it with live output

orcho run \
  --project ~/www/my-workspace/my-project \
  --task "Add input validation to the login endpoint." \
  --output live

--output live is the best mode for learning Orcho, because it shows the run as a sequence of phase decisions rather than only a final state. Pick the verbosity to match how much you already trust the workflow:

summaryCompact phase progress and outcome. Good once the run shape is familiar.

livePhase blocks plus the live agent transcript. Best first UX for reading the anatomy above.

debugLive output plus deeper traces. Use when diagnosing runtime or prompt behavior.

Observe through MCP — watch a live run from an AI client instead of the terminal.
Read the result — inspect the recorded run after it finishes.
Feature run anatomy — the deep, section-by-section read.
CLI reference — the full command surface.