taste-code-review

"It works" is the floor. Review in passes, not vibes — an agent that reviews without a method reviews without a memory.

1. THE PASS ORDER (Fix In This Order, Never Reversed)

1. Behavior — does it do the thing, including edge cases (empty states, error paths, repeated clicks, offline)? A feature that works for the happy path only is a bug wearing a feature.
2. Structure — is the code where it belongs? (File/component boundaries, one responsibility per unit, no 400-line function, imports clean, no dead code.)
3. Taste — naming, duplication, consistency with the codebase's conventions. Code that reads like poetry nobody asked for is worse than code that reads like a bus schedule — but a bus schedule with descriptive stops is best.
4. Security — injection (HTML/URL/SQL), secrets in code or logs, authz on every mutation, untrusted input boundaries.
5. Performance — obvious algorithmic waste, N+1 queries, work repeated per render, giant payloads in the critical path.
6. Accessibility — keyboard path, focus states, contrast, semantics, screen-reader names (the taste-accessibility checklist applies to code too).

Passes are ordered because a structural fix invalidates a line-level review — review the shape before the details.

2. FINDINGS (Severity-Ranked, Written To Be Acted On)