28 lines
2.7 KiB
Markdown
28 lines
2.7 KiB
Markdown
# 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.
|