Known issue mirror anchor relevant

The check is default-on at warning, verify stage. It reads every active KnownIssue (open / reviewed / empty status) that already declares a mirror: block. Scope is the same union the mirror machinery uses: requirement ids annotated under the mirror's source.paths for requirements: auto, or the explicit id list, filtered to currently-active requirements. If none of the KI's affected_requirements sit in that set, the hop warns.

Known issue complete auto-detects the other direction: a KI whose requirements fall inside a mirror's scope but that declares no link. The not_applicable opt-out silences that floor, so an author can park a finding on an arbitrary port and nothing objects. This hop reads the declared id against the resolved scope and fires when the sets do not intersect. A KI with no affected_requirements is not judged here. That gap is known issue affected requirements present.

id: KI-M1
status: open
title: empty STS token must be REJECTED
affected_requirements:
  - SYS-REQ-STS-4
mirror:
  id: MIR-OCR
  class: not_applicable

The suite can still be green. The ticket can still be open. The YAML can still sit in .proof/known-issues/. Mirror tooling still reasons about KI-M1 through MIR-OCR. Zero active KnownIssues is a pass that inspected nothing. Closed findings are skipped. A declared mirror that resolves to no scope is silence, not a fail. Load failure is silence too. Precision-first.

proof mirror list
proof known-issue edit KI-M1
proof audit --check known_issue_mirror_anchor_relevant

Repoint the anchor to the mirror whose scope the finding actually falls inside, drop the mirror: block if the finding relates to no port, or stamp a reviewer mirror_anchor_exemption. Do not leave not_applicable on a port the shall never touches so the hop stays quiet. An off-scope row is still a finding.

The teaching graph is still one active KI next to one named port. Read the finding. Then repoint the anchor, drop it, or stamp the waiver.

mirror_anchor_exemption:
  reviewer: "alex"
  rationale: "cross-port finding; MIR-OCR is the only published parity relationship"

Close an honest off-scope row by naming the mirror whose source.paths actually contain the shall. Close an intentional cross-port finding with a stamped exemption. Both reviewer and rationale must be non-empty. Completeness stays on known issue complete. The contract key stays on known issue affected requirements present. The rewrite cluster stays on characterization testing and mirrors. Do not treat Salesforce's bulletin as this cell. Jama still authors. Proof vs Jama.

Warning severity. A counted warning does not block advancement. Naming the right port is author judgment. The tool surfaces the empty intersection. Closed and resolved findings are skipped, not flagged. Zero active KnownIssues is a pass that inspected nothing. Load failure is silence. A declared mirror that resolves to no scope is silence: the hop cannot prove irrelevance. A KI with no affected_requirements is not judged here. The hop does not check that the finding actually describes that port's behavior. Overlap of requirement ids is the whole test. The hop does not prove the Go. We have not scored this floor against a frozen Jama pack, a Salesforce bulletin, or a Jira export. The loss is named, not scored.

The missing-anchor hop stays on known issue complete. The contract-key hop stays on known issue affected requirements present. The rewrite cluster stays on characterization testing and mirrors. The engagement stays on software correctness audit. Jama still authors.

What is known issue mirror anchor relevant? Same question. Same URL.

Is this known issue complete? No. That hop is whether every active KI has some evidence kind, and it auto-detects a missing mirror link. This hop is a declared anchor whose scope the KI never touches. See known issue complete.

Is this known issue affected requirements present? No. That hop is whether the KI names a shall. This hop assumes that list exists and asks whether it overlaps the named port. See known issue affected requirements present.

Is this characterization testing? No. That page is old vs new behavior on a port. This hop is whether a finding bound to that port sits in its requirement set. See characterization testing and mirrors.

Is this a Salesforce known issue? No. Ads known issue is that status page. A hosted vendor bulletin is not this cell.

Does a missing known-issues directory fail? No. Zero active KnownIssues is a silent pass. Put a YAML there when the behavior is confirmed, then name the port whose scope contains the shall.

Does a stamped exemption fail? No. A mirror_anchor_exemption with both reviewer and rationale filled is the honest shape for a cross-port finding.

Does an off-scope anchor fail the merge? No. The check keeps warning severity. A counted warning does not block advancement.

Does a green hop prove the port? No. The hop checks that at least one affected requirement id sits in the named mirror's resolved scope. It does not run the old binary. It does not run the new binary.

Is Proof a Jama alternative for the shall? No. Jama still authors. Proof vs Jama.