code-review-and-quality

# Code Review and Quality ## Overview Multi-dimensional code review with quality gates. Every change gets reviewed before merge — no exceptions. Review covers five axes: correctness, readability, architecture, security, and performance. **The approval standard:** Approve a change when it definitely improves overall code health, even if it isn't perfect. Perfect code doesn't exist — the goal is continuous improvement. Don't block a change because it isn't exactly how you would have written it. If it improves the codebase and follows the project's conventions, approve it. ## When to Use - Before merging any PR or change - After completing a feature implementation - When another agent or model produced code you need to evaluate - When refactoring existing code - After any bug fix (review both the fix and the regression test) ## The Five-Axis Review Every review evaluates code across these dimensions: ### 1. Correctness Does the code do what it claims to do? - Does it match the spec or task requirements? - Are edge cases handled (null, empty, boundary values)? - Are error paths handled (not just the happy path)? - Does it pass all tests? Are the tests actually testing the right things? - Are there off-by-one errors, race conditions, or state inconsistencies? ### 2. Readability & Simplicity Can another engineer (or agent) understand this code without the author explaining it? - Are names descriptive and consistent with project conventions? (No `temp`, `data`, `result` without context) - Is the control flow straightforward (avoid nested ternaries, deep callbacks)? - Is the code organized logically (related code grouped, clear module boundaries)? - Are there any "clever" tricks that should be simplified? - **Could this be done in fewer lines?** (1000 lines where 100 suffice is a failure) - **Are abstractions earning their complexity?** (Don't generalize until the third use case) - Would comments help clarify non-obvious intent? (But don't comment obvious code.) - Are there dead code artifacts: no-op variables (`_unused`), backwards-compat shims, or `// removed` comments? ### 3. Architecture Does the change fit the system's design? - Does it follow existing patterns or introduce a new one? If new, is it justified? - Does it maintain clean module boundaries? - Is there code duplication that should be shared? - Are dependencies flowing in the right direction (no circular dependencies)? - Is the abstraction level appropriate (not over-engineered, not too coupled)? - **Utility reuse (ADR-011):** Does the change introduce any private helper that duplicates logic already in `page_template_utils.py`, `write_utils.py`, `contracts.py`, or `_optional_surface_common.py`? If yes, flag as a required fix before merge. Does it redefine a module-level constant (e.g. `TOPICAL_NAMESPACES`) without a `# keep in sync with` drift guard? If yes, flag as a required fix. ### 4. Security For detailed security guidance, see `security-and-hardening`. Does the change introduce vulnerabilities? - Is user input validated and sanitized? - Are secrets kept out of code, logs, and version control? - Is authentication/authorization checked where needed? - Are SQL queries parameterized (no string concatenation)? - Are outputs encoded to prevent XSS? - Are dependencies from trusted sources with no known vulnerabilities? - Is data from external sources (APIs, logs, user content, config files) treated as untrusted? - Are external data flows validated at system boundaries before use in logic or rendering? ### 5. Performance For detailed profiling and optimization, see `performance-optimization`. Does the change introduce performance problems? - Any N+1 query patterns? - Any unbounded loops or unconstrained data fetching? - Any synchronous operations that should be async? - Any unnecessary re-renders in UI components? - Any missing pagination on list endpoints? - Any large objects created in hot paths? ## Change Sizing Small, focused changes are easier to review, faster to merge, and safer to deploy. Target these sizes: ``` ~100 lines changed → Good. Reviewable in one sitting. ~300 lines changed → Acceptable if it's a single logical change. ~1000 lines changed → Too large. Split it. ``` **What counts as "one change":** A single self-contained modification that addresses one thing, includes related tests, and keeps the system functional after submission. One part of a feature — not the whole feature. **Splitting strategies when a change is too large:** | Strategy | How | When | |----------|-----|------| | **Stack** | Submit a small change, start the next one based on it | Sequential dependencies | | **By file group** | Separate changes for groups needing different reviewers | Cross-cutting concerns | | **Horizontal** | Create shared code/stubs first, then consumers | Layered architecture | | **Vertical** | Break into smaller full-stack slices of the feature | Feature work | **When large changes are acceptable:** Complete file deletions and automated refactoring where the reviewer only needs to verify intent, not every line. **Separate refactoring from feature work.** A change that refactors existing code and adds new behavior is two changes — submit them separately. Small cleanups (variable renaming) can be included at reviewer discretion. ## Change Descriptions Every change needs a description that stands alone in version control history. **First line:** Short, imperative, standalone. "Delete the FizzBuzz RPC" not "Deleting the FizzBuzz RPC." Must be informative enough that someone searching history can understand the change without reading the diff. **Body:** What is changing and why. Include context, decisions, and reasoning not visible in the code itself. Link to bug numbers, benchmark results, or design docs where relevant. Acknowledge approach shortcomings when they exist. **Anti-patterns:** "Fix bug," "Fix build," "Add patch," "Moving code from A to B," "Phase 1," "Add convenience functions." ## Review Process ### Step 1: Understand the Context Before looking at code: What is this change trying to accomplish? What spec or task does it implement? ### Step 2: Review the Tests First Do tests exist? Do they test behavior (not details)? Are edge cases covered? Would they catch a regression? ### Step 3: Review the Implementation Walk through each file with the five axes: correctness, readability, architecture, security, performance. ### Step 4: Categorize Findings Label every comment with severity: | Prefix | Meaning | Author Action | |--------|---------|---------------| | *(no prefix)* | Required change | Must address before merge | | **Critical:** | Blocks merge | Security, data loss, broken functionality | | **Nit:** | Minor, optional | Author may ignore | | **FYI** | Informational | No action needed | ### Step 5: Verify the Verification What tests ran? Did the build pass? Manual testing done? Screenshots for UI changes? ## Multi-Model Review Pattern Use different models for different review perspectives (Model A writes → Model B reviews → Model A fixes → human decides). Different models have different blind spots. ## Dead Code Hygiene After refactoring, check for orphaned code. Identify unreachable/unused elements, list them explicitly, and ask before deleting: "Safe to remove these: [list]?" Don't leave dead code around, but don't silently delete things you're unsure about. ## Review Speed Reviews block teams. Respond within one business day (ideally sooner). Prioritize fast individual responses over quick final approval. Ask authors to split large changes rather than reviewing massive diffs. ## Handling Disagreements When resolving review disputes, apply this hierarchy: 1. **Technical facts and data** override opinions and preferences 2. **Style guides** are the absolute authority on style matters 3. **Software design** must be evaluated on engineering principles, not personal preference 4. **Codebase consistency** is acceptable if it doesn't degrade overall health **Don't accept "I'll clean it up later."** Experience shows deferred cleanup rarely happens. Require cleanup before submission unless it's a genuine emergency. If surrounding issues can't be addressed in this change, require filing a bug with self-assignment. ## Honesty in Review - **Don't rubber-stamp.** "LGTM" without evidence helps no one. - **Don't soften real issues.** Quantify: "N+1 adds ~50ms/item" beats "could be slow." - **Push back directly** on flawed approaches. Sycophancy is a review failure mode. - **Accept override gracefully.** Defer to author judgment when they have full context. Critique code, not people. ## Dependency Discipline Part of code review is dependency review: **Before adding any dependency:** 1. Does the existing stack solve this? (Often it does.) 2. How large is the dependency? (Check bundle impact.) 3. Is it actively maintained? (Check last commit, open issues.) 4. Does it have known vulnerabilities? (`npm audit`) 5. What's the license? (Must be compatible with the project.) **Rule:** Prefer standard library and existing utilities over new dependencies. Every dependency is a liability. ## The Review Checklist A copy-paste review checklist template lives in [`references/review-checklist-template.md`](references/review-checklist-template.md). ## See Also - For detailed security review guidance, see `references/security-checklist.md` - For performance review checks, see `references/performance-checklist.md` ## Common Rationalizations | Rationalization | Reality | |---|---| | "It works, that's good enough" | Unreadable, insecure, or architecturally wrong code creates compounding debt. | | "We'll clean it up later" | Later never comes. The review is the quality gate — use it. | | "AI-generated code is probably fine" | AI code needs more scrutiny, not less. It's confident even when wrong. | ## Red Flags - PRs merged without review or with rubber-stamp "LGTM" - Security-sensitive changes without security-focused review - Large PRs that are "too big to review properly" (split them) - No regression tests with bug fix PRs - Accepting "I'll fix it later" — it never happens ## Verification After review is complete: - [ ] All Critical issues are resolved - [ ] All Important issues are resolved or explicitly deferred with justification - [ ] Tests pass - [ ] Build succeeds - [ ] The verification story is documented (what changed, how it was verified)