Review the whole loop.
The requirement, the patch, and the check should tell the same story.
A sequence of individually reasonable edits can end somewhere the task never asked to go. Review the complete result after the cycle, especially when the assistant revised its approach. Compare the current patch with the original finish condition.
Trace the requirement.
For each promised behavior, identify the changed code and the evidence that exercises it. A passing command with no relevant assertion leaves a gap. A changed file with no connection to the task deserves an explanation.
- Requirement
- Reject a blank display name.
- Implementation
- Validation in the existing save path.
- Evidence
- Blank rejected; valid name still saves.
Find the leftovers.
Look for temporary logging, abandoned helpers, generated output, and commentary that describes an earlier version. Remove only the leftovers introduced by this work. Check whether later edits invalidated a result recorded earlier in the session.
Make the result reviewable.
Write a short explanation of the behavior changed, why the change belongs here, and what verification established. Include limitations without turning guesses into findings. If the result is not ready, state the concrete unresolved condition and the next action.
Changed: blank-name validation in the save flow.
Verified: invalid and valid inputs through existing tests.
Unverified: behavior against the remote service.
Next decision: whether integration verification is needed.Before moving on