Review an agent's change

Use this procedure when an agent has changed a library or application and you need to decide whether the result meets the task.

Keep the review anchored to the intended behaviour. An implementation and its tests can agree while both misunderstand the requirement.

1. Restate the acceptance criteria

Write the expected result in domain terms before interpreting the patch. For a reservation operation, include successful reservation, insufficient stock, invalid quantity and repeated request behaviour.

Ask the agent to connect each criterion to an operation or test. Missing coverage is useful information; do not convert an untested criterion into a claim of success.

2. Find the changed responsibility

Identify the owning actor or library. Read its inputs and outcomes, then inspect the checked definitions and dependents. For a graph application at ./app:

effectful code find ./app --query reserve --format json

Use the returned definition and snapshot identities with the context commands in the evidence tutorial. Search hits are candidates for review; checked dependency relationships give the stronger structural context.

3. Compare the boundaries

Review more than the function body:

• Did state ownership or a message shape change?
• Did the set of effects or target actors change?
• Does the new behaviour require broader authority?
• Can existing saved state still be interpreted under the change?
• Did a native dependency or external delivery contract change?

A new declared operation should not silently imply a new grant. An actor’s response should not become general authority to call the requester.

4. Read outcomes and applicability separately

For a graph-test receipt, inspect the current comparison:

effectful code evidence ./app --receipt ./run-001.json --format json

Use your actual application and receipt paths. The query executes no tests. Read outcome, origin and applicability together. A stale pass does not validate the current inputs; an applicable failure is still a failure. Missing and unknown cases need attention.

Ask for fresh execution with a new receipt where evidence is insufficient. A reused result should remain identified as reuse.

5. Validate the changed external behaviour

If the patch changes an HTTP adapter, database connection, native integration or deployment setting, run the corresponding integration check. Scripted graph evidence does not establish those behaviours.

For durable-state changes, review the migration and rollback conditions. For an external effect, examine a refused request and an ambiguous outcome as well as success.

6. Record the decision

Keep the code and dependency identities, the accepted criteria, the evidence you used and any remaining limits with the review. Accept a bounded claim: which behaviour was checked, on which code, under which conditions.

This gives the next person a useful basis for continued work instead of an unexplained “green” result.