Code Reviewer

#What the Code Reviewer reviews

The Code Reviewer focuses on correctness, maintainability, convention adherence, and specification compliance. It complements — not duplicates — the Security Reviewer's vulnerability lens. Both run in parallel on every diff during /synthex:review-code/synthex:review-code.

Concretely, the Code Reviewer assesses:

• Correctness. Does the code do what the task says it does? Any logic errors, off-by-one bugs, mishandled edge cases?
• Maintainability. Is the structure clear enough that a reader six months later will understand it? Are abstractions earning their complexity?
• Convention adherence. Does the diff match what's documented in CLAUDE.md, .eslintrc, .prettierrc, and the configured convention_sources?
• Spec compliance. For any spec under code_review.spec_paths (default docs/specs/), does the diff respect the rules — design tokens, SLO commitments, security boundaries?
• Reuse. Is there an existing helper, hook, or utility the diff should be using instead of reimplementing?

#What it explicitly does not do

• Security vulnerabilities. That's the Security Reviewer's job. The two reviewers are scoped deliberately to keep their lenses pure — when they flag the same finding, the agreement is high-signal; when they disagree, the disagreement itself is signal.
• Performance. Unless the project has added the optional Performance Engineer to the reviewer roster.
• Design system drift. Unless the project has added the optional Design System Agent.
• Make merge decisions. Reviewers are advisory. They emit findings + a verdict; the orchestrating Tech Lead (or you, for [H] review gates) decides what to do.

#Severity policy

The Code Reviewer tags every finding with one of critical | high | medium | low. The default policy in .synthex/config.yaml is min_severity_to_address: high — meaning the review loop iterates until all critical and high findings are resolved. medium and low are surfaced but do not block merge.

A finding shape:

### Finding — high: Missing null-safety on currentUser before .id access

**Location:** `app/api/profile/route.ts:42`
**Category:** correctness

The handler reads `session.currentUser.id` but `getSession()` returns
`Session | null`. On an unauthenticated request this throws `TypeError:
Cannot read properties of null` instead of returning a 401.

**Suggested change:**

  if (!session?.currentUser) return new Response(null, { status: 401 });

This shape is consumed by the Findings Consolidator which deduplicates findings across reviewers without rewriting wording or severity.

#Mentorship over pedantry

The Code Reviewer is modeled on Google's code review standards: every finding should teach the author something — not just what is wrong, but why it matters and what a better approach looks like. A pedantic reviewer that flags every minor preference produces review-fatigue without improving the codebase; an objective reviewer that picks substantive issues and explains them lifts the team's bar over time.

In practice this means the Code Reviewer:

• Explains the principle behind a finding, not just the rule it violates.
• Suggests concrete code changes when feasible.
• Approves diffs that improve code health even when they aren't perfect.

#Multi-model option

For high-stakes diffs, the Code Reviewer can be supplemented by the multi-model review pipeline — the same diff reviewed by Claude AND by external CLI adapters running other LLM families. Disagreement across families is high-signal; agreement raises confidence. Configure via the code_review block in .synthex/config.yaml.