triage-findinglisted

# Triage Finding ## Objective Triage existing security findings against the current repository using static code evidence. Return one evidence-backed verdict per supplied finding: `confirmed`, `not_actionable`, or `needs_review`. For `confirmed` and `needs_review` findings, also assign a discrete exploitability stack rank inside that verdict's own queue. This skill is for backlog burn-down. It starts from findings the user already has, such as SARIF results, CVEs, advisories, scanner tickets, bug bounty reports, Jira/Linear issues, or Codex Security finding artifacts. It is not a repository-wide scan, dynamic validation run, fix implementation, dashboard, or queue manager. ## Backlog Burn-Down Scope Treat multiple supplied findings as one backlog-reduction problem, not as a set of unrelated one-off triages. The goal is to turn noisy existing finding sources into a ranked, evidence-backed action queue while preserving one result per input for auditability. For now, run the workflow inline in the current thread, but structure the work like a backlog pipeline: - Build the normalized triage item list for the whole supplied or imported collection before assigning verdicts. Here, normalize means: assign `triage_item_id`, preserve source ids and references, extract the fields in the Inputs section below, and record missing fields as proof gaps without inventing scanner, severity, remediation, or generated Codex Security fields. - Triage each normalized item using static evide