apply-findings

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. When the finding carries a suggested fix, treat the fix as a separate claim from the finding and verify it independently before applying it — trace it against the failure modes the finding names. When the fix encodes, escapes, quotes, or otherwise sanitizes untrusted input, enumerate the character classes the target interpreter treats specially and name the construct in the fix that blocks each one; a class with no blocker means the fix is incomplete, including when it reproduces the finding's suggested wording. If the 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.
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, apply it normally. 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. Make the fix
7. If the finding renames an identifier or changes a recurring shape — a type signature, call pattern, or wrapper that appears in many places — search every caller and reference the change reaches, not only the changed files, by concept rather than by the literal just replaced: a stem that survives inflection and compounding, or the shape common to every variant. 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 before marking the fix complete.
8. 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.