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.

Workflow notes: For an active track, read docs/tracks/<track-id>/notes.md at phase entry or resume and update it when useful context changes or before handoff. Capture observations, tentative ideas, outcomes, blockers, and next actions with evidence links. Follow the memory-management running-note and document-metadata protocols; honor explicit read-only or file-scope limits and keep writes outside pinned verification or release targets.

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?
• Spec reconciliation: Do implemented, verified requirements match the owning docs/specs/<capability>/spec.md in the same implementation PR, with links or a justified no-change disposition in the track spec or bug report? Missing reconciliation is a Required finding; deferred and canceled proposals remain track-local.
• 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?
• Is a new conditional bolted onto an unrelated flow? That's a design smell, not a nit — push the logic into its own helper, state, or policy instead of tangling an existing path.
• Do repeated conditionals on the same shape appear? They signal a missing model or dispatcher. A "temporary" branch is usually permanent debt.

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)?
• Does this refactor reduce complexity or just relocate it? Count the concepts a reader must hold to follow the change. If a "cleaner" version leaves that count unchanged, it isn't cleaner — prefer the restructuring that makes whole branches, modes, or layers disappear over one that re-centralizes the same logic. Prefer deleting an abstraction to polishing it.
• Is feature-specific logic leaking into a shared or general-purpose module? Keep logic in its owning layer, reuse the existing canonical helper instead of a near-duplicate, and don't normalize architectural drift.
• Are type boundaries explicit? Question gratuitous any/unknown/optional/casts and silent fallbacks that paper over an unclear invariant — making the boundary explicit often makes the surrounding control flow simpler.

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?

Structural Remedies

When you flag a structural problem, propose the move — not just the problem. A review that only says "this is complex" leaves the author guessing. Reach for a named restructuring:

• Replace a chain of conditionals with a typed model or an explicit dispatcher.
• Collapse duplicate branches into a single clearer flow.
• Separate orchestration from business logic so each reads on its own.
• Move feature-specific logic out of a shared module into the package that owns the concept.
• Reuse the canonical helper instead of a bespoke near-duplicate.
• Make a type boundary explicit so downstream branching disappears.
• Delete a pass-through wrapper that adds indirection without clarifying the API.
• Extract a helper, or split a large file into focused modules.

Prefer the remedy that removes moving pieces over one that spreads the same complexity around.

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.

Watch file size, not just diff size. A small diff can still push a file past a healthy boundary — around 1000 total lines in a single file (distinct from the ~1000 changed-lines threshold above) is a common inspection signal, not a hard cap. When a change materially grows an already-large file, ask whether to extract helpers, subcomponents, or modules first, before piling more on. Decompose, then add.

What counts as "one change": A single self-contained modification that addresses one thing, includes any test changes justified by the admission gate or an explicit existing-coverage rationale, and keeps the system functional after submission. One part of a feature — not the whole feature.

Track boundary: Check the entire PR against its implementation track's one outcome, declared base, and acceptance evidence. Many small commits, one capability name, or one release date do not justify a huge PR. An oversized or bundled implementation track is a Required finding: preserve the work, return to planning to split it into tracks and PRs, then reverify each resulting diff. Apply the delivery fork; initiative docs PRs must not carry child implementation.

Splitting strategies when a change is too large:

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, understand the intent:

- What is this change trying to accomplish?
- What spec or task does it implement?
- What is the expected behavior change?

Record the exact revision under review. Findings and approvals are evidence for that revision; after fixes, reverify affected behavior and rereview the updated revision.

Step 2: Review the Tests First

Tests reveal intent and coverage:

For substantial test-specific design, pruning, or overlap analysis, apply test-case-design-review. It owns the distinct-defect ledger and Keep/Merge/Rewrite/Remove/Add/Omit decisions; this skill retains the broader five-axis review and final merge assessment.

- Do tests exist for the change?
- Do they test behavior (not implementation details)?
- Are material edge cases and error paths covered?
- Does each added case protect a distinct plausible regression that existing tests would miss?
- Is the behavior tested at the cheapest reliable layer without unjustified duplication across unit, integration, and end-to-end suites?
- Do tests have descriptive names?
- Would the tests catch a regression if the code changed?

Step 3: Review the Implementation

Walk through the code with the five axes in mind:

For each file changed:
1. Correctness: Does this code do what the test says it should?
2. Readability: Can I understand this without help?
3. Architecture: Does this fit the system?
4. Security: Any vulnerabilities?
5. Performance: Any bottlenecks?

Step 4: Categorize Findings

Label every comment with its severity so the author knows what's required vs optional:

This prevents authors from treating all feedback as mandatory and wasting time on optional suggestions.

Lead with what matters. Order findings by leverage: correctness and security first, then structural regressions and missed simplifications, then everything else. Don't bury a real issue under cosmetic nits — a few high-conviction comments beat a long list. If you have one structural problem and ten nits, the structural problem is the review.

Step 5: Verify the Verification

Check the author's verification story:

- What tests were run?
- Did the build pass?
- Was the change tested manually?
- Are there screenshots for UI changes?
- Is there a before/after comparison?

Step 6: Remediate and Rereview

Critical and Required findings enter a loop:

Review -> Fix -> Reverify affected behavior -> Rereview final revision

Behavior-changing fixes follow test-driven-development. Do not approve based on a superseded diff or stale verification report.

Persist the structured findings and final disposition to docs/tracks/<track-id>/review.md, resolving the active numbered track from explicit task/PR context before branch-derived naming. Include the implementation revision, evidence sources, each finding's severity and disposition, and the final verdict. Copy or link the report from the pull request. A later commit containing only evidence or administrative updates in that track does not expand the reviewed scope; changes to requirements, scope, acceptance criteria, canonical specs, or production behavior require affected reverify and rereview.

Multi-Model Review Pattern

Perform review, in-scope fixes, re-verification, and rereview autonomously. Use a different model when useful and available within the existing provider, data-handling, scope, and cost authorization; follow doubt-driven-development's read-only execution and evidence rules. A missing optional model is a disclosed limitation, not a routine human gate. Preserve an explicit read-only review request and any independent or human review enforced by project policy; an agent's verdict is never a fabricated human approval.

A standalone review request authorizes findings and its report. Edit implementation only when remediation is included in the assignment, such as an end-to-end implementation or an explicit request to fix findings.

Use different models for different review perspectives:

Model A writes the code
    │
    ▼
Model B reviews for correctness and architecture
    │
    ▼
Model A addresses the feedback
    │
    ▼
Required reviewers and checks satisfy the authorized merge gate

This catches issues that a single model might miss — different models have different blind spots.

Example prompt for a review agent:

Review this code change for correctness, security, and adherence to
our project conventions. The spec says [X]. The change should [Y].
Flag every issue as Critical, Required, Optional, Nit, or FYI.

Dead Code Hygiene

After any refactoring or implementation change, check for orphaned code:

1. Identify code that is now unreachable or unused
2. List it explicitly
3. Remove confirmed obsolete code created by the authorized change, verify consumers and behavior, and record the removal. In a read-only review, report the finding instead of editing.

Check references, dynamic loading, public consumers, and tests before removal. If ownership or intended behavior remains materially uncertain, preserve the code and ask only when resolving that uncertainty is necessary for the task. Do not require another yes for a verified cleanup already within scope.

DEAD CODE IDENTIFIED:
- formatLegacyDate() in src/utils/date.ts — replaced by formatDate()
- OldTaskCard component in src/components/ — replaced by TaskCard
- LEGACY_API_URL constant in src/config.ts — no remaining references
→ Verify consumers and remove within the authorized refactor; record evidence.

Review Speed

Slow reviews block entire teams. The cost of context-switching to review is less than the waiting cost imposed on others.

• Respond within one business day — this is the maximum, not the target
• Ideal cadence: Respond shortly after a review request arrives, unless deep in focused coding. A typical change should complete multiple review rounds in a single day
• Prioritize fast individual responses over quick final approval. Quick feedback reduces frustration even if multiple rounds are needed
• Large changes: Ask the author to split them rather than reviewing one massive changeset

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

When reviewing code — whether written by you, another agent, or a human:

• Don't rubber-stamp. "LGTM" without evidence of review helps no one.
• Don't soften real issues. "This might be a minor concern" when it's a bug that will hit production is dishonest.
• Quantify problems when possible. "This N+1 query will add ~50ms per item in the list" is better than "this could be slow."
• Push back on approaches with clear problems. Sycophancy is a failure mode in reviews. If the implementation has issues, say so directly and propose alternatives.
• Accept override gracefully. If the author has full context and disagrees, defer to their judgment. Comment on code, not people — reframe personal critiques to focus on the code itself.

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.

Upgrading an existing dependency is a code change like any other, and the riskiest upgrades are the ones merged in bulk with a message like "bump deps." Review them with the same discipline:

1. Read the changelog, not just the version number. Semver is a promise the maintainer may not have kept — a "patch" can carry a behavioral change. For a major bump, read the migration notes and find what breaks.
2. One dependency per change. Upgrade and merge them individually (or in small related groups). When a bulk bump breaks the build, you've lost which package did it; a single-package change makes the cause obvious and the revert clean.
3. Let the tests decide. The upgrade is verified by a green suite before and after, not by "it installed." If coverage around the dependency's behavior is thin, that gap is the real finding — add a test first.
4. Mind the transitive graph. Most installed packages are ones nobody chose directly. Review the lockfile diff, not just package.json; a single direct bump can pull in dozens of indirect changes.
5. Keep the lockfile honest. Commit it, review its diff, and never hand-edit it. The lockfile is the thing that actually pins what ships.

For triaging npm audit findings and supply-chain risk (typosquatting, compromised maintainers), follow the security-and-hardening skill — this section covers the upgrade workflow, that one covers the security verdict.

The Review Checklist

---
type: Review
title: "[Change] review"
description: "Findings and dispositions for [change] at the recorded implementation revision."
status: draft
---

## Review: [PR/Change title]

### Context
- [ ] I understand what this change does and why

### Correctness
- [ ] Change matches spec/task requirements
- [ ] Edge cases handled
- [ ] Error paths handled
- [ ] Tests cover the change adequately

### Readability
- [ ] Names are clear and consistent
- [ ] Logic is straightforward
- [ ] No unnecessary complexity

### Architecture
- [ ] Follows existing patterns
- [ ] No unnecessary coupling or dependencies
- [ ] Appropriate abstraction level
- [ ] Refactors reduce complexity rather than relocate it
- [ ] No feature logic in shared modules; file stays within a healthy size

### Security
- [ ] No secrets in code
- [ ] Input validated at boundaries
- [ ] No injection vulnerabilities
- [ ] Auth checks in place
- [ ] External data sources treated as untrusted

### Performance
- [ ] No N+1 patterns
- [ ] No unbounded operations
- [ ] Pagination on list endpoints

### Verification
- [ ] Tests pass
- [ ] Build succeeds
- [ ] Manual verification done (if applicable)

### Verdict
- [ ] **Approve** — Ready to merge
- [ ] **Request changes** — Issues must be addressed

Optional Whole-Pack References

The required review axes and exit gates are embedded above. Whole-pack installs can load these supplemental checklists:

• Security review guidance: ../../references/security-checklist.md
• Performance review guidance: ../../references/performance-checklist.md

Common Rationalizations

Red Flags

• PRs merged without any review
• Review that only checks if tests pass (ignoring other axes)
• "LGTM" without evidence of actual review
• 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
• Review comments without severity labels — makes it unclear what's required vs optional
• Accepting "I'll fix it later" — it never happens
• A refactor that moves code around without reducing the number of concepts a reader must hold
• A change that grows an already-large file instead of decomposing it
• New conditionals scattered into unrelated code paths (a missing abstraction)
• A bespoke helper that duplicates an existing canonical one, or feature logic placed in a shared module
• A bulk "bump dependencies" PR with no changelog review and no per-package isolation
• A lockfile change that's hand-edited, uncommitted, or merged without reviewing its diff

Verification

After review is complete:

• All Critical issues are resolved
• All Required changes are resolved
• Tests pass
• Build succeeds
• The verification story is documented (what changed, how it was verified)
• The review is saved to docs/tracks/<track-id>/review.md and names the reviewed implementation revision
• Dependency upgrades were reviewed against their changelog, isolated per package, and verified by a green suite with the lockfile diff reviewed

Presumptive blockers: surface and propose the simpler design for each of these; escalate to Required only when the change actively makes structure worse: a refactor that relocates complexity instead of reducing it; a change that pushes a file past the size boundary with no decomposition; feature logic added to a shared module; a near-duplicate of an existing canonical helper; a silent fallback that hides an unclear invariant.