Claude Code review packets: unknown is not a pass

Consider a hypothetical Claude Code review packet. The repository tests pass. The diff stays inside the agreed files. An MCP write timed out, and the packet has no receipt from the service that owns the resource.

The summary says the run succeeded.

A reviewer scanning that summary could approve the next step without noticing that nobody has established whether the external write happened. Repository tests cannot answer that question. Retrying the write might create a second effect.

I want the missing receipt to stop the workflow, even when the rest of the packet looks reassuring. That requires a small gate outside the agent’s prose, backed by requirements the agent cannot edit.

Define the evidence before the run

For a workflow that changes a staging routing rule, write down what must be known before another automated mutation can proceed. This example requires validation tied to the intended revision, an authorisation record, a receipt for the external effect, and settlement of downstream work or cost commitments.

That last requirement is deliberately conservative. A different workflow might permit outstanding work under a bounded reservation. Its policy must say so before execution. An agent should not get to relax the requirement because a service is slow.

Keep the requirements in workflow-owned configuration. Let the agent supply references to evidence, rather than assertions that it has verified itself:

{
  "claimed_effect": "committed",
  "evidence": {
    "validation": "receipt:validation",
    "authorization": "receipt:authorization",
    "effect": "receipt:effect",
    "settlement": "receipt:settlement"
  }
}

These are illustrative local references, not native Claude Code configuration or standard MCP fields. In a deployed system, references would resolve through a restricted evidence service. The service would authenticate the issuer, check the record’s scope and freshness, and return only the information the reviewer is allowed to see. Raw tool output is not automatically trusted evidence.

The expected operation and target must also come from the workflow. If the packet chooses both the receipt and the identity it should match, it can substitute a perfectly good receipt from an unrelated run.

Keep evidence status separate from outcome

A receipt can be present and report failure. A missing receipt tells you less: the outcome may still be unknown.

Do not replace these fields with a single green status. Even a verified authorisation record only proves what was allowed at the recorded decision point. It does not renew expired permission for the next action.

Bind each record to the appropriate operation, environment and tenant. For this single-resource example, the expected revision is part of that binding too. More complex workflows need distinct bindings for each resource and validation step; forcing every receipt to share one revision would hide those differences.

The summary can be checked for contradiction, but it cannot overrule the service record. If the agent says “committed” and the authoritative receipt says “failed”, retain the disagreement and block. Do not ask the model to produce a more confident summary.

Try the executable evidence gate

Download the Python teaching fixture. It uses the standard library, makes no network calls, and performs no external writes. Save it locally and run:

python3 review-packet-evidence-gate.py

The fixture keeps a fixed requirement set outside the packet. It resolves each supplied reference against a simulated trusted registry, then checks the evidence kind, binding, verification status and acceptable outcome. It returns a list of blockers rather than an optimistic overall score.

Twelve local unit tests cover the complete packet and several ways a reassuring summary can conceal a problem:

• Remove the write receipt while keeping the success claim.
• Substitute a receipt from a different operation, tenant or revision.
• Return a verified receipt whose outcome is failure.
• Delete a requirement from the packet and try to supply a shorter requirement list.
• Leave downstream settlement pending or supply a self-written verified flag.
• Contradict the service outcome in the summary, or supply malformed evidence references.

The tests also check that the gate does not modify its input and that simulated authoritative reconciliation can resolve a missing receipt. The wrong-tenant and wrong-revision checks run as subcases within one test.

This is an executable design exercise, not a production authorisation library. The trusted registry is an in-memory dictionary. It does not verify signatures, enforce retention, provide durable audit storage, or exercise a real MCP server. Passing the tests establishes the behaviour of this fixture, not the safety of a distributed workflow.

An empty blocker list is not permission to write

The gate’s narrow result is evidence complete under this policy. It must not directly mint a new execution capability.

Before the next mutation, the execution service still needs to check current authority, resource state, and any remaining budget. Otherwise, a clean review packet can outlive the permission or revision it describes. A separate check followed much later by a write can also race with another operator; the mutation boundary must enforce the relevant preconditions.

Put this gate in the path that every automated continuation has to use. A CI report that the agent can bypass through a direct tool call is advisory. For an existing deployment, start by finding the actual write credential and the component that can refuse its use. That is where the policy needs enforcement.

Record the decision with the requirement-set version and the evidence references. A future reviewer needs the reason the workflow stopped. A red indicator alone leaves them hunting through logs.

Block the next write without blocking investigation

A missing receipt may mean the write committed and its response disappeared. Blocking further agent work cannot undo that effect.

Preserve a separately authorised investigation path. An operator or restricted reconciliation worker should query the owning service using the original operation identity where the service supports it. If the service cannot establish the outcome, keep it unknown and escalate. Waiting longer does not turn uncertainty into proof of failure.

Investigation also needs access limits. Do not give a reconciliation worker broad write authority merely because it is handling an exception. Replaying an incident should consume captured evidence rather than reissue the original mutation.

Recovery is a separate decision. A conditional rollback must protect changes made by another writer. Likewise, a missing financial receipt should not release budget that downstream work may still consume; one MCP call can create costs beyond the visible agent loop.

For your next review exercise, take a successful synthetic run and remove its external-effect receipt. Keep the green tests and the success summary. Check whether the actual continuation path refuses the next write, who receives the unresolved operation, and what evidence they need to settle it. If the only change is a warning in the summary, the enforcement work is still ahead of you.

For the wider permission and human-review model, read Claude Code: Building Production Agents That Actually Scale. See the book and Kindle edition.