A review checklist you can actually run

Course 1 taught four questions to ask of a diff, and unit 2 handed you the short card so you had it while you were rebuilding. This unit turns those four into something you can run on a whole feature, on somebody else's work, and on your own code six weeks later.

Why a checklist rather than judgement

Because judgement is the first thing to go when you are tired, and because the bugs that survive review are never the ones you were looking for. A list you run every time catches the class of problem you were not thinking about today. This is not bureaucracy; it is the same reason a pilot with ten thousand hours still reads the card.

The four lenses

Every review is the same four questions, in this order, because the order is roughly worst-consequence-first.

1. Leaks. Can a secret escape? Can a caller reach something they should not? Does user input reach a request made with my key?

2. Cost. How many API calls does this make, and how does that number grow? What happens if it runs in a loop?

3. Lies. Is any number rendered in units it is not in? Can a value be missing and render as zero? Are two currencies added together?

4. Failure. What does a person see when this breaks? Is a partial result kept or thrown away?

The next three lessons work one lens each on real screener code. This one is about how to run them.

Review the diff, then review the whole

Two different passes, and skipping the second is how features rot.

The diff pass asks what changed and whether the change is right. It is fast, you do it every time, it is the loop from course 1.

The feature pass asks whether the thing as a whole now makes sense. Twenty small correct diffs can add up to a page with three different ways of showing an error, two formatting helpers that disagree, and a state variable nobody reads. No individual diff was wrong. Run this pass when a feature is finished, before you call it done.

Reviewing what an assistant wrote is not different, except in one way

The four lenses are the same. What differs is the failure distribution: an assistant is reliably good at the happy path and reliably weak on the boundary. It will write correct filter serialisation and forget that limit can be a string, produce a clean table and no empty state, handle the response and not the error envelope.

So weight your attention accordingly. Do not spend review time re-checking that the sort function sorts. Spend it on what happens when the list is empty, the field is missing, the response is an error, and the number is a fraction.

Say what is wrong, not what to type

A review comment that names the problem produces a better fix than one that dictates a solution, whether you are talking to a person or an assistant:

This forwards limit from the query string straight upstream, so anyone can ask for 500 rows against my key.

is better than "add Math.min". The first gets you a clamp and makes the next request handled correctly too. The second gets you exactly one Math.min.

Try it now

Write the four lenses into your repository as REVIEW.md, in your own words, with one screener-specific example under each. Then run it on the filter code you wrote in unit 2. You wrote that code and you will still find something, which is the entire argument for the checklist.