Review And Fix

Run:

git diff --name-only $(git merge-base HEAD origin/HEAD 2>/dev/null || echo "HEAD~1") HEAD 2>/dev/null || git diff --name-only HEAD~1 HEAD 2>/dev/null || git status --porcelain | awk '{print $2}'

If no changes are found, inform the user there is nothing to review and conclude with a no-op result.

Build a thorough understanding of:

• What was changed and why (infer intent from the diff and surrounding code)
• How the changes interact with the rest of the codebase
• Whether the changes are complete and consistent

Also get the full diff for reference:

git diff $(git merge-base HEAD origin/HEAD 2>/dev/null || echo "HEAD~1") HEAD

1. Bug Determination Criteria - Flag issues that:

• Meaningfully impact accuracy, performance, security, or maintainability
• Are discrete and actionable (not general codebase issues)
• Were introduced in these changes (not pre-existing bugs)
• Are provably broken (not speculation about potential issues)
• The author would likely fix if made aware
• Can be traced to specific affected code parts

2. Contract Consistency:

• Verify all referenced properties exist in their types/interfaces/classes
• Check for invalid, missing, or renamed properties
• Confirm changes don't break inheritance, composition, or overrides
• Look for contract violations across related entities

3. Data Model Validation:

• Check queries filter soft-deleted records appropriately
• Verify active/deactivation flags are checked
• Ensure database constraints aren't violated
• Confirm field types match schema definitions

4. Reference and Usage Review:

• Trace references to changed functions, methods, or classes
• Ensure usages remain compatible with changes
• Watch for subtle breaking changes

5. Security review:

• Check for exposed sensitive data
• Verify input validation
• Look for injection vulnerabilities

6. Code quality checks:

• Identify code smells (long methods, complex logic, tight coupling)
• Find duplicated code that should be refactored
• Look for incomplete implementations or TODO comments

7. Performance considerations:

• Look for inefficient algorithms
• Identify potential memory leaks

8. Concurrency and atomicity issues:

• Check for race conditions in shared state access
• Verify atomic operations where required
• Look for missing transaction boundaries

Review Principles:

• TRUST THE TYPE SYSTEM: Avoid reporting type errors that the compiler would catch
• One finding per distinct issue
• Focus on issues the author would want to fix
• Avoid trivial style nits unless they obscure meaning
• Verify findings against the actual codebase context

Use this exact format:

Severity levels:

• 🔴 High: Bugs, security issues, data loss risks, broken functionality
• 🟡 Medium: Logic issues, missing edge cases, performance problems
• 🟢 Low: Code quality, maintainability, minor improvements

Keep descriptions concise (1-2 sentences max). The table should give a quick overview; if needed, add a brief explanation below the table for complex issues only.

If no issues are found, say so clearly and briefly note what you reviewed.

After presenting the table, proceed to the next step to fix all identified issues.

For each issue:

1. Read the relevant file (if not already in context)
2. Make the fix using the appropriate editing tool
3. Verify the fix doesn't introduce new issues

Work through issues in order of severity (High first, then Medium, then Low).

After fixing all issues, present an updated summary table:

If any issue could not be fixed, explain why briefly and provide clear next steps for the user to address it manually (e.g. "Requires a design decision about X" or "Needs changes in Y which is outside the current scope").