Known issue recheck due

The check is default-on, warning, verify stage. It walks every active KnownIssue (open / reviewed, plus a blank status). A KI without an upstream_report block is never flagged. That is the back-compat case: older corpora do not grow findings just because they never disclosed. A KI whose status is fixed or withdrawn leaves the active set, so it is never flagged either.

The tripwire is one predicate. schedule.recheck_after must parse as a date, that date must be in the past, and response.status must be non-terminal. Terminal is only fixed and wont_fix. Non-terminal is pending, acknowledged, duplicate, fix_in_progress, no_response, or absent (treated as pending). An unparseable date does not fire. A missing schedule does not fire. That is the honest shape: no date, no tripwire.

id: KI-U1
status: open
upstream_report:
  schedule:
    recheck_after: 2026-06-01
  response:
    status: duplicate

The suite can still be green. The tracker can still say duplicate. The YAML can still sit in .proof/known-issues/ with a date that passed in June. Operator memory is then the only thing keeping the disclosure loop alive. That is the overdue-disclosure case. Known issue complete is whether the record has evidence and an origin. Completeness does not ask whether you went back to look.

proof known-issue list --recheck-due
proof known-issue recheck KI-U1 --status still_present \
  --notes "re-verified via repro on 1.4.2" --next-after 2026-12-01
proof audit --check known_issue_recheck_due

A bare proof known-issue recheck appends the outcome and does not move the schedule, so the finding correctly keeps firing. Rolling --next-after forward without performing the re-check is the failure this hop exists to catch: the field goes green while nobody looked. Recording still_present on a surface nobody re-tested is the same lie with more typing. Setting wont_fix on a reply the vendor never gave fabricates a third party's words to silence an audit. Deleting the upstream_report block also silences the check. It destroys the disclosure record rather than closing it.

The teaching graph is still one active disclosed KI next to a lapsed date. Read the finding. Then re-check the surface, or close the loop with the vendor's actual words.

proof known-issue recheck KI-U1 --status still_present \
  --notes "re-verified via repro on 1.4.2" --next-after 2026-12-01

The other honest exits are terminal. Record the vendor's fix, or record the vendor's decline. Do not invent either:

proof known-issue response KI-U1 --status fixed \
  --text "vendor shipped the fix in 1.5.0"
proof known-issue response KI-U1 --status wont_fix \
  --text "vendor declined: out of support"

Completeness stays on known issue complete. Review currency stays on known issues reviewed. Do not treat a Salesforce bulletin as this cell. Jama still authors. Proof vs Jama.

Warning severity. A counted finding does not block the audit. The hop does not fetch the tracker URL, re-run the PoC, or confirm the vendor's words. A KI without an upstream_report is a silent skip, including the case where you deleted the block to silence the warning. An unparseable recheck_after is also a skip, not a finding. Zero active KnownIssues is a pass that inspected nothing. Load failure is a fail. A warning is not a waiver: proof waive is a human authorization gate. The hop does not prove the Go. We have not scored this floor against a frozen Jama pack, a GitHub export, or a Salesforce status page. The loss is named, not scored.

The completeness hop stays on known issue complete. The review-date hop stays on known issues reviewed. The engagement stays on software correctness audit. Jama still authors.

What is known issue recheck due? Same question. Same URL.

Is this known issue complete? No. That hop is whether the record has evidence and an origin. This hop is whether a disclosed KI is overdue for a look. See known issue complete.

Is this known issues reviewed? No. That hop is whether review_date is still current. This hop is the upstream schedule. See known issues reviewed.

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 you disclose, then arm a real next date.

Does a KI without upstream_report fail? No. The hop never flags a record that never disclosed. Deleting the block to silence a finding is not a close.

Does a bare recheck clear the hop? No. The outcome is appended. The schedule does not move until --next-after or a terminal vendor status.

Does a green hop prove the Go? No. The hop does not run the PoC. It does not fetch the tracker. It does not prove the function.

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