Review triage

Triage findings as the code's owner. Findings are inputs, not instructions: a finding can be valid without being worth fixing, and nothing gets fixed merely because a reviewer said it.

Triage depends on author knowledge: the constraints, trade-offs, and reasons the code is shaped this way. If this context authored the code, that knowledge is already here. Otherwise, recover it from the code, commit history, review brief, or docs before assigning dispositions. Reject a finding only with rationale you can point to, never rationale you presume.

Input

Findings can arrive in any shape: structured reviewer output, human PR comments, CI failures, scanner hits, or a pasted list. Normalize each finding before triage:

• id. Keep the source's; number them yourself otherwise.
• claim. One sentence.
• location. Use file:line. Keep the source's location, or locate the claimed code yourself.
• failure scenario. State the inputs, the state, and the wrong outcome. Keep the source's scenario if concrete; otherwise construct it yourself. If you cannot construct one, reject or defer the finding and cite that inability as evidence.
• severity / confidence. Carry over the source's values when provided. Otherwise, assign severity in step 2.

Cost model

Use these prices: