2.7 KiB
2.7 KiB
Review Calibration
Use this reference only after open-ended discovery. Apply it to decide which candidates deserve a place in the report.
Admit a finding
Accept a candidate only when all of these are present:
- An existing implemented behavior, boundary, or intrinsic invariant, including code already exposed within a WIP feature. An absent part of a WIP, planned, or future capability is not itself a basis.
- Concrete evidence that current code violates that behavior or invariant through a reachable, plausible path.
- A material consequence under production-grade operation of the existing capability, without requiring the finished product's full feature set.
- A precise source location and a recommendation that primarily corrects existing behavior or structure rather than delivers a missing product capability.
Ask: Does the repair mainly correct existing behavior, or design and deliver a capability that does not yet exist? The amount of code required is not decisive; the repair's purpose is.
Seek the strongest disconfirming evidence. Check other layers, tests, supported scope, containment, and intentional tradeoffs before accepting a candidate.
Apply the boundary
- A missing safeguard qualifies only when it is intrinsic to an existing interface or mechanism and its absence creates a demonstrated failure. Do not turn expected product policies or lifecycle subsystems into defects merely because a mature product will need them.
- For configuration, distinguish enforceable technical validity from operator judgment. Report values that violate an implemented mechanism's objective preconditions or are silently misapplied; do not claim the program can prove secret entropy or prevent every poor but technically valid policy choice.
- Report architecture or evolution risk only when current design causes concrete coupling, boundary leakage, unsafe change propagation, or material rework for a committed direction. A missing future subsystem is not an architecture flaw.
- Require a reachable hot path, resource-growth mechanism, and material impact for performance findings. Do not report style, naming, speculative scale, or optional preference as a defect.
- Keep one primary violated invariant and root cause per finding. Do not combine independent missing defenses to raise severity; assign one category and describe only supported secondary impacts.
- Preserve valid tests and intended behavior. Never weaken a test to dismiss an implementation failure.
Use Unverified areas only for a near-qualifying current defect that a specific factual check can resolve. Omit undecided product policy, future capability, and general hardening ideas rather than using this section as a backlog.