Inspect a local run
Orchard's runtime is in-process and ephemeral: orchard run executes a workflow as promises inside its own process via createLocalRuntime(). There is no database and nothing persists once that process exits, so everything you can observe about a run comes from that single process's own output while it is alive.
Read run status from stderr
orchard run and orchard generate write status lines to stderr as the workflow progresses:
[orchard:workflow] started: workflow task_000001 started (backend: local)
[orchard:workflow] waiting: awaiting workflow task_000001
[orchard:workflow] step: analyze (task_000002) harness=cursor model=composer-2.5 42.3s attempts=1
[orchard:workflow] completed: workflow task_000001 finished with state completedA step: line is printed for every harnessCall as it finishes, so a long run is not silent between waiting and completed. attempts is the turn count including structured-output repair turns: attempts=1 means the harness returned valid JSON first try, and anything higher means the step paid for extra turns that its result does not reveal. A step that exhausted its repair turns is marked failed.
Pass --debug to also print per-run option context and internal runtime logger lines to stderr.
Read the final result
orchard run prints the workflow's final state and result snapshot to stdout on completion. There is no separate inspection command: the printed output — plus anything you captured from stderr — is the only record of the run once the process exits.
Watch pending approval gates
While a run is active on an interactive terminal, orchard run polls for pending approval gates and prompts for a decision inline; see Use approval gates. There is no way to inspect or resolve a gate from a second terminal or process — the gate exists only in the memory of the orchard run process that owns it, for as long as that process runs.
What is gone
Earlier revisions of Orchard ran on a Postgres-backed Absurd runtime and supported external inspection and control (absurdctl dump-task/list-tasks, habitat run, retries, cancels, and durable event delivery from a second process). None of that applies to the in-process runtime: there is no database to query, no separate worker process to inspect, and no way to act on a run except from inside the terminal that started it.