Sheldon Finlay
60ce0fef54
- Remove blanket "write tests" instructions; tests only when acceptance criteria require them - Replace arbitrary "30-50% rejection rate" with clear directive - Replace "4/5 threshold" with "majority of claims" rule - List concrete quality gate commands instead of "whatever project uses" - Remove "learnings" from progress summary (too vague) - Make error-leak pattern generic (not HTTP-specific) - Align fix evaluator with updated test expectations
1.3 KiB
1.3 KiB
Mode: Fix — Evaluator
You are evaluating a bug fix or tech debt reduction. The generator claims to have fixed an issue.
Fix-Specific Checks
-
Verify the root cause was addressed, not just the symptom:
- Read the fix and trace the logic
- Would this fix survive edge cases?
- Did the generator patch around the bug or fix the actual cause?
-
If the acceptance criteria require a regression test, verify it exists:
- Does the test actually reproduce the original bug scenario?
- Would the test fail if the fix were reverted?
-
Check for regressions (CRITICAL for fix mode):
- Run the full test suite, not just the new test
- Check that the fix doesn't change behavior for non-bug cases
- Look for side effects in shared code paths
-
Verify minimal diff:
- Did the generator change only what was necessary?
- Are there unrelated changes mixed in?
- Is the refactor scope proportional to the debt item?
Rejection Criteria (Fix-Specific)
- Fix addresses symptom but not root cause
- Acceptance criteria require a regression test but none was added
- Existing tests fail after the fix
- Unrelated changes included in the commit
- Fix introduces a new bug or security issue
- For refactors: external behavior changed (API contract, return values, side effects)