Keep an issue linked to the relevant port

What the check reads

The verify-stage warning compares an active KnownIssue’s mirror.id with affected_requirements. Mirror scope comes from explicit requirement IDs or source-path annotations when requirements is auto, filtered to active requirements. No overlap produces a finding unless mirror_anchor_exemption contains a reviewer and rationale. The not_applicable class does not by itself excuse an unrelated anchor.

proof audit --check known_issue_mirror_anchor_relevant

An illustrative case

Illustrative case: an authentication issue names a requirement in the token client but points at a mirror covering only document parsing. That link sends later port reviews to the wrong context. Repoint it to the relevant mirror if one exists. If the issue has no relationship to a port, remove the unsupported link rather than selecting an arbitrary mirror.

Resolve the finding

1. Inspect the issue’s affected requirements and the declared mirror’s resolved scope.
2. Repair the anchor or scope if either is wrong. Document an intentional off-scope relationship with a specific reviewer-stamped exemption.
3. Rerun this check and the general KnownIssue completeness check, which handles missing mirror links in the opposite direction.

What a clear result means

The check stays silent if scope cannot be resolved, the mirror has no resolved requirements or the issue names no requirements. A clear result therefore does not establish that every mirror link is meaningful. Scope overlap also does not prove behavioral parity between the implementations.

Continue with one real issue

Known issue affected requirements present · Known issue complete

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