code-reviewlisted

# Code review — reading depth > This is HOW a diff is read. WHAT the verdict looks like belongs to > `tyran:reviewer` — binary APPROVE or CHANGES-REQUESTED, numbered executable > counterexamples, a re-review that first checks the previous round's findings > are pinned as tests, and a section naming what was not checked. Do not > restate any of that here; two definitions of "reviewed" drift apart, and the > drift only shows up when they disagree in front of someone. ## Read the diff twice, for different things **First pass — does it do what the story says?** Against the acceptance criteria, not against your idea of the feature. A correct implementation of the wrong thing is the most expensive defect on this list, and it is the one a dimension sweep never catches. **Second pass — the sweep below.** Every dimension gets looked at explicitly. Skipping one is a decision that belongs in the "did not check" section, not a gap nobody notices. ## The dimensions - **Correctness at the edges.** Empty, one, many. Zero, negative, overflow. The first and last iteration. Null versus absent versus empty-string — three different states that most code conflates and most tests exercise as one. - **Boundaries and shared zones.** Does the change reach outside its story's scope? An API shape, a schema, a shared file, a generated artefact, a published type. Those are the conductor's to authorise, and a review that waves one through has spent authority it does not have. - **Concurren