BMAD-METHOD Deletion Check 解析：在代码审查中捕获删除回归的次级审查通道

• AI 技能
• 人工智能
• 开发工具

Deletion Check 是 BMAD-METHOD 开源仓库中bmad-build技能内置的代码审查机制，作为 Edge Case Hunter 审查透镜（review lens）的次级通道（secondary pass），专门在 diff 删除了有意义代码时运行。本文从该机制的定位、触发条件、判断标准、JSON 输出契约到与 Claims Check 的配合关系，结合仓库源码完整拆解其原理与实战用法，帮助读者理解并复现这套"删除即审查"的回归防线。

Deletion Check 在审查体系中的定位

Deletion Check 不是独立运行的审查器，而是 Edge Case Hunter 审查指令 中的Step 4。该指令将审查者定义为"纯路径追踪者（pure path tracer）"，核心方法论是"穷举路径枚举（exhaustive path enumeration）——机械地遍历每一条分支，而非凭直觉狩猎"。

Edge Case Hunter 的执行序列被强制固定：

1. Step 1：接收审查内容（diff、完整文件或函数），识别内容类型以确定作用域规则
2. Step 2：穷举路径分析——遍历所有分支路径与边界条件，仅报告未被处理（unhandled）的路径
3. Step 3：完整性验证——重新审视所有边缘类别（缺失 else/default、空输入、off-by-one、算术溢出、隐式类型转换、竞态、超时缺口等）
4. Step 4：Deletion Check——仅当 diff 删除了有意义代码时加载并执行
5. Step 5：Claims Check——对照规格文档中的意图与验收声明逐条证伪
6. Step 6：以单个 JSON 数组输出全部发现

从源码结构可以推断，这套"Step 4 + Step 5"的设计意图是形成互补的两道防线：Edge Case pass 盯着"新增/修改的代码缺了什么处理"，Deletion Check 盯着"被删掉的代码带走了什么"，Claims Check 则盯着"代码声称做到的事是否属实"。三者共享同一个输出数组与四个标准字段，便于后续统一分类（triage）。

触发条件：什么情况下才运行 Deletion Check

Deletion Check 指令 的第一句就划定了边界：

Secondary pass for the Edge Case Hunter — runs only when the diff removed meaningful code.

即它只在 diff 删除（或替换）了有意义代码时运行，并且明确排除两类"假删除"：

• 纯重命名（pure renames）：仅改名不改行为，不触发
• 空白改动（whitespace）：格式、缩进、换行等不携带语义，不触发

同时它的定位被明确标注为"从属于边缘用例通道（Subordinate to the edge-case pass）；发现通常很少或没有（findings are usually few or none）"。这意味着 Deletion Check 不是要放大审查噪音，而是在主通道之外补一个低成本、高针对性的检查：删除往往意味着信息丢失，而这种丢失恰恰是最容易被主通道忽略的。

核心判断标准：行为与契约的迁移审计

Deletion Check 对每一块被删除或替换的代码（排除重命名与空白后）提出一个核心问题：

did it carry behavior or a contract that the change neither re-established nor intentionally retired?

即：这段被删的代码是否携带了某种行为（behavior）或契约（contract），而本次改动既没有重新建立它，也没有有意地将其退役？

围绕这个问题，指令给出了三类需要产生发现（finding）的结果：

• 回归（regression）：删除导致原有功能失效或行为改变
• 孤立引用（orphaned reference）：删除后，仍有关联方引用被删的符号、字段、接口或状态
• 新死代码（newly-dead code）：删除后，某些代码成为永远不可达或永不生效的"尸体"

同时明确要求去重：跳过任何已被边缘用例发现覆盖的内容（Skip anything already covered by your edge-case findings）。这保证了主通道与次级通道的发现不重复计费，最终数组中的每条记录都有唯一价值。

输出契约：统一的 JSON 数组与字段语义重映射

Deletion Check 的发现追加（append）到与边缘用例发现相同的 JSON 数组中，在 Edge Case Hunter 定义的四个标准字段之上再附加两个字段。

四个标准字段在 Edge Case Hunter 输出格式 中定义：

• location：发现位置（file:start-end，单行为file:line，无法精确到行时为file:hunk）
• trigger_condition：触发条件，一句话描述（最多 15 词）
• guard_snippet：关闭缺口的最小代码草图（单行转义字符串，不含裸换行或未转义引号）
• potential_consequence：可能实际发生的后果（最多 15 词）

Deletion Check 附加的两个字段：

• kind：固定为"deletion"——用于区分同数组中的边缘用例发现与 Claims Check 的"claim"发现
• confidence：取"high"、"medium"或"low"——因为删除审查本质上是推断（inference），指令明确要求为其评级

对于删除类发现，四个标准字段被重映射为专门语义：

以下是一个遵循该契约构造的示例（字段语义据指令定义）：

[{ "location": "src/auth/validator.ts:12-18 (removed)", "trigger_condition": "Deleted pre-check rejected empty token before lookup", "guard_snippet": "if (!token) { return { error: 'empty token' }; }", "potential_consequence": "Empty token now reaches DB lookup, causing 500s", "kind": "deletion", "confidence": "high" }]

指令同时强调：如果没有符合条件的发现，就什么都不加（Add nothing if nothing qualifies）——被删除的代码若其行为已被重新建立或有意退役，则不产生发现，空数组[]是合法输出。

与 Claims Check 的配合：删除审查的"对偶"通道

Deletion Check 之后紧跟 Claims Check（Step 5），两者形成对偶关系：

• Deletion Check 审查"失去的"：删除的代码带走了什么行为或契约，改动方是否重新建立或有意退役
• Claims Check 审查"声称的"：规格文档中## Intent与## Tasks & Acceptance部分声明的可检查声明（做什么、保留什么、顺序、算术、与现有代码的对等性），逐条对照已追踪的代码尝试证伪

Claims Check 有严格的防污染设计：审查者直到 Step 5 才第一次读取 claims 文件（路径追踪在 Steps 2–3 必须完成，声明不能追溯性地影响路径分析），并且"规格是改动对自身的陈述：是证词，不是证据（testimony, not evidence）"——代码注释里重复的声明仍是同一声明，不算确认。

两个通道的发现都追加到同一 JSON 数组，分别以kind: "deletion"与kind: "claim"区分，且都遵循"无发现则不输出"的原则。这保证了审查器在 Step 6 输出时，数组中的每一条记录都对应一个真实、未重复、可被后续 triage 处理的问题。

发现的下游处理：Step 4 的分类路由

Deletion Check 产生的发现不会直接决定代码的去留，而是进入 bmad-build 的 Step 4 审查流程 的"分类（Classify）"阶段，经过三层处理：

1. 验证（Verify）：在引用位置确认审查者描述的坏结果是否真实发生，需沿调用链追查；对每条发现必须给出唯一裁决：high/medium/low（真实缺陷并定级）、false（检查后不成立并写出反证）、maybe-false（无法判定并写出所需证据）
2. 分组（Group）：仅当同一缺陷同时产生多条发现时才归入同一条目，位置相同或修复相同都不算共享根因
3. 路由（Route）：每条目进入恰好一个分类——intent_gap（意图捕获不完整）、bad_spec（规格缺陷）、patch（最小修复即解决）、defer（非本次改动引入的存量问题）

从该分类体系可以推断删除类发现的典型去向：若删除导致回归且最小修复直接、无新增公共面，则路由为patch；若规格本应阻止该删除却未做到，则路由为bad_spec触发回环（loopback）；若属改动前就存在的存量问题，则记入deferred-work.md延后处理。

运行环境与启用方式

Deletion Check 作为 bmad-build 技能的一部分，通过技能入口 bmad-build/SKILL.md 启动：

uv run --no-cache "{project-root}/_bmad/scripts/render_skill.py" --project-root "{project-root}" --skill "{skill-root}"

审查通道由workflow.review参数控制（none、quick、thorough，支持auto自动解析），完整执行序列见 workflow.md 与 step-04-review.md：只有走完整审查路径（非none）时才会铺开审查透镜，Edge Case Hunter 及其 Deletion Check 子通道才会被激活。技能元数据见 module-manifest.toml（当前版本 6.13.0-next）。

值得注意的是，该指令并非 bmad-build 独有：仓库中 bmad-build-auto/references/deletion-check.md 与 bmad-code-review/references/deletion-check.md 承载着完全相同的文本，说明 Deletion Check 是 BMAD-METHOD 审查体系中的标准化通用组件，被自动构建与独立代码审查两条路径复用。

实践要点小结

• 触发是条件性的：只有删除/替换了有意义代码才运行，纯重命名与空白改动直接跳过
• 核心问题是契约审计：被删代码是否携带未被重建或未被有意退役的行为/契约，关注回归、孤立引用、新死代码三类后果
• 与主通道去重：已由边缘用例覆盖的内容不重复报告
• 输出契约严格：追加到同一 JSON 数组，四个标准字段 +kind: "deletion"+confidence三档评级，字段语义按删除场景重映射
• 下游分类闭环：发现经验证、分组、路由进入intent_gap/bad_spec/patch/defer之一，由审查流程统一裁决
• 无发现即无输出：空数组[]合法，Deletion Check 不制造噪音

这套设计把"删除"从审查盲区变成显式检查点：行为与契约不会因为一行git diff中的减号而无声消失——要么被重新建立，要么被有意退役，要么被记录在案。

• AI 技能
• 人工智能
• 开发工具