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:

- Summary
  - Mode: diff | main | full
  - Target: all | <path/package/component>
  - Baseline: <commit or none>
  - Reviewed snapshot: <HEAD and workspace state>
  - Verification: <build, vet, test, and format-check results>

- Findings
  - ID: <CATEGORY-NNN>
  - Severity: Critical | High | Medium | Low
  - Location: <filename:line>
  - Analysis: <evidence, reachable causal path, and material impact>
  - Recommendation: <root-cause repair direction>

- Architecture drift
  - <material differences between documented and implemented architecture, referencing finding IDs instead of duplicating analysis>

- Documentation drift
  - <documentation inaccuracies that can materially mislead implementation, operation, or review>

- Unverified areas
  - <unverified area, reason, and required validation>

If there are no qualifying findings, write Findings: None. Write None for any other empty section. Do not omit verification failures or review limitations.

2.3 KiB Raw Blame History

Review Report Template

2.3 KiB

Raw Blame History