Topic · known issue affected requirements present

Known issue affected requirements present

Gist

Known issue affected requirements present is whether an active KnownIssue names the requirement contract it violates. A finding that empty api_key must be rejected, with affected_requirements empty and no stamped waiver, is invisible to find_tests, get_requirement, and mirror auto-detect. Proof runs proof audit --check known_issue_affected_requirements_present. Jama still authors.

proof audit --check known_issue_affected_requirements_present

Keep the Jira ticket if the board already owns it. Keep Jama if it already authors the shall. Neither one is the field the trace graph keys on.

Request demo Last contract-less KI vs this hop

01 · The silent ledger row

A KI with no requirement exists. Nothing in the graph can reach it.

Evidence is not a contract. This hop asks whether the finding names the shall it violates, or carries a reviewer-stamped waiver that it does not.

The check is default-on at warning, verify stage. It reads every active KnownIssue (open / reviewed / empty status). It asks one question: is there at least one non-blank affected_requirements entry, or a requirement_exemption with both reviewer and rationale filled. Absent both, the hop warns. The field is the single key find_tests and get_requirement follow from a shall to its bound findings. Mirror auto-detect uses the same field to decide which mirrored component the finding lands on. No other check requires it.

This hop does not ask whether every active KI has some evidence kind. That is known issue complete. It does not ask whether a bound test name contradicts the finding. That is known issue reproducer consistent. It does not ask whether a selector actually resolves. That is known issue reproducer present and resolves. A complete KI with a resolving, well-named reproducer still fails here if it names no shall.

id: KI-R3
status: open
title: empty api_key must be REJECTED
affected_requirements: []

The suite can still be green. The ticket can still be open. The YAML can still sit in .proof/known-issues/. Nothing that starts from a requirement id can see KI-R3. Zero active KnownIssues is a pass that inspected nothing. Closed findings are skipped.

proof known-issue edit KI-R3 --affected-requirements SYS-REQ-AUTH-12
proof audit --check known_issue_affected_requirements_present

Name the shall, or stamp a waiver that the finding is a process or tooling defect with no product requirement to bind. Do not leave the list empty so the hop stays quiet. A ledger row that no requirement can reach is still a finding.

02 · The exhibit

Same KI-R3. An empty list, or this hop.

Open finding, no requirement id, no stamped waiver. Click the tabs.

The row

Ask does the KI still exist in the ledger
Stamp KI-R3.yaml is present, status open
Why affected_requirements is empty, no waiver

Status green

This hop

Nobody asked whether a requirement, a test lookup, or a mirror can reach the row. known_issue_complete still reads as present.

No stamp

The row

Keep the Jira ticket. Keep the Jama field. That is not this hop.

Keep the record

Proof

Ask does the active KI name a non-blank requirement id, or carry a stamped requirement_exemption
Out known_issue_affected_requirements_present KI-R3 declares no affected_requirements

Invisible

Same KI-R3. An empty list, or this hop. Click the tabs.

Surface	What they do	What Proof does	What we lose
Known issue complete	Whether every active KI has some evidence kind, including reproduction_steps prose.	Whether that KI names the shall it violates.	Not the quality floor. See known issue complete.
Known issue reproducer consistent	Whether a bound test name contradicts the finding.	Whether the finding is reachable from a requirement id.	Not the accept-verb hop. See known issue reproducer consistent.
Known issue reproducer present and resolves	Whether the selector, command, or Reproduces annotation actually resolves.	Whether the KI has a contract key at all.	Not the presence floor. See known issue reproducer present and resolves.
Salesforce known issue	A hosted vendor bulletin. Ads known issue is that page.	A YAML object whose affected_requirements the audit can fail next to the KI.	Not a status page. Bare "known issue" is that SERP, not this hop.
Jira ticket	A linked-issue field the board already owns.	A YAML object whose requirement list is the key the trace graph follows.	Not a ticket workflow. We have not frozen a Jira pack.
Jama field	The authoring programme. Attributes if you put them there.	A YAML object the audit can fail next to the shall.	Not Jama's V&V. Jama still authors. We have not run a frozen Jama pack.

The teaching graph is still one active KI next to one empty list. Read the finding. Then name the shall, or stamp the waiver.

requirement_exemption:
  reviewer: "alex"
  rationale: "tooling defect in the CI runner; no product shall to bind"

Close a missing contract by naming the id so trace and mirror can reach the row. Close an honest process finding with a stamped exemption. Both reviewer and rationale must be non-empty. A list of blank strings does not count. Completeness stays on known issue complete. Presence stays on known issue reproducer present and resolves. Accept-verb stays on known issue reproducer consistent. Do not treat Salesforce's bulletin as this cell. Jama still authors. Proof vs Jama.

03 · The honest loss

Proof names a KI with no contract key. It does not check that the id exists, and it does not prove the Go.

A green known_issue_affected_requirements_present can still mean there were no active KnownIssues. The hop is a warning. Jama still authors.

Warning severity. A counted warning does not block advancement. Naming the shall is author judgment. The tool surfaces the missing field. Closed and resolved findings are skipped, not flagged. Zero active KnownIssues is a pass that inspected nothing. Load failure is a fail. The hop does not look up the id in the spec corpus. A string such as TODO is a non-blank entry and counts as present. The hop does not check that the finding actually violates that shall. 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 quality-floor hop stays on known issue complete. The accept-verb hop stays on known issue reproducer consistent. The presence hop stays on known issue reproducer present and resolves. The engagement stays on software correctness audit. Jama still authors.

Request demo How the install is bought

04 · Nearby questions

What people type next.

What is known issue affected requirements present? Same question. Same URL.

Is this known issue complete? No. That hop is whether every active KI has some evidence kind, including prose. This hop is whether the KI names a shall. See known issue complete.

Is this known issue reproducer consistent? No. That hop is whether a bound test name contradicts the finding. This hop is the contract key. See known issue reproducer consistent.

Is this known issue reproducer present and resolves? No. That hop is whether a selector, command, or Reproduces annotation actually resolves. This hop is whether a requirement id is present. See known issue reproducer present and resolves.

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 shall it violates.

Does a stamped exemption fail? No. A requirement_exemption with both reviewer and rationale filled is the honest shape for a process or tooling defect.

Does a missing contract fail the merge? No. The check keeps warning severity. A counted warning does not block advancement.

Does a green hop prove the finding? No. The hop checks that a non-blank id or a stamped waiver is present. It does not look up the id. It does not run the code.

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