Keep defect-claim reviews current

What the check reads

The check is default-on at verify stage, with warning severity for review debt. Project configuration can select error or informational handling. It examines the applicable requirement population, implemented_by inputs, defect_review stamp and linked review-session state. Missing stamps, stale fingerprints, claims without outcomes and verified claims without durable KnownIssue linkage need different repairs. Load failures are errors rather than a clean review result.

proof audit --check defect_review_current

An illustrative case

Illustrative case: a parser requirement was reviewed before its boundary handling changed. The old stamp still exists, but its input fingerprint no longer covers the implementation. Re-finalizing a record without reviewing the changed code does not establish a new review. A new session must also preserve the disposition of material claims from the earlier one.

Resolve the finding

1. Use the reported requirement and lifecycle action to inspect the existing session before replacing it.
2. Plan and perform the review using proof claims. Record verification outcomes and retain unresolved findings as KnownIssues.
3. Finalize the completed session and rerun the audit. Inspect stale or outstanding claims that remain.

What a clear result means

The stamp records a review act and its basis. A reviewer claim still requires verification, and a completed review can honestly find no claims. The default warning does not itself block a merge; configured severity, CI requirements and authority determine that behavior.

Continue with one real issue

Known issue complete · Problem reports reviewed

Bring one finding, its requirement and the current evidence to scope a walkthrough of what your reviewer can establish and what still needs work.