Keep code-signal suppressions reviewable

What the check reads

The verify-stage warning check reads project.signals.suppressions in proof.yaml. It reports a blank reason, an invalid or expired expires value, and a broad signal_id or rule_id wildcard without a narrow path. A missing expiry does not itself trigger the date check. With no declared suppressions, the check passes. Dates can be calendar dates or RFC3339 timestamps.

proof audit --check code_signal_suppressions_reviewed

An illustrative case

Illustrative case: a suppression matches http.* everywhere and says only that the analyzer is noisy. That leaves future production HTTP clients outside review. If the real exception concerns generated fixtures, restrict the path to those fixtures and explain why their behavior is outside the obligation. Retain a review date where the exception depends on a temporary condition.

Resolve the finding

1. List the suppressed rows with proof signals matrix and identify which files each exception actually covers.
2. Replace an empty reason with the technical basis. Narrow wildcard paths and remove exceptions whose basis no longer holds.
3. Correct or renew expiry only after reviewing the underlying condition. Rerun the check and inspect the remaining suppressed rows.

What a clear result means

The check validates exception hygiene, not the truth of the rationale. Provider or obligation selectors can further narrow a rule, but they do not replace the path requirement for a broad wildcard. A date-free exception can remain effective, so choose that intentionally.

Continue with one real issue

Code signal obligations reviewed · Waivers 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.