Feature: add superseded-finding state to reduce stale triage fixation after corrected receipts

Resolved 💬 2 comments Opened Mar 27, 2026 by Pro777 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

  1. A label or structured state such as finding:superseded and finding:current.
  2. A bot command/template for reporters to post canonical corrections (machine-readable block).
  3. Triage bot behavior that prioritizes latest validated_claim block over initial issue body.
  4. 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

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗