Applies to "fix this high-risk issue and confirm" or "review and fix." A bare "just review" only allows reporting and does not authorize modifications. Before starting, check the fix scope specified by the user, other uncommitted changes, and the current candidate state.
When to use and capability boundaries
Use only when the user explicitly requests fixing review findings; when only review is requested, hand it over to finding verification and do not change code. If core requirements need to be modified, data migrated, or the fix scope expanded, first show the impact and obtain direction.
Workflow / Workflow
Step 1 — Verify the issue and authorization
Accept only verified issues or hypotheses explicitly selected by the user for verification; if evidence is insufficient, first hand it over to codereview-finding-triage. Review authorization does not include modification, dependency installation, external model sending, committing, or pushing.
Step 2 — Reproduce and fix
First write or update a test that can reproduce the target behavior, and confirm that it fails because of the target issue; when automated testing is not possible, record manual verification steps. Make the minimal fix, protect the user's existing changes, and do not rewrite unrelated code or suppress rules.
Step 3 — Verify and re-review
Run the target test and affected regressions, and retain commands, exit codes, and failures. Content changes invalidate the original OCR report/plugin fingerprint; manual review should rerun the same target, and the plugin candidate submission should re- prepare and review, and old proceed。
Step 4 — Deliver item by item
Compare the original issue with the new results, and report "fixed/still present/unverified," newly introduced risks, and uncovered tests; do not automatically commit/push.
Check Fix loop example handles partially staged and model-suggested code. The output "fix complete" only means the tested behavior is consistent with the current candidate; it does not represent final project acceptance.
Stop conditions
- The user only requests review and there is no fix authorization: stop at suggestions.
- The fix would touch unknown data migration, external API contracts, or a large number of non-target files: first explain the impact and request direction.
- The test environment is missing or the new review fails: make it explicit
UNVERIFIED, retain the changes and failure evidence, and do not claim closure.
Gotchas / Common pitfalls
- When the fix is only in the workspace and has not entered the staging area, the old plugin report still cannot prove that the new candidate has been fixed.
- Model-suggested code may break other callers; first verify types, exceptions, and concurrency paths.
- Passing tests does not equal passing re-review; record the two kinds of evidence separately.
- The user requesting a fix for one finding does not mean authorization to conveniently modify all similar files.