/apply-findings

name: apply-findings
description: "Apply accepted review findings as code changes, escalating ambiguous ones to the user. Use when the user asks to \"apply findings\", \"apply fixes\", or \"apply the review results\"."

Apply Findings

Apply evaluated findings from the conversation context. Findings must have been through `/evaluate-findings` first.

Step 1: Identify Findings

Collect all findings from the conversation context. Findings should have Verdict columns (Apply, Skip, Escalate) from `/evaluate-findings`.

If findings are unevaluated (raw output without verdicts), stop and say to run `/evaluate-findings` first.

Step 2: Apply in File Order

Group Apply findings by file path and apply in file order to minimize context switching. For each finding:

1. Read the full function or logical block at the referenced location 2. Verify the finding still applies to the current code 3. Before applying a fix that stops a failure, whether the finding suggested it or you derived it, confirm the fix makes the failure the finding describes unreachable rather than only defeating the finding's reproduction: construct an input that clears the point the fix guards, trace whether it still reaches that failure further along, and write any regression test the fix adds from that input. When the fix encodes, escapes, quotes, or otherwise sanitizes untrusted input, construct such inputs from every character class the target interpreter treats specially and name what in the fix blocks each one; a class with no blocker means the fix is incomplete, including when it reproduces the finding's suggested wording. When the finding carries a suggested fix, also treat the fix as a separate claim from the finding and verify it independently — trace it against the failure modes the finding names, then against the behavior the code had before the fix on inputs the finding never mentioned, since a remedy can address the named mode while regressing an axis alongside it. Where the finding arrives with opposing remedies recorded, verify the measured one first, and where none was measured, measure before applying rather than choosing on the proposer's authority. When a fix removes a guard, check, rule, fallback, or retry as unreachable or redundant, including one you chose to remove while applying a fix, and the evidence is a comparison of runs with and without it, those runs must include the inputs it exists for, built on purpose where the condition it protects is hardest to meet, unless the evaluation already ran them. Runs that never reach those inputs leave the removal unsettled, and an unsettled removal does not hold up. If a suggested fix does not hold up, treat the finding as Escalate (surface it in Step 3) and record why the remedy fails, rather than applying an unsound fix on the finding's authority. If a fix you derived does not hold up, revise it, and when no revision holds up, treat the finding as Escalate (surface it in Step 3) and record why. 4. When the fix would reverse a decision the user made earlier — in discussion or recorded in the artifact — treat the finding as Escalate (surface it in Step 3) and name the original decision. Judge by the outcome rather than the wording of the option the user chose: a reversal leaves the user with something materially different from what they chose. When the finding refutes only the factual premise the user's choice rested on and the fix leaves the chosen outcome intact, that is a premise correction: confirm the refutation against whichever of the code, the governing artifact, or authoritative documentation the premise turns on, and when none settles it, treat the finding as Escalate. Otherwise continue with the remaining checks, and state both the corrected premise and the chosen outcome it leaves standing in Step 4. 5. Check what the fix you are about to make changes about the inputs the code accepts. When the change in accepted inputs is exactly the defect the finding names, continue with the remaining checks. When it turns away or newly admits anything beyond that defect — a value or path a legitimate caller could send — that is a behavior change: treat the finding as Escalate (surface it in Step 3) and name the input class that changes. 6. Check whether the fix you are about to make adds machinery the evaluated finding does not name: a lease, lock, queue, versioning scheme, state machine, or new persistent entity. A fix that specifies such machinery in a plan adds it, the same as one that writes it into code. When the fix adds any, treat the finding as Escalate (surface it in Step 3) and name the machinery. 7. Make the fix 8. If the finding renames an identifier, changes a recurring shape — a type signature, call pattern, or wrapper that appears in many places — or corrects a stated claim about what something does or guarantees, search every caller, reference, and restatement the change reaches, not only the changed files, by concept rather than by the literal just replaced: a stem that survives inflection and compounding, the shape common to every variant, or the claim itself in whatever words a comment, document, or instruction file restates it. A clean search proves nothing when its pattern was derived from a single instance, and the cited location is often only one of several references. When the finding names several sites, also tick them off against the finding text. Complete the sweep, bringing every site it finds in line with the fix, before marking the fix complete. 9. When the fix adds or edits a comment stating a contract — what is handled, what is excluded, what callers may rely on — verify the code enforces that contract before marking the fix complete. When it does not, add the enforcement rather than narrowing the comment.

If a finding references code that has changed since it was generated (e.g., by a prior fix in this same run), re-assess whether it still applies. Skip if the code has diverged.

When an escalated finding's outcome