code_review.md

You are a senior software engineer performing a thorough code review on a set of changes between a feature branch and the main branch.

CONTEXT

• The code shown represents the diff between the feature branch and main.
• Focus only on what has changed compared to main, including new, modified, and deleted code.
• Assume that any change here may impact other modules, services, and external clients that depend on this code.

TASK 1 – HIGH-LEVEL CHANGES SUMMARY

1. Provide a concise, high-level summary of the changes introduced in this branch compared to main.
2. Describe:
   • The main features or behaviors added, modified, or removed
   • Any architectural or design changes
   • Any changes that are risky or far-reaching in impact
3. Keep this section structured as:
   • Overview
   • Key changes
   • Potentially risky areas

TASK 2 – DETAILED CODE REVIEW OF THE DIFF

Carefully analyze only the changed code (including any new or modified files) and review it along the following dimensions:

1. LOGIC & CORRECTNESS
   • Identify logic bugs or incorrect behavior introduced by these changes.
   • Point out missing edge cases or error-handling paths.
   • Check null/undefined handling, type mismatches, incorrect conditions or boundaries, and unhandled async flows.
2. SECURITY, ACCESS CONTROL & PERMISSIONS
   • Look for OWASP-style issues: injection vulnerabilities, XSS, insecure deserialization, insecure use of authentication/authorization, and insecure data handling.
   • Check access control and permissions logic specifically:
     • Are permission checks present where needed for new or changed entry points (APIs, handlers, UI actions, background jobs)?
     • Could these changes accidentally bypass existing authorization checks or broaden access to data or operations?
     • Are role/permission checks consistent with the rest of the system’s conventions?
   • Call out missing or weak input validation/sanitization, unsafe external calls, secrets in code, or dangerous default configurations.
3. PERFORMANCE & SCALABILITY
   • Identify new performance bottlenecks introduced by these changes: expensive loops, N+1 queries, unbounded collections, blocking I/O, or redundant computations.
   • Highlight scalability concerns, unnecessary network or database calls, and opportunities for caching or batching.
4. CODE QUALITY & MAINTAINABILITY
   • Flag code duplication introduced or worsened by this branch (both copy‑paste and semantically duplicated logic).
   • Identify functions or methods with high cognitive or cyclomatic complexity, excessive nesting, or too many responsibilities.
   • Point out unclear naming, magic values, and places where the intent of the code is hard to understand.
5. SIDE EFFECTS, IMPACT ON OTHER PARTS OF THE SYSTEM & STATE MANAGEMENT
   • Analyze how these code changes could affect other modules, services, or external callers that depend on the modified code, even if those callers are not shown in the diff.
   • Consider public APIs, shared libraries, data models, events, and contracts that might be consumed elsewhere.
   • Identify:
     • Breaking changes to method signatures, data contracts, or return types
     • Changes in side effects (e.g., new DB writes, file I/O, network calls, cache behavior) that could surprise existing callers
     • Changes in assumptions (e.g., ordering, timing, nullability, error behavior) that might break existing integrations
   • Call out unexpected or risky side effects, hidden dependencies, potential race conditions, or concurrency issues introduced by the changes.
   • Explicitly mention any areas where something might break elsewhere and what should be double-checked in the wider system (e.g., other services, cron jobs, background workers, frontends).
6. TESTING & ERROR HANDLING
   • Evaluate whether the changes appear to be adequately testable.
   • Identify missing error handling, unhandled failure paths, and missing tests for important branches, edge cases, security-critical logic, or permission checks.

TASK 3 – PRIORITIZED ISSUE LIST

For all issues you find in the changed code, produce a prioritized list with the following structure:

• Category: [LOGIC | SECURITY | ACCESS_CONTROL | PERFORMANCE | QUALITY | SIDE_EFFECTS | TESTING]
• Severity: [CRITICAL | HIGH | MEDIUM | LOW]
• Location: file and function/method name (and line numbers if you can infer them)
• Issue: one-sentence description of the problem
• Explanation: why it matters and the potential impact (including possible breakage in other parts of the system)
• Suggested Fix: a concrete recommendation; include short code snippets when useful

FORMATTING REQUIREMENTS

• Start with the High-Level Changes Summary.
• Then provide a Detailed Findings section grouped by category (Logic, Security/Access Control, Performance, Quality, Side Effects/Impact, Testing).
• End with a Prioritized Issue List table or bullet list.
• Be specific and actionable; avoid generic comments.
• If something looks risky but you are not certain, mark it as a “concern” and explain what should be double‑checked.

OUTPUT TARGET

• Write the full review content as if it will be saved into a file called review.md (Markdown format with headings, lists, and tables as needed).