Automated Review Gates
In one line: Match the reviewer to what changed, not to the developer's guess about whether review is needed.
What: Review gates determine when to dispatch a reviewer and which one, based on what changed.
Why: Voluntary review is unreliable — the developer may not see the security implication, or may judge a "simple" change as not needing review. Trigger conditions that map changes to reviewers remove the judgment call.
Review Gate Rules:
| What Changed | Reviewer to Dispatch | Rationale |
|---|---|---|
API route files (app/api/*.py) | API Reviewer | Convention violations in routes affect external API consumers |
| Authentication or authorization code | Security Reviewer | Auth changes have outsized impact — a single bypass affects all protected resources |
| Database models or migrations | Migration Reviewer | Schema changes are irreversible in production and affect all downstream queries |
| AI decision logic, audit trail, or evidence collection | Compliance Reviewer | Regulatory requirements are non-negotiable and gaps are costly to retrofit |
Files with FORCE ROW LEVEL SECURITY patterns | Security Reviewer + Migration Reviewer | Tenant isolation failures are data breaches |
| New service modules | API Reviewer + Security Reviewer | New services often introduce new data access patterns that need both convention and security checks |
Dispatch timing:
Reviews are most effective after implementation is complete but before merge. This timing ensures the reviewer sees the final state of the code (not an intermediate state that will change) while still being early enough to catch issues before they reach the shared codebase.
In the subagent-driven development model (Section 5.4), reviews happen after each task — not at the end of all tasks. This early feedback prevents a single architectural mistake in task 2 from propagating through tasks 3-8 before being caught.
Review output format:
All project reviewers produce structured output with:
- Severity — Critical (must fix before merge), Important (should fix, may defer with tracking), Minor (optional improvement)
- Location — File path and line number
- Issue — What is wrong, stated specifically
- Fix — What to do about it, stated specifically
- Regulation (compliance reviewer only) — Which regulation is violated
This format keeps findings actionable. "Consider improving error handling" is not actionable. "File app/api/case_crud.py line 47: HTTPException returns the raw database error message. Fix: catch IntegrityError specifically and return a user-facing message without internal details. Regulation: data-protection-by-design." That is actionable.
Evidence: Each reviewer exists because its defect category was encountered in real development and was expensive enough to justify automated prevention — the compliance reviewer catches AI-traceability gaps invisible to general review; the migration reviewer catches async-driver cast-syntax bugs that pass unit tests but fail in production. The checks are committed in the reviewer definitions, so they fire for every author. See Section 5.3.