Known issue poc quality effective

The check is default-on at warning, verify stage. It reads every active KnownIssue (open / reviewed / empty status) whose structured severity is high or critical and that already carries a poc_quality block. For each of the eight general rules, the boolean must be true, or the rule must be declared not_applicable with a non-empty reason on an N/A-eligible rule. Otherwise the hop warns, unless a reviewer-stamped poc_quality_exemption sits on the KI.

poc_quality_checked is the document-stage hop: missing block, and the eleven-rule review when its scope includes the KI. submission_validated only asks whether the block exists. A high KI that nobody is submitting can carry an all-false block and clear the presence floor. This hop grades truth whenever a high or critical KI carries one. When the block is absent, this hop is silent so the two never double-flag the missing-block case.

id: KI-P1
status: open
severity: high
title: empty STS token is ACCEPTED
poc_quality:
  real_infrastructure: false
  control_test: false
  current_deployment_relevance: false
  honest_severity: false
  reproducible: false
  no_inflation: false
  operational_path_verified: false
  reachability_verified: false

The suite can still be green. The ticket can still be open. The YAML can still sit in .proof/known-issues/. The eight general rules are real_infrastructure, control_test, current_deployment_relevance, honest_severity, reproducible, no_inflation, operational_path_verified, and reachability_verified. The three Web3-only rules (quantitative_impact, untrusted_attacker, attacker_profitability) are not graded here: the check reads only KnownIssue fields and cannot detect a Web3 project. Among the eight, only reachability_verified may be N/A. Integrity-core rules can never be N/A. Zero high or critical KnownIssues with a block is a pass that inspected nothing. Closed findings are skipped. Medium and low are out of scope. Load failure is a fail, not a warning.

proof known-issue list
proof known-issue edit KI-P1
proof audit --check known_issue_poc_quality_effective

Set each unsatisfied rule true once it genuinely holds, citing where it was verified in poc_quality.notes. Declare N/A with a reason only on reachability_verified here. Or stamp a reviewer poc_quality_exemption. Do not flip eight booleans to true so the hop stays quiet. A present but false checklist is still a finding.

The teaching graph is still one active high KI next to one present checklist. Read the finding. Then set the rules, mark the one N/A-eligible rule, or stamp the waiver.

poc_quality_exemption:
  reviewer: "alex"
  rationale: "local-behavioral correctness defect; PoC review tracked under the document-stage hop"

Close an honest all-false row by setting each rule true with a notes citation. Close an intentional skip with a stamped exemption. Both reviewer and rationale must be non-empty. Completeness stays on known issue complete. The executed-witness gate stays on high severity reproducer grade. Do not treat Salesforce's bulletin as this cell. Jama still authors. Proof vs Jama.

Warning severity. A counted warning does not block advancement. Whether a boolean is actually true is author judgment. The tool surfaces the false rules. It does not independently verify the PoC. Closed and resolved findings are skipped, not flagged. Zero high or critical KnownIssues with a block is a pass that inspected nothing. An absent block is silence: that case belongs to poc_quality_checked. Medium and low are out of scope even with an all-false block. The three Web3-only rules are not graded here. Load failure is a fail, not a warning. 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 completeness hop stays on known issue complete. The executed-witness hop stays on high severity reproducer grade. The engagement stays on software correctness audit. Jama still authors.

What is known issue poc quality effective? Same question. Same URL.

Is this poc_quality_checked? No. That hop is document-stage: missing block, and the eleven-rule review when its scope includes the KI. This hop is verify-stage truth of a present block on high or critical. The two never double-flag an absent block. There is no topic URL for that hop yet.

Is this high severity reproducer grade? No. That hop is whether a high-stakes KI is graded by an executed witness. This hop is whether the present PoC checklist is true. See high severity reproducer grade.

Is this known issue complete? No. That hop is whether every active KI has some evidence kind. This hop is a present checklist whose booleans are false. See known issue 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 missing known-issues directory fail? No. Zero high or critical KnownIssues with a block is a silent pass. Put a YAML there when the behavior is confirmed, then make the checklist true before you leave it at high.

Does an absent poc_quality block fail? No. This hop is silent on a missing block. That case belongs to poc_quality_checked.

Does a stamped exemption fail? No. A poc_quality_exemption with both reviewer and rationale filled is the honest shape for a waived KI.

Does an all-false block fail the merge? No. The check keeps warning severity. A counted warning does not block advancement. Load failure is the fail.

Does a green hop prove the PoC? No. The hop checks that applicable booleans are true or N/A with a reason. It does not run the exploit. It does not run the control test.

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