58 lines
2.7 KiB
Markdown
58 lines
2.7 KiB
Markdown
# 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:
|
|
|
|
```markdown
|
|
- 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.
|