fixflow

Fixflow

概述

使用此技能，在一次运行中完成端到端工程工作：

• 完整制定计划。
• 严格按顺序执行。
• 持续验证。
• 明确提交策略（默认使用 per_step；按需使用 final_only/milestone）。
• 按需或在需求不明确时添加 BDD 行为规范。

触发条件

用户提出以下一项或多项要求时，触发此技能：

• 完整计划并按顺序执行。
• 不考虑向后兼容。
• 交付前测试所有内容。
• 完成后提交，或每进行下一步前提交。
• 行为驱动交付（BDD）或验收场景。

工作流

1. 定义就绪标准（DoR）

参见共享交付基础：references/delivery-base.md

2. 编辑前制定完整计划

参见共享交付基础：references/delivery-base.md

3. 按需添加 BDD/TDD 层

用户提出要求，或需求不明确时，使用 BDD。

3.0 TDD 模式（RED -> GREEN -> IMPROVE）

用户要求使用 TDD 或测试驱动交付时：

1. RED — 先编写一个失败的测试

   • 从需求中提取可测试的行为
   • 编写最简测试用例，断言预期行为
   • 运行测试，确认其失败（红）
   • 如果测试意外通过 -> 说明需求已满足，或测试有误

2. GREEN — 编写最简实现

   • 只编写足以让测试通过的代码
   • 不做额外改进，也不顺手修改其他内容
   • 运行测试，确认其通过（绿）

3. IMPROVE — 在测试保持通过的前提下重构

   • 消除重复，改进命名，简化逻辑
   • 每次重构后运行测试，确认没有回归
   • 重构不得改变外部行为

覆盖率目标：新代码的行覆盖率达到 80%，关键路径达到 100%。

TDD 模式的触发条件：

• 用户说“ TDD”“测试驱动”或“先写测试”
• 用户说“先写测试，再写代码”
• 需求定义明确，输入和输出清晰

关于 BDD Lite、场景质量检查清单、场景大纲和测试层映射，请参阅共享参考文档：

references/bdd-guide.md

4. 逐步执行

参见共享交付基础：references/delivery-base.md

对于 per_step（默认策略）：

• 仅暂存当前步骤涉及的文件。
• 运行步骤级检查。
• 步骤检查通过后立即提交。
• 记录步骤与提交哈希的对应关系。

5. 按需应用不考虑向后兼容模式

参见共享交付基础：references/delivery-base.md

6. 使用测试矩阵验证（验证循环）

参见共享交付基础：references/delivery-base.md

7. 提交并交接

参见共享交付基础：references/delivery-base.md

防护准则

• 预期需要实现时，不要止步于制定计划。
• 不要留下未完成的计划步骤。
• 可以立即运行的必要测试，不要推迟。
• 不要默认使用 final_only；除非用户明确提出其他要求，否则使用 per_step。
• 当 commit_policy = per_step 时，提交前不要进入下一项计划步骤。
• 用户明确要求不进行兼容性工作时，不要声称具有兼容性。
• 不要将无关的既有未提交文件纳入提交。
• 没有具体的验证证据时，不要交接。