Review

Print ✔ Step 1 done.

Step 2 — Read the Target

Print ▶ Step 2 — Read the Target, then read the target file fully. Also read closely related files if they share state, types, or function contracts with the target (e.g. corresponding .h headers, callers, or persistence partners).

Print ✔ Step 2 done.

Step 3 — Review Against the Checklist

Print ▶ Step 3 — Review Against the Checklist, then work through review-checklist.md section by section:

1. Correctness — Does the code behave correctly for all inputs, including edge cases and error paths?
2. State and Data — Are global state interactions safe? Are persistence read/write paths correct? Any data-loss or corruption risk?
3. Input and Safety — Is user input validated? Is file-loaded input validated? Are string operations and buffer bounds safe?
4. Regression Risk — What cross-module dependencies could break? Identify risk chains: trigger → impact.
5. Evidence Quality — Every finding must have a file:line reference and a concrete impact statement.
6. Output Quality — Merge duplicates, order by severity, keep findings actionable.

Print ✔ Step 3 done.

Step 4 — Classify Findings

Print ▶ Step 4 — Classify Findings, then assign severity to each finding:

• High — can crash, corrupt data, or silently lose data
• Medium — incorrect state or inconsistent behavior under realistic conditions
• Low — style, naming, or minor robustness improvements

Print ✔ Step 4 done.

Step 5 — Produce the Report

Print ▶ Step 5 — Produce the Report, then write the report using the structure from review-report-template.md:

• Findings sorted highest severity first
• Each finding: location (file:line), impact, evidence, suggested fix direction
• Close with Short Summary (3 lines max) and Verification Notes

Print ✔ Step 5 done — Review complete.

Constraints

• Prioritize bugs, safety, and data-loss risks over style.
• Do not propose architectural changes unless unavoidable.
• Do not refactor beyond the finding's direct scope.
• If build or runtime validation cannot be performed, say so explicitly in Verification Notes.