# 5 · Report: check your review, then give one clear summary Your review is a piece of work too, and it gets read by someone with little time. Before you send it, check it the way you checked the code. Then give the person one summary that tells them, in the first line, whether this can merge. On a small change: skip the lenses. Write the summary (F1, F2) in three or four lines. --- ## Step 1 · Four lenses on your review Go through each lens. Each takes a minute. Fix your review before you send it, not after. > **In ihumane Pro** (https://ihumane.ai/#pricing): > - Lens 1 · The author > - Lens 2 · The user > - Lens 3 · The next developer > - Lens 4 · The evidence ## Step 2 · Report > **In ihumane Pro** (https://ihumane.ai/#pricing): > - F1 · Open with a verdict the person can act on ### F2 · Say what you covered, what you ran, and what you didn't **Rule:** After the verdict, say what kind of review this was (I2), which files or parts you reviewed closely, which you skimmed and which you didn't look at, the commands you ran and what they showed, and anything you couldn't check (no environment, no access to the other service, couldn't reproduce the bug). Mention any project rule you followed over this module (Precedence). See `working-with-humans` R4. **Why:** The person merging decides what still needs checking from what you say you checked. "Approve" from someone who read every file and ran the tests means something different from "approve" on the API part only. If your summary doesn't say which, they'll assume the first. **Agent trap:** an approval after reading the diff without running anything, with no line saying so. Or reviewing six of twenty files (D6) and writing a summary that sounds like it covered all twenty. **Check:** your summary has a "Ran" line and a "Not covered" line. If "Not covered" says "nothing", is that true? > **In ihumane Pro** (https://ihumane.ai/#pricing): > - F3 · Show the person before you post ## The summary Your summary follows this shape. Leave out a section only if it's empty, and say "nothing" in "Not covered" only when it's true. ``` Request changes: 1 blocking, 2 should fix, 3 nits. The main issue: clearing the status filter sends `undefined` to deleteMany, which deletes every order (lib/orders.ts line 41). Reviewed: full review. Read all 9 files; closely: lib/orders.ts, api/orders.ts and the migration. Ran: npm test (passes, 112 tests), npm run build (passes). Reproduced issue #412 on main and confirmed it's fixed on this branch. Not covered: didn't run the migration against a copy of real data; didn't check the mobile app, which also calls GET /orders. Good: the test for part-refunded orders covers the case that broke in March. ``` **Agent trap:** a summary that lists every comment again in full, so the one blocking issue is lost in a wall of text. The comments are on the lines; the summary says what matters and what you checked.