Feature: add superseded-finding state to reduce stale triage fixation after corrected receipts
Status Closed — not planned
Maintainer reply None cached
Activity 2 comments · opened Mar 27, 2026 · closed Apr 26, 2026
Summary
When issue claims evolve (for example, initial claim later narrowed or corrected by stronger receipts), triage appears to keep anchoring on the original framing.
Request: add a first-class superseded/corrected finding state so maintainers and automation can key off the latest validated claim instead of stale issue text.
Why this matters
Security/policy reports are often iterative:
- initial hypothesis
- contradictory evidence
- narrowed final claim
Without explicit supersession metadata, threads can remain fixed on the original wording and miss the corrected actionable finding.
Concrete example pattern
- Initial report claimed top-level chain bypass
- Later receipts showed chain parsing is fixed on current version
- Final validated finding was a different class (wrapper path)
In that workflow, triage quality improves if the system can explicitly mark:
superseded_by: <comment/issue>validated_claim: <current narrowed claim>validated_version: <semver>
Proposed additions
- A label or structured state such as
finding:supersededandfinding:current. - A bot command/template for reporters to post canonical corrections (machine-readable block).
- Triage bot behavior that prioritizes latest
validated_claimblock over initial issue body. - Optional issue form section:
Current claim (if changed since original filing).
Practical outcome
- Less duplicate/noise
- Faster maintainer alignment to current reproducible behavior
- Better trust for reporters who provide corrections instead of clinging to stale claims
Related context
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗