Known issue platform coverage

The check is known_issue_platform_coverage. It is VERIFY-stage. It warns. It is build matrix complete one level down: the same config: vocabulary, the same superset matching, applied per known issue instead of per suite. A record is in scope exactly when some row says the issue no longer reproduces. A record whose verdict is still reproduces is not in scope. One witness settles an existential claim. Asking for a second platform there is busywork. A non-reproduction is a universal claim. One host cannot settle it. The finding names the platforms the record has, the declared targets it has not, and the command to run there. It does not write the YAML. It does not prove the Go. It does not run the reproducer.

Coverage is compared on the platform axes only: os:, arch:, privilege:. Two build targets that differ only on transport: or build: collapse to one platform, so the advice stays about machines rather than lanes. A declared platforms: on the record does not widen the scope. It narrows which targets are suggested, so a Linux-only subject is never asked to run on FreeBSD. No project.build_targets is a skip. Fewer than two distinct declared platforms is a skip. No record proposing a closure is a pass. Opting the check out reports skip, never pass. A Salesforce “known issue” page is not that floor. Ads known issue is that status page.

The resolutions are alternatives, not steps. Refresh the reproducer on the named target and keep both rows. Or declare that the subject cannot exist there with proof known-issue edit KI-116 --add-platform 'os:linux'. That declaration also arms known issue closure platform bound, which refuses to credit a closure observed off those platforms. Do not delete project.build_targets to silence the finding if the suite still claims two machines. That is the finding.

# proof.yaml project.build_targets:
#   darwin-arm64  [os:darwin, arch:arm64]
#   linux-x86_64  [os:linux,  arch:x86_64]
# proof/evidence/ki-116-reproducer.yaml
# verdict: known_issue_not_reproduced
# config: [os:darwin, arch:arm64]
# proof audit --check known_issue_platform_coverage
# [VERIFY] known_issue_platform_coverage
# KI-116 observed only on [os:darwin,arch:arm64]
# not yet on linux-x86_64
# WARN
# proof evidence refresh KI-116

Read both sides before you edit anything. The declared build targets, and the host that recorded the absence. A corpus with one machine skips this hop. That skip is not a proof that every closure was observed on every kernel you ship:

proof audit --check known_issue_platform_coverage
proof help known_issue_platform_coverage
proof evidence refresh KI-116
proof known-issue edit KI-116 --add-platform 'os:linux'
proof config set project.checks.known_issue_platform_coverage.enabled false

The teaching graph is still one declared second platform whose closure was never observed there. Close it by refreshing on the named target and keeping both rows, or by declaring the subject cannot exist there. Do not strip project.build_targets to make the skip look like a pass if the suite still claims two machines. The hop does not run that refresh for you. The hop does not prove the Go.

# refresh on linux-x86_64, keep the darwin row
# proof audit --check known_issue_platform_coverage
# 0 single-platform closures
# VERIFY may move on. warn sits on a missing platform, not a skipped compile

The suite-level hop stays on build matrix complete. The error hop stays on known issue closure platform bound. The quality floor stays on known issue complete. Jama still authors. Proof vs Jama.

Warning when a known issue's closure-relevant evidence exists on only one platform while project.build_targets declares more than one. Default severity is warning. It does not fail the merge unless the audit treats warnings as blocking. No project.build_targets is a skip. Fewer than two distinct declared platforms is a skip. No record proposing a closure is a pass. That skip is not a proof that every closure was observed on every kernel you ship. Opt-out reports skip, never pass. The hop does not write the evidence file. It does not SSH to linux-x86_64. It does not compile the gated subject. It does not prove the Go. A quiet hop is not a proof that Jama's shall still holds on every kernel, only that every in-scope record currently has a second-platform observation, or that nothing asked. We have not scored this floor against a frozen Jama pack, a VectorCAST corpus, or a Salesforce bulletin. The loss is named, not scored. The error hop stays on known issue closure platform bound: whether the only closure is even creditable. This hop is coverage advice after that credit exists.

The suite-level hop stays on build matrix complete. The quality floor stays on known issue complete. The engagement stays on software correctness audit. Jama still authors.

What is known issue platform coverage? Same question. Same URL.

Is this known issue closure platform bound? No. That hop fails when the only closure is not creditable at all. This hop warns when a creditable closure exists on only one of several declared build targets. See known issue closure platform bound.

Is this known issue complete? No. That hop is whether the record has evidence and an origin. This hop is whether a closure-proposing record has been observed on a second platform. See known issue complete.

Is this build matrix complete? No. That hop is whether a declared target's config tokens showed up on some result. This hop applies the same superset rule per known issue. See build matrix complete.

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

Does a still-reproduces record need a second platform? No. One witness settles an existential claim. Only a not-reproduced row is in scope.

Does this finding fail the merge? No by default. The check keeps warning severity. A skip because nothing declared two platforms is not that warning.

Does a quiet hop prove every closure shipped? No. A corpus with one machine skips. The hop observes declared platforms versus the observation hosts. It does not prove the Go.

Is Proof an LDRA alternative for the instrument? No. LDRA still owns the avionics toolchain. Proof vs LDRA.

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