Skip to content
Orcho Docs

Correction follow-ups

A rejected final acceptance is a controlled state, not a dead end.

When a run has a real diff but final acceptance rejects delivery, Orcho keeps the held diff and points the operator toward a correction follow-up. The follow-up continues from the run plan and repairs the blocked delivery path.

Follow-up vs resume

Section titled “Follow-up vs resume”

A correction follow-up is not a checkpoint resume. Resume continues the same run from its last checkpoint; a follow-up starts a new child run with the rejected parent as context, carrying its plan, diff, findings, and lineage. Use a follow-up when the parent reached a terminal rejection and needs a new, explicit repair task — not when a paused run can simply continue.

In engine terms that is FOLLOWUP (new run directory, parent context recorded) versus CHECKPOINT (same run directory, checkpoint store rehydrated).

The full taxonomy and the orcho run --resume / --from-run-plan launch commands live in Recovery and resume. This page stays on what a correction specifically carries and how a client drives it.

MCP control flow

Section titled “MCP control flow”

MCP clients should use the typed run-control surface instead of guessing from terminal text:

orcho_run_status("<run_id>")
orcho_run_diagnose("<run_id>")
orcho_delivery_gate("<run_id>")

If the gate says a delivery or correction decision is required, choose one ready orcho_delivery_decide call from the gate. If the safe next action is a follow-up, the projection should point at orcho_run_start with from_run_plan. If the safe next action is checkpoint continuation, it should point at orcho_run_resume.

What a correction needs

Section titled “What a correction needs”

A correction follow-up should carry:

  • the parent run id;
  • the held diff.patch;
  • the final acceptance blocker;
  • relevant findings and receipts;
  • a concrete task that tells the worker what to fix.

What success looks like

Section titled “What success looks like”

When the correction child delivers, the parent should no longer look like an open rejected candidate. The run history should make the relationship clear:

parent run: rejected → correction requested → superseded by follow-up
child run: correction follow-up → approved/delivered

This keeps recovery visible without leaving stale blockers as active truth.

Section titled “Related”