A screen loading is not a finished feature
An AI may say 'implemented' without running the tests or checking more than the happy path. Features that change state, such as sign-in, saving, and payments, often behave differently after a refresh or an error.
For a large diff, start with user behavior instead of reading every line in isolation. Write down what was supposed to change, then inspect anything outside that scope first.
Check in this order
Not every item applies to every edit. A copy change calls for language and narrow-screen checks more than data tests. Match the review to the risk of the change.
- Requirement: Does the original request and definition of done still hold?
- Scope: Are there unexpected file, dependency, or configuration changes?
- Behavior: Does the core path work in a real browser or device?
- State: Does data survive a refresh and return visit?
- Errors: Are invalid input and network failure understandable?
- Access: Is another account's data protected and are server secrets hidden?
- Verification: Which tests actually ran, and which were not run?
Attach the decision to the version
Wellnote lets you record review status and notes for each artifact version. Keeping the accepted version and its open questions makes later decisions easier to understand. A new version needs a new review.