False-Ready Agent Delivery

Trust boundary

False-ready delivery is the state where a worker appears finished, but the delivery system cannot prove the result is ready. Orcho exists to keep that state visible instead of letting it become a confident final message.

worker says donereview gaterepairfinal gateevidence

Read run gatesCorrection follow-ups

agent done is not enoughgate decides readinessevidence survives

golden journeyreject -> repair -> receipt

Three commands reach the first result. The deterministic mock run uses the real CLI and lifecycle; only paths, IDs, and idle time are normalized for the recording.

01Worker claimThe implementation can look complete before readiness is proven.02Review gateA gate can reject with a concrete blocker and required fix.03RepairThe run routes the rejected work into a correction phase.04EvidenceThe blocker, repair, receipts, and verdict remain inspectable.

Worker claim

A worker runtime can finish its implementation phase and still leave the delivery unready.

[IMPLEMENT] edited api/auth.py and tests

That line is useful, but it is not a release decision. It says work happened. It does not prove that review passed, required checks ran, or final acceptance approved the result.

Review gate

The review gate is where false-ready delivery becomes visible.

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

A normal agent transcript can drift from implementation into a confident final message. Orcho keeps the gate separate. The run can say:

• the worker made a change;
• the change is not delivery-ready yet;
• this exact blocker must be fixed before the run can proceed.

Repair

Repair is not a new vague prompt. It is a continuation of the delivery contract.

[REPAIR_CHANGES] added missing negative-path test

The point is not that rejection is good. The point is that rejection becomes a controlled state with a next action instead of hidden operator anxiety.

When the correction needs a new run, use Correction follow-ups to carry the parent context, blocker, diff, and evidence forward.

Final gate

Final acceptance is the last readiness decision.

[FINAL_ACCEPTANCE] verdict=APPROVED
  ship_ready  yes

If final acceptance rejects, the run should not look ready. It should preserve the blocker and tell the operator whether to repair, follow up, resume, or halt.

Read Run anatomy for where review and final acceptance appear in the live stream.

When code review passes but delivery is still blocked

The strongest version of false-ready is not “the agent looked done.” It is “review approved the code, and delivery was still blocked.” Review and final acceptance are separate gates for exactly this reason: a reviewer can be satisfied with the diff while required verification is missing or stale.

release gatecode ok, delivery blocked

Review
verdict  APPROVED
summary  no substantial defects found

Final acceptance
verdict     REJECTED
ship_ready  no
summary     required receipts are missing or stale

Correction gate
missing required receipts: mcp-mock-smoke
stale required receipts: env-provenance, lint

Contract status
task_contract  incomplete
tests          weak

A confident final message would have shipped this. Orcho holds it: the code was fine, but the proof that it works was not there.

Read Plan contract and DAG for the same gate inside a full run.

Evidence

For a rejected or blocked run, inspect:

1. final acceptance verdict;
2. release blockers;
3. verification receipts;
4. diff summary;
5. delivery gate state;
6. recommended correction or recovery action.

The durable proof surface lives in artifacts such as:

output.log
events.jsonl
plan.md
review.json
diff.patch
verification_command_receipts/

A receipt is what turns “tests passed” from a sentence into something inspectable. Each one records where and how a check actually ran, so final acceptance can tell apart passed, failed, ran in the wrong place, and never ran:

[
  {
    "name": "lint",
    "status": "stale",
    "command": "ruff check api/",
    "working_dir": "/repo/app",
    "interpreter": "python3.12",
    "source": "api/auth.py",
    "result": "passed against an earlier diff; re-run required",
    "provenance": "ran before the last edit"
  },
  {
    "name": "mcp-mock-smoke",
    "status": "missing",
    "result": "required by the profile, but no receipt was produced"
  },
  {
    "name": "verification-unit",
    "status": "passed",
    "command": "pytest tests/test_auth.py",
    "working_dir": "/repo/app",
    "interpreter": "python3.12",
    "source": "tests/test_auth.py",
    "result": "ran in the expected checkout and passed"
  }
]

The canonical receipt shape and classification live in Verification receipts.

The values are sanitized, but the shape is the point: missing and stale receipts are why the run above blocked delivery even though the code review approved the diff.

Use Evidence bundle for the artifact model and Verification receipts when the key question is whether checks ran in the right environment.

Reuse the deterministic harness

The recording above is generated from a public, repeatable Orcho control:

orcho run \
  --task "Fix validation bug in sample API" \
  --project /tmp/orcho_demo_1a/project \
  --workspace /tmp/orcho_demo_1a/workspace-orchestrator \
  --profile feature \
  --mock \
  --mock-review-reject 1 \
  --max-rounds 2 \
  --output live

--mock-review-reject N makes the first N mock review calls reject before the next review can approve. This gives you the same lifecycle shape every time: implementation claims done, review names a blocker, repair runs, re-review approves, and final acceptance writes the closing record.

That makes the run useful beyond this page:

Use it for	Inspect
CLI or SDK regression	exit state, phase order, findings, final summary
release-candidate preflight	installed command, artifacts, evidence readers
observability debugging	events.jsonl, review JSON, evidence, terminal rendering
documentation and recordings	stable story without provider credentials or token cost

The boundary matters: this proves Orcho’s delivery protocol and public surfaces. It does not prove that a real model can solve the fixture. Run provider-backed and project-specific checks separately when model capability is part of the question.

What false-ready usually looks like

False-ready delivery can happen when:

• required tests were not run;
• review found a blocker;
• final acceptance rejected;
• verification ran against the wrong tree;
• the diff touched files outside the declared scope;
• a delivery decision is still parked.

The point is not to celebrate rejection. The point is to keep the operator from shipping a result that only looked complete in the worker’s last message.

Deep reference

The canonical engineering guide lives with the code:

• Deterministic mock harness

Related

• Run anatomy shows the deeper run stream.
• Evidence bundle explains durable artifacts.
• Verification receipts explains proof that checks ran.
• Correction follow-ups explains recovery after rejection.