Run a comprehensive 7-phase verification pipeline for .NET projects: build, analyzers, antipattern detection, tests, security, formatting, and diff review. Each phase produces PASS/FAIL with actionable output and the pipeline short-circuits on critical failures. Also the authority on verification st

/verify 7 Phase Verification Pipeline What Runs a sequential, 7 phase verification pipeline that catches issues at every level from compiler errors to subtle antipatterns to formatting drift. Each phase produces an explicit PASS, WARN, or FAIL with details. "It looks fine" is not a verification result; a table of statuses is. Critical failures (Phase 1 build, Phase 4 tests) short circuit the pipeline because later phases cannot produce meaningful results on broken code. The pipeline answers one question: "Is this code ready for review?" Phase Tool What It Catches Critical 1. Build dotnet build Compilation errors, missing references Yes 2. Diagnostics get diagnostics (MCP) New analyzer warnings, nullability issues FAIL on new errors 3. Antipatterns detect antipatterns (MCP) async void, sync over async, DateTime.Now , more No 4. Tests dotnet test Failing tests, regressions Yes 5. Security dotnet list package vulnerable + scan Secrets, SQL injection, missing auth, vulnerable packages FAIL on critical/high 6. Format dotnet format verify no changes Style drift, formatting inconsistencies No 7. Diff Review git diff analysis Accidental changes, debug leftovers, TODOs No When After completing a feature, bug fix, or major refactor Before creating a pull request non negotiable, full pipeline After merging upstream changes or updating dependencies When the user says "verify", "check everything", "is this ready", "run all checks" As the final step before marking a task complete Which Phases to Run Full pipeline is the default. For scoped changes, run a subset: Scenario Phases Notes Feature complete / Pre PR / new endpoint All 7 No shortcuts Bug fix 1, 2, 4 Add a test first if none covers it After refactor 1, 2, 3, 4 Correctness focus; add 5 7 if security sensitive Dependency update 1, 4, 5 Build, tests, vulnerability scan Config or test only change 1, 4 Build and test Formatting only 6 Format check is sufficient When in doubt, run all 7. Extra phases cost minutes; a missed security issue costs days of incident response. Never cherry pick phases because a change "looks safe". How Phase 1: Build (CRITICAL short circuits) If the build fails, STOP. Report errors and fix before continuing nothing downstream is meaningful on code that does not compile. Capture the warning count even on PASS; new warnings are tracked in Phase 2. Output: PASS (0 errors) or FAIL (with error list) Phase 2: Diagnostics Use the Roslyn MCP get diagnostics tool, scoped to changed files/projects (full solution for cross cutting changes). Compare against baseline flag only NEW warnings introduced by the current changes. Common findings: CS8600/CS8602 (nullability), CS0219 (unused variable). Output: PASS (0 new) / WARN (new warnings) / FAIL (new errors). Treat new warnings as work today's CS8600 is next month's production NullReferenceException. Phase 3: Antipattern Detection Use the Roslyn MCP detect antipatterns tool on changed files (full project for broad changes). Catches: async void , sync over async ( .Result , .GetAwaiter().GetResult() ), new HttpClient() , DateTime.Now / UtcNow instead of TimeProvider , broad catch (Exception) , string interpolation in logging, missing CancellationToken , EF read queries without AsNoTracking . Output: PASS (0 findings) / WARN (findings) / FAIL (critical antipatterns) Phase 4: Tests (CRITICAL short circuits) Full suite, or scoped to affected test projects for large solutions. Any failing test is a FAIL no exceptions. Stop and fix before later phases. If no test project exists: SKIP with a recommendation to add tests. Output: PASS (all green) or FAIL (failing test names + error messages) Phase 5: Security Scan Then review changed files for: hardcoded secrets/connection strings/API keys, SQL injection (raw SQL without parameterization), missing [Authorize] on endpoints that need it, permissive CORS, missing input validation, disabled HTTPS or certificate validation. Output: PASS / WARN (medium/low findings) / FAIL (critical/high vulnerabilities) Phase 6: Format Check Reports drift without auto fixing. To resolve, run dotnet format and include the changes in the commit. If no .editorconfig exists, note it as a recommendation. Output: PASS / WARN (with file list) Phase 7: Diff Review Analyze git diff stat and git diff (staged + unstaged) for: Accidental or unrelated file changes ( .vs/ , bin/ , obj/ , .env , secrets) Debug leftovers ( Console.WriteLine , if DEBUG in production paths) Unresolved TODO/HACK/FIXME markers Scope mismatch changes must match the task/PR description Output: PASS (clean, matches intent) / WARN (with findings) Fix and Retry Loop A single pass rarely produces all green. The loop is the point: 1. IDENTIFY which phase failed, and the specific error 2. FIX make the minimal change that resolves it 3. RE RUN from Phase 1 if the fix changed code; otherwise from the failed phase 4. REPEAT until all phases pass, or an issue needs user input Final Summary Verdicts: READY FOR REVIEW (all PASS, or only non blocking WARNs) or NEEDS FIXES (any FAIL, with specific remediation steps). For pre PR runs, include the verification report in the PR description. Example Related /build fix Auto fix build errors when Phase 1 fails /code review Multi dimensional review once verification passes /health check Whole project graded assessment (beyond this change set)