triagelisted

# triage A findings list is not a work list. `triage` turns one into the other: it re-checks each finding against the source, ranks what survives, and routes every item to fix now, defer, or reject. Nothing is dropped silently; a rejected finding stays in the record with its reason. ## When to use it - After `repo-review` or `code-review` returns more findings than one sitting can fix. - When findings arrive from a teammate or a tool and their confidence is unknown. - Not for replying to review comments on your own change; that is `respond-to-review`. - Skip it for a list of one or two findings; just verify and fix them. ## Required inputs - The findings, one per line, each with whatever evidence came with it. - Access to the code the findings point at. - The bar for fix now: what ships soon, what gate must stay green. ## Steps 1. Verify before ranking. For each finding, check the claim against the code it names. Tag it confirmed (reproduced or re-read and true), doubtful (could not confirm; say what would), or wrong (the code does not do what the finding says). 2. Rank the confirmed by severity: blocker (breaks the gate, corrupts data, misleads a user), major (wrong behavior with a workaround, a trap for the next editor), minor (cosmetic, style, a nice-to-have). 3. Route each confirmed finding against the caller's bar for fix now: the bar decides what is worth fixing now, severity decides the order. Blockers always meet the bar. Defer (majors and min