two-axis-reviewlisted

A change can be beautifully built and still be the wrong thing; it can be exactly what was asked and still be built badly. One review that mixes both questions lets each failure hide behind the other's pass. Keep the axes separate. ## Axis 1 — Craft Does the change meet this project's own standards? Documented conventions first; beyond them, watch for the classics: duplicated logic, names that don't say what they mean, one edit scattered across a dozen files, abstractions nobody needed. (The canon here is Martin Fowler's catalog of code smells — flag by name, as judgment calls, never as autopilot rules.) ## Axis 2 — Faithfulness Put the original request next to the diff and check three things: - **Missing** — asked for, not there (or half there). - **Uninvited** — there, but nobody asked (scope creep hiding as initiative). - **Warped** — looks implemented, but numbers/edge behavior/wording differ from what was specified. Check the exact values: limits, thresholds, orderings, legal wording. ## The reviewer is never the author Two passes from one model are one pass with extra steps. It reviews toward the assumptions it wrote with. - **A different model, not just a different chat.** Reviewers on both axes come from another model family or another tier than the author. A fresh context on the same model clears the memory, not the blind spot — what it failed to imagine while building is what it fails to look for while judging. - **The reviewer gets the ask, the diff, and the