Verification Loop

## Verification Report

| Phase | Status | Details |
|-------|--------|---------|
| 1. Build | PASS | 0 errors, 2 warnings (pre-existing) |
| 2. Diagnostics | WARN | CS8600 in OrderService.cs:47 — possible null reference |
| 3. Anti-patterns | PASS | 0 anti-patterns in changed files |
| 4. Tests | PASS | 42 passed, 0 failed, 0 skipped |
| 5. Security | PASS | No vulnerable packages, no secrets detected |
| 6. Format | PASS | No formatting violations |
| 7. Diff Review | PASS | 3 files changed, all match task scope |

**Overall: PASS (with warnings)**

### Action Items
- [ ] Fix CS8600 in OrderService.cs:47 — add null check or use null-forgiving operator with justification

1. IDENTIFY — Which phase failed? What's the specific error?
2. FIX — Make the minimal change to resolve the issue
3. RE-RUN — Start from the failed phase (not from Phase 1, unless the fix changed code)
   Exception: If the fix involved code changes, re-run from Phase 1 (build)
4. REPEAT — Until all phases pass or you've identified an issue that needs user input

EXAMPLE:
Phase 4 fails: OrderServiceTests.CreateOrder_ReturnsCreated fails with 404
  → Fix: Route was "/orders" but test expected "/api/orders"
  → Re-run from Phase 1 (code changed) → Build PASS → Phase 4 PASS
  → Continue Phase 5, 6, 7

PRE-PR CHECKLIST:
1. All 7 phases PASS (warnings acceptable only if pre-existing)
2. No new warnings introduced
3. All new code has corresponding tests
4. Diff review confirms changes match the PR description
5. No TODO comments left unresolved (or tracked in issues)

Only after all 7 phases pass:
→ Create the PR with the verification report as part of the PR description

QUICK VERIFICATION (3 phases):
Phase 1: dotnet build
Phase 4: dotnet test
Phase 6: dotnet format --verify-no-changes

Use when:
- Single-line bug fix with existing test coverage
- Configuration change
- Documentation-only change
- Dependency version bump (also add Phase 5 for security)

POST-REFACTOR VERIFICATION (4 phases):
Phase 1: dotnet build — refactors often break compilation
Phase 2: get_diagnostics — refactors often introduce new warnings
Phase 3: detect_antipatterns — refactors can accidentally introduce anti-patterns
Phase 4: dotnet test — the ultimate refactor validation

Skip Phase 5-7 unless the refactor touches security-sensitive code or public APIs.

# BAD — "it compiles in my head"
"I've made the changes. The code looks correct. Let me create the PR."
# No build run, no tests, no diagnostics — hope-driven development

# GOOD — verify before declaring done
"Let me run the verification pipeline before we create the PR."
→ Phase 1: Build PASS → Phase 2: Diagnostics PASS → ... → Phase 7: PASS
"All 7 phases passed. Creating the PR now."

# BAD — wasting time on downstream checks
Phase 1: Build FAIL (3 errors)
Phase 2: Running diagnostics anyway...
Phase 3: Running anti-pattern scan...
Phase 4: Running tests... (they'll fail because build failed)

# GOOD — short-circuit and fix
Phase 1: Build FAIL (3 errors)
→ STOP. Fix the 3 build errors first.
→ Re-run from Phase 1.

# BAD — "warnings are just suggestions"
Phase 2: 12 new CS8600 warnings introduced
"These are just warnings, not errors. Moving on."
# Three weeks later: NullReferenceException in production

# GOOD — treat new warnings as failures
Phase 2: 12 new CS8600 warnings introduced
"12 new nullability warnings detected. Fixing before proceeding."
→ Add null checks or non-nullable assertions with justification
→ Re-run Phase 2: 0 new warnings. PASS.

# BAD — reading code instead of running tools
"Let me read through OrderService.cs... looks good to me."
# Missed: DateTime.Now on line 23, async void on line 67, CS8600 on line 91

# GOOD — tools first, then human judgment
→ detect_antipatterns: Found DateTime.Now (line 23), async void (line 67)
→ get_diagnostics: CS8600 on line 91
"Found 3 issues via automated analysis. Fixing all three before manual review."

# BAD — only running the phases you think are relevant
"It's just a service change, I'll skip the security scan."
# The service change added a raw SQL query with string concatenation

# GOOD — full pipeline for non-trivial changes
When in doubt, run all 7 phases. The cost of running extra phases is minutes.
The cost of missing a security issue is days of incident response.