Review Should Auto-Fix Findings Before Asking

Context

During SPEC-022 deployment, /vt-c-4-review returned GO WITH CAUTION with 3 medium findings. One (PR-01: multi-version changelog extraction) was fixable code. The workflow paused to ask whether to fix or proceed — adding friction to an otherwise automatable step.

This pattern has repeated across multiple specs: review finds issues, asks user, user says fix, fix is applied, review re-runs. The human decision point adds no value when the fix is straightforward.

Decision

Create intake proposal for a review-autofix loop: - After /vt-c-4-review identifies findings, automatically attempt to fix fixable findings (code changes, not architectural decisions) - Limit to 2 retry attempts to prevent infinite loops - Only prompt the user if fixes fail or findings are non-automatable - Goal: /vt-c-4-review returns a clean PASS more often, reducing round-trips

Rationale

• Most medium findings from code-simplicity-reviewer and pattern-recognition-specialist are mechanically fixable
• The "ask before fixing" pattern wastes context window and user attention
• A 2-attempt cap prevents runaway loops while allowing iterative improvement
• Non-automatable findings (architectural, theoretical races) still surface to the user