verify-fix

Verify Fix Command

Core principle: A fix isn't fixed until you've seen it work.

• /verify-fix - Verify the most recent fix (infer from context)
• /verify-fix "login redirect works" - Verify specific behavior
• /verify-fix auth tests - Run auth-related tests

Tests exist: Run the relevant test file or test suite.

# TypeScript/JavaScript
pnpm test path/to/affected.test.ts
npm test -- --testPathPattern="ComponentName"
vitest run src/component.test.tsx

# Python
pytest path/to/test_module.py -v

# Go
go test ./pkg/... -run TestAffectedFunction

UI changes: Start dev server and verify visually or fetch the page.

# Verify page loads correctly
curl -s http://localhost:3000/affected-page | head -20

# Or use MCP Playwright tools for visual verification
mcp__plugin_playwright_playwright__browser_navigate to affected URL
mcp__plugin_playwright_playwright__browser_snapshot to capture state

API changes: Hit the endpoint and check the response.

curl -X POST http://localhost:3000/api/endpoint \
  -H "Content-Type: application/json" \
  -d '{"test": "data"}'

Config changes: Verify the config loads without error.

node -e "require('./config')"
python -c "from config import settings; print(settings)"

Build/compile: Verify the build succeeds.

pnpm build
npm run build
go build ./...

✓ Verified: [what was tested]
  Ran: [command]
  Result: [specific outcome - N tests passed, page loads, response correct]
  Evidence: [URL, test output, or response snippet]

Fix confirmed: [specific claim about what's now working]

On failed verification:

✗ Verification failed
  Ran: [command]
  Result: [what happened]
  Error: [specific error message or unexpected behavior]

The fix is NOT confirmed. [Next action: investigating X / trying Y / need more info]

After successful verification, use confident language:

• "Verified: the login redirect now works correctly"
• "Fix confirmed: tests pass and the page loads"

Claim success only with specific evidence. Epistemic honesty preserves trust.

If verification fails, continue debugging rather than reporting success.

• Tests pass that directly exercise the changed code paths
• Live request returns the expected response through the modified code
• UI renders correctly when displaying the fixed functionality
• Build completes without errors affecting the changed files
• The specific broken behavior is now demonstrably working

The standard: observe the fix working through code paths that exercise it. A passing test suite verifies the fix when those tests cover the changed behavior.

• Document what verification is needed in your response
• Explain to the user what they should verify manually
• Be explicit that the fix is unverified pending these checks