Reviewing Code

Review the requested change, not the entire codebase. Treat the task as read-only unless fixes are requested. Keep this as an ordinary code review with a security baseline; when security is the primary objective or acceptance criterion, use auditing-code-security instead of expanding this workflow into a full security audit.

Workflow

1. Determine the exact target and comparison base from the request and repository or PR context. Use the target branch's merge base; do not assume main. State broader file-audit scope when no diff is involved.
2. Infer intended behavior from the request, issue/PR context, tests, docs, and surrounding code. Label material assumptions.
3. Trace changed behavior through relevant callers, contracts, state, errors, and downstream consumers. Report issues introduced, worsened, or made reachable by the change; separate directly relevant pre-existing problems.
4. Check, where plausible:
   • correctness, boundaries, state transitions, retries, concurrency, partial failure, and cleanup
   • where repeated work without progress stops, and its worst-case time, resources, cost, and side effects
   • interfaces, schemas, migrations, jobs, caches, feature flags, permissions, and configuration
   • security baseline: affected assets and trust boundaries; authn/authz and tenant or object ownership; source-to-sink validation and injection; secrets, logging, and sensitive data; dependency and configuration exposure
   • repeated work, I/O, queries, blocking, leaks, and expected scale
   • tests for changed behavior and concrete error paths; maintainability only where it creates real cost or risk
5. Run focused checks when feasible. Passing checks support but do not prove correctness.
6. Stop after the relevant diff, directly affected contracts/callers, and focused evidence are covered. Distinguish confirmed findings, inferred risks, and unverified areas.