# Review Report Template Write the report in the language requested by the user; otherwise match the language of the review request. Preserve source identifiers, commands, file paths, and code symbols exactly. Use category-based finding IDs: - `ARCH`: architecture and evolution - `SEC`: security - `REL`: resilience - `DATA`: data consistency - `PERF`: performance and scaling - `IMPL`: implementation correctness Number IDs within the report, for example `SEC-001`. Assign one primary category to each root cause. Use these severity levels independently of category: - `Critical`: a reachable issue with catastrophic impact, such as broad authorization compromise, widespread sensitive-data exposure, irreversible systemic data loss, or reliable total-service failure. - `High`: a realistic issue causing material authorization or ownership bypass, user-data exposure or corruption, service-wide outage, or a fundamental design failure that blocks supported behavior. - `Medium`: a material but contained correctness, consistency, resilience, scalability, or maintainability failure with a plausible trigger. - `Low`: a verified, bounded defect with limited impact. Do not use `Low` for style preferences or optional improvements. Sort findings by severity, then by impact within the same severity. Security is a category, not a severity; a security finding can have any severity. Use this structure: ```markdown - Summary - Mode: diff | main | full - Target: all | - Baseline: - Reviewed snapshot: - Verification: - Findings - ID: - Severity: Critical | High | Medium | Low - Location: - Analysis: - Recommendation: - Architecture drift - - Documentation drift - - Unverified areas - ``` If there are no qualifying findings, write `Findings: None`. Write `None` for any other empty section. Do not omit verification failures or review limitations.