Poc quality checked

The check is default-on at warning, document stage. It reads every active KnownIssue (open / reviewed). Scope is a union. Either limb is enough: any of severity, code_severity, or bounty_severity meets the configured floor (default medium), or the KI has gone outside (submission, upstream_report, or the substring submit in disposition). A low finding that nobody is filing is skipped. A low finding that is being submitted is not.

If the KI is in scope and poc_quality is absent, the hop warns and names the limb: at or above the floor, or being submitted. If the block is present, each applicable boolean must be true, or an N/A-eligible rule must carry a non-empty reason. Otherwise the hop warns. It does not run the PoC.

id: KI-P2
status: open
severity: medium
title: empty STS token is ACCEPTED

The suite can still be green. The ticket can still be open. The YAML can still sit in .proof/known-issues/ with no poc_quality key. That is the missing-block case. known_issue_poc_quality_effective is silent here on purpose: it grades truth only when a high or critical KI already carries a block. submission_validated is an error gate that only asks whether the block exists on a submitting KI. This hop is the document-stage review: missing block, then the eleven rules.

proof known-issue list
proof known-issue edit KI-P2
proof audit --check poc_quality_checked

Write the block and 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 untrusted_attacker, attacker_profitability, or reachability_verified. Integrity-core rules cannot be N/A. Do not flip eleven booleans to true so the hop stays quiet. An absent checklist is still a finding.

The teaching graph is still one active medium KI next to no checklist. Read the finding. Then write the block, set the rules, or mark an N/A-eligible rule with a reason.

poc_quality:
  real_infrastructure: true
  control_test: true
  current_deployment_relevance: true
  honest_severity: true
  reproducible: true
  no_inflation: true
  operational_path_verified: true
  reachability_verified: false
  not_applicable:
    reachability_verified: "local-behavioral correctness defect; no ingress guard to traverse"

On a non-Web3 project the three on-chain rules (quantitative_impact, untrusted_attacker, attacker_profitability) are skipped. The eight general rules still apply. Completeness stays on known issue complete. The present-block truth hop stays on known issue poc quality effective. 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 missing block and the false rules. It does not independently verify the PoC. Closed and resolved findings are skipped, not flagged. Zero in-scope KnownIssues is a pass that inspected nothing. A low KI that nobody is submitting is out of scope even with no block. The three Web3-only rules are skipped on a non-Web3 project unless the check is explicitly enabled. 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 present-block truth hop stays on known issue poc quality effective. 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 poc quality checked? Same question. Same URL.

Is this known issue poc quality effective? No. That hop is verify-stage truth of a present block on high or critical. This hop is document-stage: missing block, then the eleven-rule review when the union includes the KI. The two never double-flag an absent block. See known issue poc quality effective.

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 an in-scope KI has a PoC quality review. 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 missing or false checklist on an in-scope KI. 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 in-scope KnownIssues is a silent pass. Put a YAML there when the behavior is confirmed, then write the checklist before you leave it at medium or file it.

Does an absent poc_quality block fail? Yes, as a warning, when the KI is in the union. A high KI nobody is submitting is in scope here. A low KI that is being submitted is in scope here. A low KI that nobody is filing is skipped.

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. Per-rule gaps are the same warning as a missing block.

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.