Review by risk and behaviour

Begin with the task and acceptance criteria, then follow the requested behaviour into the code. A diff read in isolation cannot show whether the change implements the approved requirement.

Start with the highest-consequence path. For an authorisation change, inspect identity and scope checks before interface text. For a migration, inspect reversibility, locks and data preservation before generated model updates. For an external action, inspect idempotency and uncertain outcomes before the success response.

Read tests as production code. Confirm that they fail for the original defect or protect the requested behaviour. Look for assertions that merely repeat the implementation's new output. Check nearby opposite cases: unauthorised users, rejected inputs, duplicate events, empty state, stale versions and boundary values.

Use a review sequence that reduces wasted attention:

1. Confirm that the task is still required and the scope matches it.
2. Check automated results from a clean environment.
3. Inspect the highest-risk behaviour and its tests.
4. Review the design and integration with neighbouring code.
5. Inspect mechanical and generated changes.
6. Run the manual or deployed-environment checks named in the task.
7. Decide, request a bounded revision, or close the change.

Avoid drip-feeding minor comments while a major design problem remains. State the blocking issue first and explain the acceptance evidence needed. Agents can respond to many comments quickly, which makes it easy to generate revision churn without settling the underlying decision.

For unfamiliar code, involve an owner who understands the operating context. Automated analysis can identify patterns and inconsistencies, but it may not know why an awkward constraint exists. When that knowledge is absent from the repository, capture it during review so the next task has a better starting point.