Fix Review Verifier Workshop

Systematic fix verification framework for validating bug fixes, ensuring regression prevention, confirming root cause resolution, and verifying fix completeness before deployment to production.

When to Use This Skill

Choose Fix Review Verifier when:

• Verifying that a bug fix actually resolves the reported issue
• Checking for regressions introduced by the fix
• Validating that the root cause is addressed, not just symptoms
• Reviewing fix quality before production deployment
• Building verification checklists for different fix categories

Consider alternatives when:

• Need automated testing — use test framework tools
• Need code review — use code review workflow
• Need deployment verification — use deployment monitoring

Quick Start

Copy
# Activate fix verifier
claude skill activate advanced-fix-review-verifier-workshop

# Verify a fix
claude "Verify that PR #567 properly fixes the payment double-charge bug"

Example: Fix Verification Checklist

Copy
## Fix Verification: Payment Double-Charge (BUG-234)

### 1. Root Cause Confirmation
- [x] Root cause identified: Missing idempotency key in payment API call
- [x] Root cause matches the symptom (double charges on network retry)
- [x] Fix addresses root cause, not just symptoms
- [ ] No other code paths have the same vulnerability

### 2. Fix Completeness
- [x] Idempotency key added to createCharge() call
- [x] Idempotency key generated from order ID (deterministic)
- [x] Retry logic checks for existing charge before creating new one
- [x] Error handling for idempotency conflicts

### 3. Test Coverage
- [x] Unit test: createCharge sends idempotency key
- [x] Unit test: retry scenario doesn't create duplicate charge
- [x] Integration test: concurrent payment attempts for same order
- [x] Edge case: expired idempotency key (>24h)
- [ ] Load test: verify under concurrent traffic

### 4. Regression Check
- [x] All existing payment tests pass
- [x] Related refund flow still works correctly
- [x] Webhook handling unaffected
- [x] No performance degradation in payment path

### 5. Deployment Verification
- [ ] Deploy to staging, reproduce original scenario
- [ ] Verify fix in staging with test payments
- [ ] Deploy to production with monitoring
- [ ] Confirm zero duplicate charges for 24h post-deploy

Core Concepts

Verification Levels

Level	What to Check	How
Syntax	Fix compiles and passes lint	CI pipeline
Logic	Fix addresses the root cause correctly	Code review
Behavior	Fix resolves the reported symptom	Manual + automated testing
Regression	Fix doesn't break existing functionality	Full test suite
Edge Cases	Fix handles boundary conditions	Targeted test cases
Performance	Fix doesn't degrade performance	Benchmark comparison
Production	Fix works in production environment	Staged rollout + monitoring

Fix Quality Criteria

Criteria	Question	Pass/Fail
Root Cause	Does the fix address the root cause?	Required
Completeness	Are all affected code paths fixed?	Required
Test Coverage	Is there a test that would catch regression?	Required
Side Effects	Does the fix introduce new issues?	Required (none)
Simplicity	Is the fix the simplest correct solution?	Recommended
Documentation	Is the fix documented for future reference?	Recommended

Configuration

Parameter	Description	Default
verification_levels	Required verification levels	["logic", "behavior", "regression"]
require_test	Require regression test for fix	true
staging_verification	Require staging deployment	true
monitoring_period	Post-deploy monitoring duration	24h
rollback_plan	Require documented rollback plan	true

Best Practices

1. Verify the fix resolves the exact reported symptom — Reproduce the original bug, apply the fix, and confirm the symptom no longer occurs. Don't assume a code change fixes a bug just because it changes the relevant code path.

2. Check for the same bug pattern in other code paths — If a missing null check caused a bug in one endpoint, check all similar endpoints for the same pattern. The root cause often reveals a systematic issue, not an isolated mistake.

3. Require a failing-then-passing test for every bug fix — The test should fail without the fix and pass with it. This creates permanent regression protection and documents the exact behavior that was broken and how it should work.

4. Deploy fixes through staging before production — Even "obvious" one-line fixes can have unexpected effects in production. Deploy to staging first, reproduce the original issue, verify the fix, then promote to production with monitoring.

5. Monitor production metrics after deploying the fix — Set up alerts on related metrics (error rates, response times, business metrics) for 24-48 hours post-deploy. Some fixes introduce subtle issues that only appear under real traffic patterns.

Common Issues

Fix passes tests but the bug still occurs in production. The test doesn't accurately reproduce the production conditions. Check for differences in data, configuration, concurrent load, and timing. Add a test that more closely mirrors the production scenario.

Fix introduces a performance regression. The fix may add database queries, API calls, or computation on a hot path. Profile the affected code path before and after the fix. If performance degrades, optimize the fix or implement caching.

Same bug reappears months later after unrelated changes. The regression test was too narrow or too coupled to implementation details. Write behavior-based tests that verify the outcome, not the implementation. If the test passes but the bug returns, the test doesn't actually cover the bug.