Back to Details

verify

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/verify -- 7-Phase Verification Pipeline

/verify -- 七阶段验证流水线

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?"
PhaseToolWhat It CatchesCritical
1. Build
dotnet build
Compilation errors, missing referencesYes
2. Diagnostics
get_diagnostics
(MCP)		New analyzer warnings, nullability issuesFAIL on new errors
3. Antipatterns
detect_antipatterns
(MCP)		async void, sync-over-async, 
DateTime.Now
, more		No
4. Tests
dotnet test
Failing tests, regressionsYes
5. Security
dotnet list package --vulnerable
+ scan		Secrets, SQL injection, missing auth, vulnerable packagesFAIL on critical/high
6. Format
dotnet format --verify-no-changes
Style drift, formatting inconsistenciesNo
7. Diff Review
git diff
analysis		Accidental changes, debug leftovers, TODOsNo
运行一套按顺序执行的七阶段验证流水线，能够从编译器错误到细微的反模式，再到格式偏差等各个层面发现问题。每个阶段都会生成明确的PASS、WARN或FAIL结果及详细信息。“看起来没问题”不是有效的验证结果，验证结果必须是一份状态表格。关键失败（第1阶段构建、第4阶段测试）会中断流水线，因为损坏的代码无法让后续阶段产生有意义的结果。
流水线旨在回答一个核心问题：“这段代码是否已准备好接受评审？”
阶段工具检测内容是否为关键阶段
1. 构建
dotnet build
编译错误、缺失引用是
2. 诊断
get_diagnostics
(MCP)		新增的分析器警告、可空性问题出现新错误时标记为FAIL
3. 反模式检测
detect_antipatterns
(MCP)		async void、同步覆盖异步、
DateTime.Now
等		否
4. 测试
dotnet test
测试失败、功能退化是
5. 安全检查
dotnet list package --vulnerable
+ 扫描		密钥泄露、SQL注入、缺失认证、存在漏洞的包出现严重/高危问题时标记为FAIL
6. 格式校验
dotnet format --verify-no-changes
代码风格偏差、格式不一致否
7. 差异审查
git diff
分析		意外变更、调试残留代码、TODO标记否

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
  • 完成功能开发、Bug修复或重大代码重构之后
  • 创建拉取请求（PR）之前——必须运行完整流水线
  • 合并上游变更或更新依赖之后
  • 用户提及“verify”、“check everything”、“is this ready”、“run all checks”时
  • 标记任务完成前的最终步骤

Which Phases to Run

应运行哪些阶段

Full pipeline is the default. For scoped changes, run a subset:
ScenarioPhasesNotes
Feature complete / Pre-PR / new endpointAll 7No shortcuts
Bug fix1, 2, 4Add a test first if none covers it
After refactor1, 2, 3, 4Correctness focus; add 5-7 if security-sensitive
Dependency update1, 4, 5Build, tests, vulnerability scan
Config or test-only change1, 4Build and test
Formatting only6Format 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".
默认运行完整流水线。针对范围有限的变更，可运行子集：
场景阶段说明
功能开发完成 / 预PR / 新增接口全部7个阶段不可省略任何步骤
Bug修复1、2、4若现有测试未覆盖该Bug，需先添加测试
重构之后1、2、3、4重点关注正确性；若涉及敏感安全内容，需添加5-7阶段
依赖更新1、4、5构建、测试、漏洞扫描
仅配置或测试变更1、4构建和测试即可
仅格式调整6仅需格式校验
若不确定，建议运行全部7个阶段。额外阶段仅需数分钟，但遗漏安全问题可能导致数天的事件响应工作。切勿因“看起来安全”而随意挑选阶段。

How

执行方式

Phase 1: Build (CRITICAL -- short-circuits)

阶段1：构建（关键阶段——失败则中断流水线）

bash
dotnet build --no-restore --verbosity quiet
  • 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)
bash
dotnet build --no-restore --verbosity quiet
  • 若构建失败，立即停止。报告错误并修复后再继续——无法编译的代码无法让下游阶段产生有意义的结果。
  • 即使构建通过，也要捕获警告数量；新增警告会在阶段2中被追踪。
  • 输出结果：PASS（0错误）或FAIL（附带错误列表）

Phase 2: Diagnostics

阶段2：诊断检测

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.
使用Roslyn MCP的
get_diagnostics
工具，针对变更的文件/项目（跨领域变更则针对整个解决方案）。与基线对比——仅标记当前变更引入的新警告。常见问题：CS8600/CS8602（可空性）、CS0219（未使用变量）。
输出结果：PASS（无新问题）/ WARN（存在新警告）/ FAIL（存在新错误）。将新警告视为待处理任务——今天的CS8600可能就是下个月生产环境中的NullReferenceException。

Phase 3: Antipattern Detection

阶段3：反模式检测

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)
对变更的文件（大范围变更则针对整个项目）使用Roslyn MCP的
detect_antipatterns
工具。可检测：
async void
、同步覆盖异步（
.Result
、
.GetAwaiter().GetResult()
）、
new HttpClient()
、使用
DateTime.Now
/
UtcNow
而非
TimeProvider
、宽泛的
catch (Exception)
、日志中的字符串插值、缺失
CancellationToken
、EF查询未使用
AsNoTracking
等。
输出结果：PASS（无发现）/ WARN（存在问题）/ FAIL（存在严重反模式）

Phase 4: Tests (CRITICAL -- short-circuits)

阶段4：测试（关键阶段——失败则中断流水线）

bash
dotnet test --no-build --verbosity quiet
  • 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)
bash
dotnet test --no-build --verbosity quiet
  • 运行完整测试套件，大型解决方案可针对受影响的测试项目运行。
  • 任何测试失败均标记为FAIL——无例外情况。停止并修复后再进入后续阶段。
  • 若不存在测试项目：标记为SKIP，并建议添加测试。
输出结果：PASS（全部通过）或FAIL（失败测试名称 + 错误信息）

Phase 5: Security Scan

阶段5：安全扫描

bash
dotnet list package --vulnerable --include-transitive
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)
bash
dotnet list package --vulnerable --include-transitive
随后检查变更文件是否存在：硬编码密钥/连接字符串/API密钥、SQL注入（未参数化的原生SQL）、需要认证的接口缺失
[Authorize]
标记、宽松的CORS配置、缺失输入验证、HTTPS或证书验证被禁用等问题。
输出结果：PASS / WARN（中/低危问题）/ FAIL（严重/高危漏洞）

Phase 6: Format Check

阶段6：格式校验

bash
dotnet format --verify-no-changes --verbosity quiet
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)
bash
dotnet format --verify-no-changes --verbosity quiet
报告格式偏差但不自动修复。如需解决，运行
dotnet format
并将变更纳入提交。若不存在
.editorconfig
文件，需记录为改进建议。
输出结果：PASS / WARN（附带文件列表）

Phase 7: Diff Review

阶段7：差异审查

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)
分析
git diff --stat
和
git diff
（已暂存 + 未暂存）内容，检查：
  • 意外或无关文件变更（
    .vs/
    、
    bin/
    、
    obj/
    、
    .env
    、密钥文件）
  • 调试残留代码（
    Console.WriteLine
    、生产路径中的
    #if DEBUG
    ）
  • 未解决的TODO/HACK/FIXME标记
  • 范围不匹配——变更内容必须与任务/PR描述一致
输出结果：PASS（干净且符合预期）/ WARN（存在问题）

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
单次运行很少能全绿通过，循环迭代才是关键：
  1. 识别——哪个阶段失败，具体错误是什么
  2. 修复——做出最小化的变更以解决问题
  3. 重新运行——若修改了代码则从阶段1开始；否则从失败阶段开始
  4. 重复——直到所有阶段通过，或需要用户输入处理问题

Final Summary

最终总结

undefined
undefined

Verification Results

验证结果

PhaseResultDetails
1. BuildPASS0 errors, 0 warnings
2. DiagnosticsPASS0 new diagnostics
3. AntipatternsWARN1 missing CancellationToken
4. TestsPASS47 passed, 0 failed
5. SecurityPASSNo findings
6. FormatPASSClean
7. Diff ReviewWARN1 TODO marker found
Verdict: READY FOR REVIEW (with 2 non-blocking warnings)

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.
阶段结果详情
1. 构建PASS0错误，0警告
2. 诊断PASS0新增诊断问题
3. 反模式检测WARN1处缺失CancellationToken
4. 测试PASS47通过，0失败
5. 安全检查PASS无问题
6. 格式校验PASS格式规范
7. 差异审查WARN发现1个TODO标记
结论：已准备好接受评审（存在2个非阻塞警告）

结论分为两种：**已准备好接受评审**（全部通过，或仅存在非阻塞警告）或**需修复问题**（存在任何失败，附带具体修复步骤）。预PR运行时，需将验证报告纳入PR描述中。

Example

示例

User: /verify

Claude: Running 7-phase verification pipeline...

Phase 1: Build ............ PASS (0 errors)
Phase 2: Diagnostics ...... PASS (0 new warnings)
Phase 3: Antipatterns ..... WARN
  - src/Features/Orders/CreateOrder.cs:42 -- DateTime.Now usage, use TimeProvider
Phase 4: Tests ............ PASS (23 passed, 0 failed, 0 skipped)
Phase 5: Security ......... PASS
Phase 6: Format ........... PASS
Phase 7: Diff Review ...... PASS

Verdict: READY FOR REVIEW (1 non-blocking warning)

Recommendation: Replace DateTime.Now with TimeProvider on line 42 before
merging. Not blocking, but it will fail the antipattern check in CI.
用户: /verify

Claude: 正在运行七阶段验证流水线...

阶段1：构建 ............ PASS（0错误）
阶段2：诊断检测 ...... PASS（0新增警告）
阶段3：反模式检测 ..... WARN
  - src/Features/Orders/CreateOrder.cs:42 -- 使用了DateTime.Now，建议改用TimeProvider
阶段4：测试 ............ PASS（23通过，0失败，0跳过）
阶段5：安全检查 ......... PASS
阶段6：格式校验 ........... PASS
阶段7：差异审查 ...... PASS

结论：已准备好接受评审（存在1个非阻塞警告）

建议：合并前将第42行的DateTime.Now替换为TimeProvider。该问题不会阻塞PR，但会在CI中触发反模式检测失败。

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)
  • /build-fix
    -- 当阶段1构建失败时自动修复构建错误
  • /code-review
    -- 验证通过后进行多维度代码评审
  • /health-check
    -- 针对整个项目的分级评估（超出当前变更范围）