/evaluate-findings

name: evaluate-findings
description: "Assess review feedback with adversarial verification and decide which suggestions to apply. Use when the user asks to \"evaluate findings\", \"triage review feedback\", or \"filter false positives\"."

Evaluate Findings

Assess external feedback (code reviews, AI suggestions, PR comments) with adversarial verification. Triage findings into actionable verdicts. Do not apply fixes.

Step 1: Assess Each Finding

If you already assessed a finding earlier in this session and recorded a verdict of Skip or Escalate — for example when an iterating loop re-runs review and the same finding resurfaces — do not re-adjudicate it from scratch. When a loop ledger path under `.turbo/loops/` is in context, read it and treat the Skip and Escalate verdicts it records the same way, whichever session recorded them. When the re-reported finding matches one you already judged (same location and substance) and presents no new evidence beyond what your recorded reason already accounts for, keep that verdict and reason without re-reading the code, re-verifying, or routing it to the Devil's Advocate in Step 2. Assess fresh only when the finding raises materially new evidence, or when neither this session nor the ledger holds a verdict for it.

When several findings rest on a shared premise — for example a source-of-truth choice — verify that premise once before adjudicating them individually. Findings whose premise holds proceed through normal per-finding verification; when it fails, they are all Skip, citing the refuted premise.

When a plan governs the work, re-read the decisions it records before adjudicating. Having read it earlier in the session does not count: once it falls out of context, a recorded decision is indistinguishable from no decision at all.

The repo's backlog is `.turbo/backlog.md` at the repo root, or at the main checkout's root inside a linked worktree. A legacy `.turbo/improvements.md` beside it counts as backlog too. When the repo keeps a backlog, search it before adjudicating for the paths and symbols the findings name and for entries on the same subject, leaving out any entry the work in hand sets out to implement. Read every matching entry: run the search uncapped, splitting it into one search per finding when the combined output is too large to read, since output cut off or capped before its end settles nothing about the entries it left out. An entry that parks all or part of the change a finding asks for records a decision to defer it. When that finding holds and acting on it would make the change now, treat it as one that would reverse a decision the user made earlier, naming the entry as the original decision and quoting any condition it records for taking the change up. An entry that only shares the finding's area leaves the verdict to the finding's merits. In both cases, weigh what the entry records about that code when verifying the claim and assessing severity.

For each finding:

1. **Read the referenced code** at the mentioned location — include the full function or logical block, not just the flagged line 2. **Check whether the code has diverged** — if the finding references code that no longer exists or has since changed, skip it and note the divergence. 3. **Determine scope** — clarify whether the issue was introduced by the PR/changeset or is pre-existing.

• Pre-existing issues in earlier commits on the same feature branch are in-scope by default — the entire branch is one coherent unit of work. Judge these on their merits like any in-scope finding.
• Findings genuinely outside the branch's work are the user's call to include. Assign Escalate so the user decides whether to widen the changeset. Before escalating a pre-existing defect, search the sibling code paths that share its root cause, reading every match, and name each one where tracing shows the same defect in the Issue cell, or the paths searched when none has it. Reserve Skip for changes whose cost wildly dwarfs the benefit.

4. **Verify the claim** against the actual code — does the issue genuinely exist?

• When the finding offers a concrete example as evidence — a claimed mishandled input, a claimed wrong output — verify that example independently: a finding can hold in substance while its example does not. Keep the finding and record the correction beside it; drop it only when the claim rests on that example alone.
• When the finding places a defect on one code path on the strength of something true of another path that shares code with it, whether a defect observed there or a state asserted to hold throughout the shared operation, that holds for the other path only. Trace the flagged path to the point where the defect would fire and confirm the state it needs is already in place there (a failure raised before the step that establishes that state never finds it in place), and Skip the claim for that path when it is not.
• When the finding claims an outcome that a sequence of steps produces, such as an exploit, a bypass, or an exhausted or replenished limit, trace the sequence end to end through the state each step changes (what it consumes, restores, writes, or grants) before assigning Apply. Confirming that its preconditions hold leaves the claim open. When the trace shows the outcome does not arise, Skip, citing the step that prevents it. When a step's effect cannot be traced from the code, assign Escalate, naming that step in the Issue cell.
• When the finding asserts a compatibility property, establish two things before assigning Apply: what the existing check actually enforces, and what real counterparts produce today. A claim stronger than the check enforces is a premise error rather than a defect — Skip, citing what the check enforces, or narrow the finding to the property it does enforce and record the narrowing beside it. When neither can be established from the code, the artifacts, or authoritative documentation, keep the finding Escal