Parent: #1936
Problem
REVIEW_SYSTEM_PROMPT (src/services/ai-review.ts) exhaustively defines blocker criteria (bug/security-hole/data-loss/build-break/API-contract-break) and explicit severity discipline, but never mentions algorithmic complexity, N+1 queries, unbounded loops/fanout, or other performance regressions as a category the reviewer should look for. REES has ~19 analyzers (dependency, secret, license, redos, typosquat, IaC-misconfig, etc.) but none target the runtime/algorithmic performance of the PR's OWN new code — the closed issue #1814 ("performance guardrails and regression telemetry") is about REES's OWN service performance budgets, a different thing entirely. A genuinely bad performance change (e.g. a DB query moved inside a loop) is currently invisible to the reviewer, not merely under-prioritized.
Requirements
- Add a performance-regression category to the blocker-criteria list in
REVIEW_SYSTEM_PROMPT, instructing the model to flag algorithmic-complexity regressions, N+1 query patterns, and unbounded loop/fanout introduced by the diff.
- Keep severity discipline consistent with existing categories — a performance issue should land as a blocker only when it's a genuine regression (not a style preference), matching the existing "don't nitpick, flag what matters" tone.
- Pure prompt-engineering change — no new service, no new cost, no new analyzer.
Deliverables
- An additional bullet/section in
REVIEW_SYSTEM_PROMPT covering performance-regression detection.
- A small set of prompt-evaluation test cases (a diff with an obvious N+1 pattern; a diff without) to sanity-check the model actually surfaces it, if the existing AI-review test harness supports prompt-behavior assertions.
Acceptance criteria
REVIEW_SYSTEM_PROMPT explicitly instructs the model to look for algorithmic/performance regressions.- No regression to existing blocker categories or their relative weighting/tone.
Expected outcome
A PR that introduces an obvious performance regression (e.g. a query moved inside a loop) has a real chance of being flagged by AI review, instead of being structurally invisible to the reviewer regardless of severity.
Parent: #1936
Problem
REVIEW_SYSTEM_PROMPT(src/services/ai-review.ts) exhaustively defines blocker criteria (bug/security-hole/data-loss/build-break/API-contract-break) and explicit severity discipline, but never mentions algorithmic complexity, N+1 queries, unbounded loops/fanout, or other performance regressions as a category the reviewer should look for. REES has ~19 analyzers (dependency, secret, license, redos, typosquat, IaC-misconfig, etc.) but none target the runtime/algorithmic performance of the PR's OWN new code — the closed issue #1814 ("performance guardrails and regression telemetry") is about REES's OWN service performance budgets, a different thing entirely. A genuinely bad performance change (e.g. a DB query moved inside a loop) is currently invisible to the reviewer, not merely under-prioritized.Requirements
REVIEW_SYSTEM_PROMPT, instructing the model to flag algorithmic-complexity regressions, N+1 query patterns, and unbounded loop/fanout introduced by the diff.Deliverables
REVIEW_SYSTEM_PROMPTcovering performance-regression detection.Acceptance criteria
REVIEW_SYSTEM_PROMPTexplicitly instructs the model to look for algorithmic/performance regressions.Expected outcome
A PR that introduces an obvious performance regression (e.g. a query moved inside a loop) has a real chance of being flagged by AI review, instead of being structurally invisible to the reviewer regardless of severity.