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

  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 ↗