28 lines
2.2 KiB
Markdown
28 lines
2.2 KiB
Markdown
# Review Calibration
|
|
|
|
Use this reference only after the open-ended discovery pass. Apply it to challenge candidate findings and suppress false positives.
|
|
|
|
## Finding eligibility
|
|
|
|
Accept a candidate as a finding only when all of these are present:
|
|
|
|
- Concrete evidence in current code or documented design.
|
|
- A violated invariant or reachable, plausible failure scenario.
|
|
- A material consequence under supported behavior or realistic roadmap use.
|
|
- A precise source location that lets another developer verify the analysis.
|
|
- A recommendation that addresses the underlying cause.
|
|
|
|
Actively seek the strongest disconfirming evidence before accepting a candidate. Check whether another layer enforces the invariant, the path is unreachable, the behavior is explicitly unsupported, or the tradeoff is intentional and adequately contained.
|
|
|
|
## Calibration rules
|
|
|
|
- Do not report a missing abstraction, restriction, validation, limit, test, or defensive mechanism solely because it is absent. Demonstrate the failure path or violated invariant caused by the absence.
|
|
- Do not treat a permissive configuration or documented tradeoff as a problem by itself. Report it only when a supported setting bypasses required processing or breaks security, lifecycle, or consistency invariants.
|
|
- Do not treat a simple implementation as an architecture flaw without concrete coupling, duplicated responsibility, boundary leakage, unsafe change propagation, or realistic scaling impact.
|
|
- Do not report theoretical performance limits without a reachable hot path, resource-growth mechanism, and material consequence under realistic use or roadmap requirements.
|
|
- Do not report style preferences, naming preferences, speculative future features, or optional hardening as defects.
|
|
- Do not weaken or reinterpret a valid test to remove an implementation failure. Confirm intended behavior before deciding whether the test or implementation is wrong.
|
|
- Do not duplicate one root cause across review lenses. Assign one primary category and describe secondary impacts in its analysis.
|
|
|
|
Place credible concerns that lack required evidence in `Unverified areas`. State what is unknown, why it matters, and the smallest validation needed to resolve it.
|