BMAD-METHOD Deletion Check 全解析在 AI 驱动的代码审查中捕获删除回归与死代码【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD本篇技术指南聚焦 BMAD-METHOD 项目中 Edge Case Hunter 审查器Edge Case Hunter的辅助检查通道——Deletion Check删除检查见 deletion-check.md。它回答一个在 AI 生成代码场景下极易被忽视的问题diff 中删掉的代码是否带走了它原本承载的行为或契约读完本文你将掌握 Deletion Check 的触发条件、判定规则、JSON 输出字段语义以及它如何在 BMAD 的无人工审查流水线中被自动调度和执行并能在自己的代码审查流程中复刻这套删除回归检测方法。Deletion Check 在 BMAD 审查体系中的定位BMAD-METHODBreakthrough Method for Agile AI Driven Development为 Agent 驱动的开发提供了一套完整的模块化技能skill体系其中代码审查由独立审查器review lens负责。在 bmad-build-auto无人值守的一次开发迭代和 bmad-code-review按需代码审查等技能中都定义了同一个核心审查器——Edge Case Hunter。Edge Case Hunter 是一个纯路径追踪器pure path tracer它不评判代码好坏只枚举 diff 或给定内容中缺少处理的路径与边界条件。其执行流程严格分为六步接收内容diff / 完整文件 / 函数穷举路径分析遍历控制流与领域边界完整性校验复查第 2 步的边界类别Deletion Check删除检查——diff 删除了代码时运行Claims Check声明检查——见 claims-check.md输出全部 findings 为单个 JSON 数组Deletion Check 正是第 4 步。原文档 deletion-check.md 开宗明义地定义了它的地位Secondary pass for the Edge Case Hunter — runs only when the diff removed meaningful code. Subordinate to the edge-case pass; findings are usually few or none.即它是 Edge Case Hunter 的辅助通道secondary pass仅在 diff 删除了有意义代码时运行从属于第 2 步的主 edge-case 通道由于主通道已经覆盖了大量路径缺失问题删除检查通常只产出很少甚至零条 findings。触发条件什么算删除了有意义代码Deletion Check 的第一道门槛是判断 diff 是否删除了meaningful code。判定规则包含两个明确排除项和两个明确纳入项忽略不触发纯重命名pure renames——只改名不改行为纯空白/格式调整whitespace——不改变任何语义。纳入触发被删除的代码块removed code、被替换的代码块replaced code——替换本质上是删除旧实现 新增新实现因此同样需要检查旧实现是否带走了不该丢失的东西。从执行链看这一门槛由 edge-case-hunter.md 的第 4 步显式表达If the diff removed or replaced meaningful code (ignore pure renames and whitespace): loadreferences/deletion-check.mdand follow it.也就是说不是每个 diff 都会触发删除检查。如果这次变更只新增代码、或只做重命名与排版第 4 步直接跳过只有存在真实删除/替换时才加载并遵循 deletion-check.md 的指令。这一条件式加载的设计保证了辅助通道只在其能贡献价值的场景消耗推理预算。核心判定问题删除的代码是否带走了行为或契约一旦确认存在有意义的删除/替换Deletion Check 对每一块被删除或被替换的代码执行同一个核心判定原文逐字要求For each chunk of removed or replaced code (ignore pure renames and whitespace), ask: did it carry behavior or a contract that the change neither re-established nor intentionally retired?拆解这个判定它实际上是三个子问题的合取它承载了什么carry behavior or a contract——被删代码是否强制了某种行为behavior例如输入校验、边界裁剪、状态转换、错误处理、资源释放或者某种契约contract例如对外 API 的语义、调用约定、返回值约束、前置/后置条件。变更是否重建了它re-established——新代码是否在别处以等价方式恢复了该行为或契约。若已重建删除无害。变更是否有意废弃了它intentionally retired——删除是否是有明确意图的需求变更例如产品决定废弃某功能而非重构过程中的误伤。若是有意废弃删除合法。只有当第 1 问为是、且第 2 问和第 3 问都为否时这次删除才构成问题需要产出一条 finding。判定通过后文档要求针对三种典型后果之一添加 findingregression回归被删行为/契约未被重建导致原有功能退化orphaned reference孤立引用删除了定义但留有引用或删除了唯一调用方却留下了无人再用的定义newly-dead code新产生的死代码删除后其他代码变成永不执行/永不引用的状态。同时有一个重要的去重规则Skip anything already covered by your edge-case findings.——如果某个删除问题已经被第 2 步的穷举路径分析捕获删除检查必须跳过避免同一问题重复上报。输出字段标准四字段 kind confidenceDeletion Check 的 findings追加到与 edge-case findings 相同的 JSON 数组中不是单独输出每个对象在标准四字段之外多出两个字段字段值说明kinddeletion标记这是删除检查产出区别于主 edge-case finding 与第 5 步的claimfindingconfidencehigh/medium/low置信度。文档明确提示删除检查的结论本质上是推断inferences必须显式评级location被删除的项四标准字段之一此处语义重载为被删除的东西trigger_condition它强制的行为或契约四标准字段之一即核心判定中的第 1 问答案guard_snippet在哪里或如何重建它四标准字段之一给出恢复该行为/契约的位置或最小代码形态potential_consequence回归或孤立四标准字段之一对应 regression / orphaned reference / newly-dead codelocation、trigger_condition、guard_snippet、potential_consequence四个标准字段的通用输出格式由 edge-case-hunter.md 的 OUTPUT FORMAT 定义location形如file:start-endtrigger_condition与potential_consequence均限 15 词以内guard_snippet为单行转义字符串Deletion Check 文档则进一步明确了这四个字段在删除场景下的专属语义映射。结合字段语义一次删除检查产出的一条典型 finding 可以表达为[ { kind: deletion, confidence: high, location: src/auth.py:88-95 (removed), trigger_condition: Input validation rejected empty tokens, guard_snippet: if not token: raise InvalidToken() before lookup, potential_consequence: Empty token now reaches upstream; auth bypass } ]以上为按字段语义构造的示意真实审查以实际 diff 为准。需要注意trigger_condition与potential_consequence的 15 词上限沿用主通道的输出约束避免 findings 变得冗长而难以被分诊triage程序消费。输出纪律无符合条件者不产出Deletion Check 有一条硬性的输出纪律也是全文最后一句Add nothing if nothing qualifies.两条对应的零产出路径分别是无删除/替换第 4 步根本不会加载本文件触发条件不满足有删除但无问题所有删除要么被重建、要么被有意废弃、要么已被 edge-case findings 覆盖则不添加任何 finding。这与 claims-check.md 的纪律Verified claims produce nothing. Add nothing if nothing is falsified.一脉相承审查器只上报经得起验证的问题宁可空数组[]也不为凑数而虚构缺陷。这也是两个辅助通道在方法论上的一致性设计——主通道穷举路径、辅助通道各管一类特殊风险三者最终合并为一个 JSON 数组见 edge-case-hunter 第 6 步Output all findings as a single JSON array。在无人值守工作流中的调度链Deletion Check 的价值在 BMAD 的自动化构建流程中体现得最充分。从 bmad-build-auto 的入口开始完整调用链如下入口用户调用bmad-build-auto经 SKILL.md 渲染 workflow.md按顺序执行 step 文件。审查阶段step-04-review.md 先将自{baseline_revision}以来的变更统一导出为 diff 文件{diff_file}不git add任何内容并把 spec 文件作为{claims_file}交付给审查镜头。镜头选择审查级别由 customize.toml 中的workflow.review与route决定——oneshot路由默认quickQuick 镜头full路由默认thorough。thorough 集包含四个镜头blind-hunter、edge-case-hunter、verification-gap、intent-alignment。镜头加载edge-case-hunter镜头id 见 customize.toml 中[[workflow.thorough_lenses]]的edge-case-hunter条目启动一个无上下文的子代理指令是完整阅读并遵循 review-prompts/edge-case-hunter.md。辅助通道触发Edge Case Hunter 在第 4 步按 diff 是否含删除/替换条件式加载references/deletion-check.md 并执行删除检查。因此Deletion Check 并不是一个独立可调用的命令而是审查镜头运行期的一段条件逻辑——它依附于 Edge Case Hunter 的执行上下文已追踪的 diff、已枚举的路径并共享其输出通道合并进同一个 JSON 数组。这种条件式参考文件加载conditional reference loading是 BMAD 技能体系的典型模式把长指令拆成按需加载的片段只在需要时进入上下文从而控制子代理的上下文占用。另外值得注意的是同一个 Edge Case Hunter 角色在三个技能中并存bmad-build-auto、bmad-build 与 bmad-code-review 均包含相同的第 4 步删除检查指令且三个技能都配套了相同的 deletion-check.md 与 claims-check.md 参考文件。这意味着无论你走哪条审查入口自动构建的 thorough 审查、手动按需代码审查删除检查的逻辑保持一致。与 Claims Check 的协同先追踪后看自述Deletion Check 与第 5 步的 Claims Check 是一对互补的辅助通道且存在严格的时序约束Deletion Check 检查的是代码删除带走的隐性契约代码做了什么、现在不做了什么Claims Check 检查的是变更自述spec / commit message中的显性声明代码声称做了什么是否被实现证伪。更关键的是读取顺序Edge Case Hunter 的输入中claims_filespec 文件必须在第 23 步路径追踪完成之后、第 5 步才允许读取——the path tracing is finished and the claims cannot steer it retroactively路径追踪已完成声明无法事后影响它。这一设计防止先读 spec、再顺着 spec 找证据的确认偏差保证主通道的路径枚举纯粹基于代码本身。Deletion Check 遵循同样的精神它对删除的评估基于已追踪的代码事实而非变更者声称的意图。二者协同后的产出被 step-04-review.md 的 Classify 阶段逐条验证、判定high/medium/low/false/maybe-false、分组并按intent_gap/bad_spec/patch/defer路由最终写入 spec 文件的## Review Triage Log。实战要点与落地建议将 Deletion Check 的方法论迁移到自己的代码审查流程无论人工还是 Agent 驱动时值得固化的几个要点先过滤噪音再检查删除检查只对改变行为的删除负责重命名、空白、格式化一律跳过避免审查者在重构型 diff 上浪费时间。用契约视角审视删除对每一处删除/替换主动追问三个问题——它原本强制了什么行为/契约新代码是否等价重建删除是否是有意为之三问缺一不可。警惕三类典型后果回归行为丢失、孤立引用定义与引用失联、新死代码删除引发连锁失效并在 finding 中明确对应到potential_consequence。与主通道去重删除问题若已被路径枚举覆盖不重复上报保持 finding 集合的干净与可分诊。显式标注推断置信度删除结论属于推断必须用confidence三档评级——有代码证据链支撑的高置信仅靠推测的低置信让后续 triage 能按置信度分配验证资源。宁缺毋滥Add nothing if nothing qualifies——无符合条件者输出空数组保持审查输出的信噪比。在 BMAD 的语境中这套检查尤其针对 AI 生成代码的一个典型缺陷模式LLM 在重构时会悄悄删掉它没看懂的防御性逻辑、边界处理或隐性契约。Deletion Check 以机械化的问题模板did it carry behavior or a contract...对冲这种倾向与穷举路径枚举的主通道、证伪声明的 Claims Check 共同构成三道防线让删除类回归在进入 step-04-review.md 的分诊与补丁循环之前就被系统化地暴露出来。【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
BMAD-METHOD Deletion Check 全解析在 AI 驱动的代码审查中捕获删除回归与死代码【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD本篇技术指南聚焦 BMAD-METHOD 项目中 Edge Case Hunter 审查器Edge Case Hunter的辅助检查通道——Deletion Check删除检查见 deletion-check.md。它回答一个在 AI 生成代码场景下极易被忽视的问题diff 中删掉的代码是否带走了它原本承载的行为或契约读完本文你将掌握 Deletion Check 的触发条件、判定规则、JSON 输出字段语义以及它如何在 BMAD 的无人工审查流水线中被自动调度和执行并能在自己的代码审查流程中复刻这套删除回归检测方法。Deletion Check 在 BMAD 审查体系中的定位BMAD-METHODBreakthrough Method for Agile AI Driven Development为 Agent 驱动的开发提供了一套完整的模块化技能skill体系其中代码审查由独立审查器review lens负责。在 bmad-build-auto无人值守的一次开发迭代和 bmad-code-review按需代码审查等技能中都定义了同一个核心审查器——Edge Case Hunter。Edge Case Hunter 是一个纯路径追踪器pure path tracer它不评判代码好坏只枚举 diff 或给定内容中缺少处理的路径与边界条件。其执行流程严格分为六步接收内容diff / 完整文件 / 函数穷举路径分析遍历控制流与领域边界完整性校验复查第 2 步的边界类别Deletion Check删除检查——diff 删除了代码时运行Claims Check声明检查——见 claims-check.md输出全部 findings 为单个 JSON 数组Deletion Check 正是第 4 步。原文档 deletion-check.md 开宗明义地定义了它的地位Secondary pass for the Edge Case Hunter — runs only when the diff removed meaningful code. Subordinate to the edge-case pass; findings are usually few or none.即它是 Edge Case Hunter 的辅助通道secondary pass仅在 diff 删除了有意义代码时运行从属于第 2 步的主 edge-case 通道由于主通道已经覆盖了大量路径缺失问题删除检查通常只产出很少甚至零条 findings。触发条件什么算删除了有意义代码Deletion Check 的第一道门槛是判断 diff 是否删除了meaningful code。判定规则包含两个明确排除项和两个明确纳入项忽略不触发纯重命名pure renames——只改名不改行为纯空白/格式调整whitespace——不改变任何语义。纳入触发被删除的代码块removed code、被替换的代码块replaced code——替换本质上是删除旧实现 新增新实现因此同样需要检查旧实现是否带走了不该丢失的东西。从执行链看这一门槛由 edge-case-hunter.md 的第 4 步显式表达If the diff removed or replaced meaningful code (ignore pure renames and whitespace): loadreferences/deletion-check.mdand follow it.也就是说不是每个 diff 都会触发删除检查。如果这次变更只新增代码、或只做重命名与排版第 4 步直接跳过只有存在真实删除/替换时才加载并遵循 deletion-check.md 的指令。这一条件式加载的设计保证了辅助通道只在其能贡献价值的场景消耗推理预算。核心判定问题删除的代码是否带走了行为或契约一旦确认存在有意义的删除/替换Deletion Check 对每一块被删除或被替换的代码执行同一个核心判定原文逐字要求For each chunk of removed or replaced code (ignore pure renames and whitespace), ask: did it carry behavior or a contract that the change neither re-established nor intentionally retired?拆解这个判定它实际上是三个子问题的合取它承载了什么carry behavior or a contract——被删代码是否强制了某种行为behavior例如输入校验、边界裁剪、状态转换、错误处理、资源释放或者某种契约contract例如对外 API 的语义、调用约定、返回值约束、前置/后置条件。变更是否重建了它re-established——新代码是否在别处以等价方式恢复了该行为或契约。若已重建删除无害。变更是否有意废弃了它intentionally retired——删除是否是有明确意图的需求变更例如产品决定废弃某功能而非重构过程中的误伤。若是有意废弃删除合法。只有当第 1 问为是、且第 2 问和第 3 问都为否时这次删除才构成问题需要产出一条 finding。判定通过后文档要求针对三种典型后果之一添加 findingregression回归被删行为/契约未被重建导致原有功能退化orphaned reference孤立引用删除了定义但留有引用或删除了唯一调用方却留下了无人再用的定义newly-dead code新产生的死代码删除后其他代码变成永不执行/永不引用的状态。同时有一个重要的去重规则Skip anything already covered by your edge-case findings.——如果某个删除问题已经被第 2 步的穷举路径分析捕获删除检查必须跳过避免同一问题重复上报。输出字段标准四字段 kind confidenceDeletion Check 的 findings追加到与 edge-case findings 相同的 JSON 数组中不是单独输出每个对象在标准四字段之外多出两个字段字段值说明kinddeletion标记这是删除检查产出区别于主 edge-case finding 与第 5 步的claimfindingconfidencehigh/medium/low置信度。文档明确提示删除检查的结论本质上是推断inferences必须显式评级location被删除的项四标准字段之一此处语义重载为被删除的东西trigger_condition它强制的行为或契约四标准字段之一即核心判定中的第 1 问答案guard_snippet在哪里或如何重建它四标准字段之一给出恢复该行为/契约的位置或最小代码形态potential_consequence回归或孤立四标准字段之一对应 regression / orphaned reference / newly-dead codelocation、trigger_condition、guard_snippet、potential_consequence四个标准字段的通用输出格式由 edge-case-hunter.md 的 OUTPUT FORMAT 定义location形如file:start-endtrigger_condition与potential_consequence均限 15 词以内guard_snippet为单行转义字符串Deletion Check 文档则进一步明确了这四个字段在删除场景下的专属语义映射。结合字段语义一次删除检查产出的一条典型 finding 可以表达为[ { kind: deletion, confidence: high, location: src/auth.py:88-95 (removed), trigger_condition: Input validation rejected empty tokens, guard_snippet: if not token: raise InvalidToken() before lookup, potential_consequence: Empty token now reaches upstream; auth bypass } ]以上为按字段语义构造的示意真实审查以实际 diff 为准。需要注意trigger_condition与potential_consequence的 15 词上限沿用主通道的输出约束避免 findings 变得冗长而难以被分诊triage程序消费。输出纪律无符合条件者不产出Deletion Check 有一条硬性的输出纪律也是全文最后一句Add nothing if nothing qualifies.两条对应的零产出路径分别是无删除/替换第 4 步根本不会加载本文件触发条件不满足有删除但无问题所有删除要么被重建、要么被有意废弃、要么已被 edge-case findings 覆盖则不添加任何 finding。这与 claims-check.md 的纪律Verified claims produce nothing. Add nothing if nothing is falsified.一脉相承审查器只上报经得起验证的问题宁可空数组[]也不为凑数而虚构缺陷。这也是两个辅助通道在方法论上的一致性设计——主通道穷举路径、辅助通道各管一类特殊风险三者最终合并为一个 JSON 数组见 edge-case-hunter 第 6 步Output all findings as a single JSON array。在无人值守工作流中的调度链Deletion Check 的价值在 BMAD 的自动化构建流程中体现得最充分。从 bmad-build-auto 的入口开始完整调用链如下入口用户调用bmad-build-auto经 SKILL.md 渲染 workflow.md按顺序执行 step 文件。审查阶段step-04-review.md 先将自{baseline_revision}以来的变更统一导出为 diff 文件{diff_file}不git add任何内容并把 spec 文件作为{claims_file}交付给审查镜头。镜头选择审查级别由 customize.toml 中的workflow.review与route决定——oneshot路由默认quickQuick 镜头full路由默认thorough。thorough 集包含四个镜头blind-hunter、edge-case-hunter、verification-gap、intent-alignment。镜头加载edge-case-hunter镜头id 见 customize.toml 中[[workflow.thorough_lenses]]的edge-case-hunter条目启动一个无上下文的子代理指令是完整阅读并遵循 review-prompts/edge-case-hunter.md。辅助通道触发Edge Case Hunter 在第 4 步按 diff 是否含删除/替换条件式加载references/deletion-check.md 并执行删除检查。因此Deletion Check 并不是一个独立可调用的命令而是审查镜头运行期的一段条件逻辑——它依附于 Edge Case Hunter 的执行上下文已追踪的 diff、已枚举的路径并共享其输出通道合并进同一个 JSON 数组。这种条件式参考文件加载conditional reference loading是 BMAD 技能体系的典型模式把长指令拆成按需加载的片段只在需要时进入上下文从而控制子代理的上下文占用。另外值得注意的是同一个 Edge Case Hunter 角色在三个技能中并存bmad-build-auto、bmad-build 与 bmad-code-review 均包含相同的第 4 步删除检查指令且三个技能都配套了相同的 deletion-check.md 与 claims-check.md 参考文件。这意味着无论你走哪条审查入口自动构建的 thorough 审查、手动按需代码审查删除检查的逻辑保持一致。与 Claims Check 的协同先追踪后看自述Deletion Check 与第 5 步的 Claims Check 是一对互补的辅助通道且存在严格的时序约束Deletion Check 检查的是代码删除带走的隐性契约代码做了什么、现在不做了什么Claims Check 检查的是变更自述spec / commit message中的显性声明代码声称做了什么是否被实现证伪。更关键的是读取顺序Edge Case Hunter 的输入中claims_filespec 文件必须在第 23 步路径追踪完成之后、第 5 步才允许读取——the path tracing is finished and the claims cannot steer it retroactively路径追踪已完成声明无法事后影响它。这一设计防止先读 spec、再顺着 spec 找证据的确认偏差保证主通道的路径枚举纯粹基于代码本身。Deletion Check 遵循同样的精神它对删除的评估基于已追踪的代码事实而非变更者声称的意图。二者协同后的产出被 step-04-review.md 的 Classify 阶段逐条验证、判定high/medium/low/false/maybe-false、分组并按intent_gap/bad_spec/patch/defer路由最终写入 spec 文件的## Review Triage Log。实战要点与落地建议将 Deletion Check 的方法论迁移到自己的代码审查流程无论人工还是 Agent 驱动时值得固化的几个要点先过滤噪音再检查删除检查只对改变行为的删除负责重命名、空白、格式化一律跳过避免审查者在重构型 diff 上浪费时间。用契约视角审视删除对每一处删除/替换主动追问三个问题——它原本强制了什么行为/契约新代码是否等价重建删除是否是有意为之三问缺一不可。警惕三类典型后果回归行为丢失、孤立引用定义与引用失联、新死代码删除引发连锁失效并在 finding 中明确对应到potential_consequence。与主通道去重删除问题若已被路径枚举覆盖不重复上报保持 finding 集合的干净与可分诊。显式标注推断置信度删除结论属于推断必须用confidence三档评级——有代码证据链支撑的高置信仅靠推测的低置信让后续 triage 能按置信度分配验证资源。宁缺毋滥Add nothing if nothing qualifies——无符合条件者输出空数组保持审查输出的信噪比。在 BMAD 的语境中这套检查尤其针对 AI 生成代码的一个典型缺陷模式LLM 在重构时会悄悄删掉它没看懂的防御性逻辑、边界处理或隐性契约。Deletion Check 以机械化的问题模板did it carry behavior or a contract...对冲这种倾向与穷举路径枚举的主通道、证伪声明的 Claims Check 共同构成三道防线让删除类回归在进入 step-04-review.md 的分诊与补丁循环之前就被系统化地暴露出来。【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
