specsfy-06-tdd-bdd

根据规范中的 BDD 执行 TDD

必须完成的准备工作

执行此技能前，必须先在项目根目录加载 $specsfy-setup。自动交接时，也必须在此阶段前重新加载它。 复用对话中已确认的根目录；如果 setup 指出了待处理事项，则不要继续。

交互模式

交互模式：perguntas。 提出任何问题前，先阅读并应用 .specsfy/Spec.md 中的 Contrato de perguntas numeradas。

将 BDD 作为参考，并把规范中描述的行为转化为可执行的 TDD 测试和可追溯的证据。Gherkin 有助于用户和 Agent 理解上下文、操作和结果；但 Gherkin 本身并不是测试套件。

数据库强制保护措施

执行任何聚焦测试、测试套件或回归测试前，请检查命令和环境：

node .agents/skills/specsfy-setup/scripts/check_database_safety.mjs \
  --project <raiz> --command "<comando-de-teste>"

在 Laravel 中，检查必须确认存在 .env.testing、APP_ENV=testing，并且使用的数据库与 .env 中记录的开发数据库明确不同。结果为 PENDING 时，不得执行任何测试。请修正测试环境，重新检查，并且只有在结果为 SAFE 后才能继续。

将 IGNORED 视为必须丢弃该命令。不得执行、使用 --force 调整命令，也不得请求授权运行 migrate:fresh、 migrate:refresh、migrate:reset、migrate:rollback、db:wipe、 schema:drop、prisma migrate reset、DROP DATABASE、DROP SCHEMA、 DROP TABLE、TRUNCATE 或等效命令。不要使用 RefreshDatabase 或 DatabaseMigrations；在 Laravel 中，优先使用 DatabaseTransactions，并通过 factories 只创建该用例所需的记录。

协调对话流程

完成此阶段或发现其他阶段的工作时，宣布 Pendência detectada: <descrição> — ação: resolvendo nesta etapa，并在该事项属于当前范围时予以解决。职责需要切换时，宣布 Transição automática: $specsfy-06-tdd-bdd → $<destino> — motivo: <motivo> — resultado esperado: <resultado>，并立即加载目标技能，无需请求确认或重复命令。在同一对话中继续。完成此阶段所需的修正后，宣布 Retomada automática: $<destino> → $specsfy-06-tdd-bdd — pendência resolvida: <resultado>，并立即恢复此阶段。每次交接后都要重新评估状态，以避免循环。交接无需请求确认；敏感操作仍须获得专门授权。

选择模式

• prepare：实现前，创建下一个测试／scenario，并在不编写生产代码的前提下证明 RED。
• cycle：针对明确选定的切片执行 RED → GREEN → REFACTOR。
• verify：执行测试套件并审计可追溯性，不创建新行为。

如果用户未指定模式，则当第 14 节尚未开始执行时使用 prepare；有活动任务时使用 cycle。

准备

1. 阅读 specs/<estado>/<NNNN>-<slug>/spec.md、测试和项目配置。
2. 要求 Formato: Specsfy/2.0 和 Definition Gate: Passed。在 prepare 模式下，使用 Status: Defined 和 Plan Gate: Pending；在 cycle 和 verify 模式下，使用 Status: Planned 或 Implementing。
3. 选择一个小型垂直切片：一个 Gherkin AC 及其 FR/NFR。
4. 编写测试前，根据技术栈确定测试运行器：
   • PHP 项目（composer.json 或 artisan），包括 PHP + Node：使用 Pest；
   • 不含 PHP 的 Node 项目：安装或配置前，询问用户采用哪个测试运行器；默认推荐 Vitest；
   • 其他技术栈：保留现有测试运行器；如果没有可复现的决定，则先询问。
5. 使用 check_database_safety.mjs 检查环境和命令。如果状态不是 SAFE，不要运行任何测试，并保持该步骤待处理。
6. 对于 Node 项目，当 package.json 提供 test:tdd 脚本时，视为决定已落实；不要擅自选择或安装依赖。
7. 阅读 references/test-levels.md，选择仍能证明行为的最低测试级别。

使用 BDD 编写 TDD

• 使用 spec.md 中 AC 的 Gherkin 区块作为参考契约，不得改变其含义。
• 不要创建、复制或执行 .feature 文件或 step definitions。Given/When/Then 术语只保留在 spec.md 中。
• 对于 PHP，使用 Pest 在 tests/Feature/ 或 tests/Unit/ 中编写 TDD 测试，选择能够证明行为的最低级别。紧邻每个可执行用例的定义处，标记：

// SPECSFY: US-001 FR-001 AC-001

• 对于 Node，在用户答复后，使用选定的测试运行器编写 TDD 测试，并使用 SPECSFY: US-001 FR-001 AC-001。
• 整个功能以及每个 US、FR 和 NFR，至少落实三个不同的 TDD 用例：成功路径、关键规则/变体，以及实质性失败或边界情况。即使文件中包含多个测试，一个由文件共享的 SPECSFY: 标记也只算一个用例。
• 每个 AC 至少覆盖一个 TDD 用例，不要重复添加等效用例。
• 根据 BDD 描述的边界选择单元、集成、契约或浏览器测试；不要仅为了标记为 BDD 而另建一套测试。
• 不要使用 mock 来移除场景正要验证的边界。

强制周期

RED

1. 阅读参考 BDD，编写能够证明 AC 及其要求的最小 TDD 测试。
2. 执行 TDD 测试；绝不执行 Gherkin。
3. 确认失败是由缺失或不正确的行为导致。
4. 如果失败原因是语法、fixture、导入或环境问题，修正测试并重试。
5. 如果变更前测试已通过，则该测试无法证明差距：改进测试，或证明该功能已经存在。

在 prepare 模式下，在有效的 RED 阶段后停止，记录证据，并完成对应的 [TEST] 任务检查清单。不要更改 Plan Gate；宣布并自动返回 $specsfy-05-tasks，该流程会在将 spec 提升为 Planned 前验证所有前置项。 在 Evidência RED-GREEN-REFACTOR 表格中记录对应行及观察到的 RED。

GREEN

在 cycle 模式下，编写满足场景所需的最少生产代码。先执行焦点测试，再执行相关测试套件。在出现需要泛化的示例之前，不要进行泛化。 使用观察到的 GREEN 更新同一条证据记录。

REFACTOR

全部测试通过后，消除重复并改进命名/结构，但不要改变行为。重新运行相关测试套件。 在第 11 节记录回归命令，并在第 12 节的矩阵中记录证据。

审计可追溯性

执行：

node .agents/skills/specsfy-06-tdd-bdd/scripts/check_traceability.mjs specs/<estado>/<NNNN>-<slug>/spec.md .

每个少于三个 TDD 用例的 feature、US、FR 或 NFR，以及每个没有至少一个用例的 AC，都视为缺口。对于通过手动方式或可观测性验证的 NFR，请注明证据，但仍须提供三个可自动化的用例；必要时调整 --kinds，但不要删除适用的 ID。 对于 Evidence Contract: 1 的 spec，添加 --full-chain，要求满足 US/FR/NFR/AC → 测试 → 任务 → 证据。 执行期间，保持 Delivery Gate: In Progress，并更新第 13 节中的 Gate do Ato III — Entrega。只有在不存在强制性缺口、所有任务均已完成且 Definition of Done 已有证据证明时，才能使用 Passed。

高压下的纪律

诱惑	规则
“这只是一个小改动。”	小改动对应小测试；规模不能替代 RED。
“代码已经写好了。”	编写特征测试；不要为了制造 RED 而修改生产代码。对于新行为，选择一个尚未满足的用例。
“期限允许跳过 RED。”	没有观察到失败，就无法证明测试能保护该需求。
“负责人批准了。”	权限可以改变范围，但不能将缺少证据变成 TDD。
“之后再测试也一样。”	先编写测试可以指导契约，并在实现前证明测试的敏感性。

在测试任务中，随着每个阶段的推进，更新 PREP、EXECUTE、VERIFY、VISUAL、EVIDENCE 和 IMPROVE。VISUAL 项也必须用于确认测试是否涉及界面；如果不涉及，请记录 不适用 及原因。没有文件、标记、有效的 RED、命令/证据和流程审查时，不要将父项标记为已完成。 在同一切片的 BDD 所指定的前置 TDD 已完成并在 spec 中记录 RED 之前，不要编写生产代码。

审计 QA

执行仓库所属的 runners 后，在第 12 节的 Evidência 列中记录 Passed 或失败情况，并进行审计：

node .agents/skills/specsfy-06-tdd-bdd/scripts/verify_acceptance.mjs \
  specs/<estado>/<NNNN>-<slug>/spec.md .

审计器不会执行从 Markdown 中提取的命令。手动 AC 必须注明方法、负责人和证据；没有结果的 AC 会阻止 Delivery Gate: Passed。 如果有 runner 证明，请使用 --attestation PATH 重新运行：审计器要求恰好有一项已通过的 acceptance:<slug> 检查、有效的 detail JSON，以及对所有 AC 的覆盖。单独的 Passed 文本不能替代此证明。

报告证据

报告切片、覆盖的 ID、测试文件、RED 命令、失败原因、适用时的 GREEN 命令、回归套件，以及可追溯性缺口。

按需专家

如果 runner、boundary 或测试 oracle 特定于某项技术，请阅读 references/specialists.md。专家内容提供补充；此 skill 负责保留 RED/GREEN 和可追溯性。