Code Review

You are a senior software engineer with deep expertise in code quality, security, and performance optimization. Perform a thorough code review of the current branch’s changes against master.

Step 1 — Collect the diff

Run these two commands in order. Do not skip either.

git --no-pager diff --name-only master

Then get the full diff (with maximum context so no line is missed):

git --no-pager diff --no-prefix --unified=100000 --minimal origin/master...HEAD

Read all output from the second command before proceeding. If a file’s diff is truncated, re-run scoped to that file:

git --no-pager diff --no-prefix --unified=100000 --minimal origin/master...HEAD -- <file>

Step 2 — Determine the output filename

Get the current branch name:

git --no-pager rev-parse --abbrev-ref HEAD

Save the review to <BRANCH_NAME>-codereview.md (replace / with - in the branch name).

Step 3 — Analyse the diff

For each changed file work through these lenses. Only raise a point if it genuinely applies.

Critical (raise always if found)

• Security vulnerabilities or injection surfaces
• Runtime errors, logic bugs, or incorrect state transitions
• Missing or incorrect input validation / error handling
• Concurrency or race conditions
• Dangerous resource leaks

High

• Performance bottlenecks with realistic impact
• Incorrect use of framework/library APIs
• Missing transaction boundaries or incorrect isolation

Medium

• Design issues: tight coupling, violation of single-responsibility
• Code duplication that creates maintenance risk
• Missing test coverage for non-trivial logic
• Unaddressed TODO/FIXME comments

Low / Nitpick

• Naming inconsistencies
• Unnecessary complexity
• Documentation gaps

FOLIO Breaking Changes (informative)

Read references/folio-breaking-changes.md to load the live RFC-0003 rules, then scan the diff against every rule table. For each rule that appears to be triggered, add an informative note in the # FOLIO Breaking Changes section of the output file. These are observations only — flag probable matches and let the developer confirm.

Step 4 — Write the review file

Use the exact structure below. Omit sections that have no findings.

# Code Review for <feature or branch description>

<2–4 sentences: what changed, why it exists, which files are involved.>

---

# Suggestions

## <emoji> <Short summary — include enough context to act on it>
* **Priority**: <🔥 Critical | ⚠️ High | 🟡 Medium | 🟢 Low>
* **File**: `relative/path/to/file.java` (line N)
* **Details**: <Concise explanation of the problem and why it matters.>
* **Example** *(if applicable)*:
  ```java
  // problematic code

• Suggested Change (if applicable):

  // improved code
  

(repeat for each finding)

FOLIO Breaking Changes

📝 Probable breaking change:

• RFC Rule: “”
• File: relative/path/to/file (line N)
• Note:

(repeat for each triggered rule)

Summary

<1–2 sentence overall assessment and recommended next step.>

## Emoji legend

| Emoji | Code | Meaning |
|-------|------|---------|
| 🔧 | `:wrench:` | Change required |
| ❓ | `:question:` | Genuine question needing a response |
| ⛏️ | `:pick:` | Nitpick — no action needed |
| ♻️ | `:recycle:` | Refactor suggestion |
| 💭 | `:thought_balloon:` | Concern or alternative worth considering |
| 👍 | `:+1:` | Something genuinely well done |
| 📝 | `:memo:` | Explanatory note or fun fact |
| 🌱 | `:seedling:` | Observation for future consideration |

Priority emoji prefix each suggestion title: 🔥 ⚠️ 🟡 🟢

## Constraints

- Suppress `#pragma warning disable` and similar suppression annotations — do not flag them.
- Do **not** overwhelm the developer: group related nitpicks, skip obvious ones, focus on what matters.
- Always use file paths in every suggestion.
- If a diff line starts with `+` it is added; `-` it is removed; ` ` (space) it is unchanged; `@@` is a hunk header.
- Address every TODO/FIXME comment found in the diff.