Rails Code Review (The Rails Way)

When reviewing Rails code, analyze it against the following areas. When writing new code, follow rails-code-conventions (principles, logging, path rules) and rails-stack-conventions (stack-specific UI and Rails patterns).

Core principle: Review early, review often. Self-review before PR. Re-review after significant changes.

HARD-GATE: After implementation (before PR)

After green tests + linters pass + YARD + doc updates:
1. Self-review the full branch diff using the Review Order below.
2. Fix Critical items; resolve or ticket Suggestion items.
3. Only then open the PR.
generate-tasks must include a "Code review before merge" task.

Quick Reference

Review Order

Work through the diff in this sequence. See REVIEW_CHECKLIST.md for the full per-area check criteria.

Configuration → Routing → Controllers → Views → Models → Associations → Queries → Migrations → Validations → I18n → Sessions → Security → Caching → Jobs → Tests

Critical checks to spot immediately:

# N+1 — one query per record in a collection
posts.each { |post| post.author.name }       # Bad
posts.includes(:author).each { |post| post.author.name }  # Good

# Privilege escalation via permit!
params.require(:user).permit!                # Bad — never in production
params.require(:user).permit(:name, :email)  # Good

Additional Critical patterns:

• Business logic in controller action (multi-step domain workflow) — flag as Critical; extract to a service object. A controller action doing more than coordinate (call one service, handle response) is a Critical finding.
• Missing authorization check on sensitive action — flag as Critical.

Severity Levels

Use these levels when reporting findings:

Re-Review Loop

When critical or significant findings were addressed, re-review before merging:

Review → Categorize findings (Critical / Suggestion / Nice to have)
       → Developer addresses findings
       → Critical findings fixed? → Re-review the diff
       → Suggestion items resolved or ticketed?
       → All green → Approve PR

Re-review triggers:

• Any Critical finding was present → mandatory re-review after fixes
• More than 3 Suggestion items addressed → re-review recommended
• Logic or architecture changed during feedback → re-review required

Skip re-review only when: All findings were Nice to have or single-line fixes with zero logic change.

Pitfalls

Integration