Review brief

The reader will not read the diff. They will skim for 30 seconds, then read only the code that could hurt them. Optimize for that.

Process

1. Get the diff (git log --oneline main..HEAD, git diff --stat main..HEAD) and read every non-trivial changed file in full.
2. Find the invariant core: what was broken, what is true now. One sentence.
3. Classify every hunk. Anything matching the crucial criteria below goes into the code section verbatim. Everything else gets one table row or is folded.
4. Write the brief in the layout below. Every line number cited must be verified against the working tree.
5. Run a second agent as a reviewer of the CODE, not the prose: "what is wrong, overstated, or missing?" Fix real bugs before delivering, and say you did.

Crucial code criteria

A hunk is crucial and must be shown as code if it touches any of:

• Schema. Drizzle tables, columns, indexes, migrations, Zod schemas at a trust boundary, MCP tool input or output schemas.
• Database writes. New or changed INSERT/UPDATE/DELETE, conditional WHERE clauses, anything that runs inside a workflow step or a cron.
• Security. Auth checks, scope or org or project gating, secrets, external calls with credentials, anything that fails open.
• Core logic. The branch or expression that decides the outcome the bug was about: a status assignment, a validation gate, a ranking comparator, a retry or timeout policy.
• Jank. Anything you would be embarrassed to defend in review. String-matching a vendor error message to pick UI copy. A regex standing in for a parser. A hard-coded lookup table. A console.warn where a metric belongs. A swallowed catch. A magic timeout. A DB read added to work around a missing parameter. A fallback that quietly changes behaviour. Show it, name it as jank in the sentence above, and say whether it is acceptable for now or should block.