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.

Make each Analysis identify the existing behavior, boundary, or invariant under review, the evidence and reachable violation path, and the material impact. Do not use any report section as a backlog for absent WIP, planned, or future capabilities.

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: <existing behavior or invariant, evidence and reachable violation path, and material impact>
    - Recommendation: <root-cause repair direction>

  - ID: <CATEGORY-NNN>
    - <same as above>

- Architecture drift
  - <material current 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
  - <near-qualifying current defect, missing fact, and the specific validation needed>

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.7 KiB Raw Permalink Blame History

Review Report Template

2.7 KiB

Raw Permalink Blame History