Link a known issue to the promise it violates

What the check reads

The verify-stage warning checks open and reviewed issues for at least one nonblank affected_requirements entry. An explicit requirement_exemption with reviewer and rationale satisfies the alternative. This is a presence check: it does not establish that the named requirement exists or is the right contract. The link makes the issue available to requirement-based lookup and related trace workflows.

proof audit --check known_issue_affected_requirements_present

An illustrative case

Illustrative case: an API accepts an empty credential although the approved authentication requirement says it must reject one. The issue names the endpoint and reproducer but leaves affected_requirements empty. A future agent retrieving the requirement may miss that known violation. Adding the relevant requirement ID preserves the connection between intended behavior, observed failure and later corrective work.

Resolve the finding

1. State expected and observed behavior, then identify the existing requirement that expresses the violated promise.
2. Add the correct affected_requirements link. If intent is missing, recover and authorize a candidate instead of inventing a requirement merely to satisfy the check.
3. For a legitimate exception such as a tooling issue outside the product model, record a reviewer and specific rationale. Rerun and inspect the linked requirement.

What a clear result means

A nonempty ID can clear this check while being wrong. Resolve and review the link, and keep the reproducer and its current execution evidence separately. Exempting an issue documents the absence of a contract; it does not make the underlying problem acceptable.

Continue with one real issue

Known issue complete · Known issue mirror anchor relevant

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