specsfy-06-tdd-bdd

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Executar TDD orientado pelo BDD da especificação

执行基于规范BDD的TDD

Modo de interação

交互模式

Modo de interação:

perguntas

. Antes de formular qualquer pergunta, leia e aplique o

Contrato de perguntas numeradas

.specsfy/Spec.md

Leia o BDD como referência e converta o comportamento especificado em testes TDD executáveis e evidência rastreável. O Gherkin ajuda o usuário e o agente a entender contexto, ação e resultado; ele próprio não é uma suíte de testes.

交互模式：

问答式

。在提出任何问题之前，请阅读并应用

.specsfy/Spec.md

中的

编号问题协议

。

以BDD为参考，将指定的行为转换为可执行的TDD测试和可追溯的证据。Gherkin帮助用户和Agent理解上下文、动作和结果；它本身不是测试套件。

Orquestrar a conversa

协调对话

Ao concluir esta etapa ou detectar trabalho de outra etapa, anuncie

Pendência detectada: <descrição> — ação: resolvendo nesta etapa

e resolva-a quando pertencer ao próprio escopo. Quando houver troca de responsabilidade, anuncie

Transição automática: $specsfy-06-tdd-bdd → $<destino> — motivo: <motivo> — resultado esperado: <resultado>

e carregue imediatamente a skill de destino, sem pedir confirmação nem repetir o comando. Continue na mesma conversa. Depois de uma correção necessária a esta etapa, anuncie

Retomada automática: $<destino> → $specsfy-06-tdd-bdd — pendência resolvida: <resultado>

e retome-a imediatamente. Reavalie o estado após cada handoff para evitar ciclos. Não peça confirmação para o handoff; ações sensíveis continuam exigindo autorização específica.

完成此步骤或检测到其他步骤的工作时，请宣布

检测到待处理项：<描述> — 操作：在此步骤中解决

，并在属于自身范围时进行解决。当需要移交责任时，请宣布

自动转换：$specsfy-06-tdd-bdd → $<目标> — 原因：<原因> — 预期结果：<结果>

，并立即加载目标Skill，无需请求确认或重复命令。继续同一对话。在完成此步骤所需的修正后，请宣布

自动恢复：$<目标> → $specsfy-06-tdd-bdd — 已解决待处理项：<结果>

，并立即恢复执行。每次移交后重新评估状态以避免循环。移交无需请求确认；敏感操作仍需特定授权。

Escolher o modo

选择模式

```
prepare
```
: antes da implementação, criar o próximo teste/scenario e provar RED sem escrever código de produção.
```
cycle
```
: executar RED → GREEN → REFACTOR para uma fatia explicitamente escolhida.
```
verify
```
: executar suites e auditar rastreabilidade sem criar comportamento novo.

Se o usuário não indicar o modo, use

prepare

quando a seção 14 ainda não estiver em execução e

cycle

quando houver uma tarefa ativa.

```
prepare
```
：在实现之前，创建下一个测试/场景，并在不编写生产代码的情况下验证RED状态。
```
cycle
```
：为明确选择的功能片段执行RED → GREEN → REFACTOR循环。
```
verify
```
：执行测试套件并审核可追溯性，不创建新行为。

如果用户未指定模式，当第14节尚未执行时使用

prepare

，当存在活跃任务时使用

cycle

。

Preparar

准备阶段

Leia
```
specs/<estado>/<NNNN>-<slug>/spec.md
```
, testes e configuração do projeto.

Exija

Formato: Specsfy/2.0

Definition Gate: Passed

. No modo

prepare

, use

Status: Defined

Plan Gate: Pending

; nos modos

cycle

verify

, use

Status: Planned

Implementing

Selecione uma fatia vertical pequena: um
```
AC
```
Gherkin e seus
```
FR/NFR
```
.
Resolva o runner de testes pela stack antes de escrever testes:
- projeto PHP (
```
composer.json
```
  ou
```
artisan
```
  ), inclusive PHP + Node: use Pest;
- projeto Node sem PHP: pergunte ao usuário qual runner adotar antes de instalar ou configurar; recomende Vitest por padrão;
- outra stack: preserve o runner de testes existente ou pergunte quando não houver decisão reproduzível.
Em Node, considere a decisão materializada quando
```
package.json
```
expuser o script
```
test:tdd
```
; não escolha nem instale dependência silenciosamente.
Leia
```
references/test-levels.md
```
para escolher o nível mais baixo que ainda prova o comportamento.

阅读
```
specs/<状态>/<NNNN>-<slug>/spec.md
```
、测试用例和项目配置。

要求遵循

格式：Specsfy/2.0

和

定义门：已通过

。在

prepare

模式下，使用

状态：已定义

和

计划门：待处理

；在

cycle

和

verify

模式下，使用

状态：已计划

或

实现中

。

选择一个小的垂直功能片段：一个Gherkin
```
AC
```
（验收标准）及其
```
FR/NFR
```
（功能需求/非功能需求）。
在编写测试前根据技术栈确定测试运行器：
- PHP项目（
```
composer.json
```
  或
```
artisan
```
  ），包括PHP + Node：使用Pest；
- 无PHP的Node项目：在安装或配置前询问用户采用哪种运行器；默认推荐Vitest；
- 其他技术栈：保留现有测试运行器，或在无可重现决策时询问用户。
在Node项目中，当
```
package.json
```
暴露
```
test:tdd
```
脚本时，视为已确定决策；不得静默选择或安装依赖。
阅读
```
references/test-levels.md
```
以选择仍能验证行为的最低测试级别。

Usar o BDD para escrever TDD

利用BDD编写TDD测试

Use o bloco Gherkin do
```
AC
```
em
```
spec.md
```
como contrato de referência sem mudar seu significado.
Não crie, copie nem execute arquivos
```
.feature
```
ou step definitions. Os termos Given/When/Then permanecem apenas na
```
spec.md
```
.
Em PHP, escreva o teste TDD com Pest em
```
tests/Feature/
```
ou
```
tests/Unit/
```
, no menor nível que prova o comportamento. Marque cada caso executável, imediatamente junto à sua definição, com:

php

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

Em Node, depois da resposta do usuário, escreva o teste TDD no runner escolhido e use
```
SPECSFY: US-001 FR-001 AC-001
```
.
Materialize no mínimo três casos TDD distintos para a feature inteira e para cada
```
US
```
,
```
FR
```
e
```
NFR
```
: caminho feliz, regra/variação crítica e falha ou limite material. Um único marcador
```
SPECSFY:
```
compartilhado pelo arquivo conta como um caso, mesmo que o arquivo contenha vários testes.
Cubra cada
```
AC
```
com ao menos um caso TDD, sem multiplicar casos equivalentes.
Escolha unidade, integração, contrato ou browser conforme a fronteira descrita pelo BDD; não crie uma segunda suíte apenas para rotulá-la como BDD.
Não use mocks para remover justamente a fronteira que o cenário pretende provar.

将
```
spec.md
```
中
```
AC
```
的Gherkin块作为参考协议，不得更改其含义。
不得创建、复制或执行
```
.feature
```
文件或步骤定义。Given/When/Then术语仅保留在
```
spec.md
```
中。
在PHP中，使用Pest在
```
tests/Feature/
```
或
```
tests/Unit/
```
中编写TDD测试，选择能验证行为的最小级别。在每个可执行用例的定义旁立即标记：

php

// 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移除场景旨在验证的边界。

Ciclo obrigatório

强制循环流程

RED

RED阶段

Leia o BDD de referência e escreva o menor teste TDD que prova o
```
AC
```
e seus requisitos.
Execute o teste TDD; nunca execute Gherkin.
Confirme falha pelo comportamento ausente ou incorreto.
Se falhar por sintaxe, fixture, importação ou ambiente, corrija o teste e repita.
Se passar antes da mudança, o teste não demonstra o gap: refine-o ou prove que a funcionalidade já existe.

No modo

prepare

, pare após o RED válido, registre evidência e conclua o checklist da tarefa

[TEST]

correspondente. Não altere

Plan Gate

; anuncie e retorne automaticamente para

$specsfy-05-tasks

, que valida todos os predecessores antes de promover a spec para

Planned

. Registre a linha correspondente na tabela

Evidência RED-GREEN-REFACTOR

com o RED observado.

阅读参考BDD，编写能验证
```
AC
```
及其需求的最小TDD测试。
执行TDD测试；绝不执行Gherkin。
确认因行为缺失或不正确导致测试失败。
如果因语法、 fixture、导入或环境问题失败，修正测试并重复执行。
如果在修改前测试通过，说明该测试未体现差距：优化测试或证明功能已存在。

在

prepare

模式下，在验证有效的RED状态后停止，记录证据并完成对应

[TEST]

任务的检查清单。不得修改

计划门

；宣布并自动返回

$specsfy-05-tasks

，后者会在将规范升级为

已计划

前验证所有前置条件。在

RED-GREEN-REFACTOR证据表

中记录对应行及观察到的RED状态。

GREEN

GREEN阶段

No modo

cycle

, escreva o mínimo de código de produção que satisfaça o cenário. Execute primeiro o teste focal e depois a suite relacionada. Não generalize antes de haver um exemplo que exija generalização. Atualize a mesma linha de evidência com o GREEN observado.

在

cycle

模式下，编写满足场景需求的最少生产代码。先执行聚焦测试，再执行相关测试套件。在没有需要泛化的示例前不要进行泛化。在同一证据行中更新观察到的GREEN状态。

REFACTOR

REFACTOR阶段

Com tudo verde, elimine duplicação e melhore nomes/estrutura sem alterar comportamento. Execute novamente as suites relacionadas. Registre o comando de regressão na seção 11 e a evidência na matriz da seção 12.

当所有测试通过时，消除重复代码并优化命名/结构，不改变行为。再次执行相关测试套件。在第11节记录回归命令，在第12节的矩阵中记录证据。

Auditar rastreabilidade

审核可追溯性

Execute:

bash

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

Trate como gap cada feature,

US

FR

NFR

com menos de três casos TDD e cada

AC

sem ao menos um caso. Para

NFR

verificado manualmente ou por observabilidade, cite a evidência sem dispensar os três casos automatizáveis; quando necessário, ajuste

--kinds

sem remover IDs aplicáveis. Em specs com

Evidence Contract: 1

, acrescente

--full-chain

para exigir

US/FR/NFR/AC → teste → tarefa → evidência

. Durante execução, mantenha

Delivery Gate: In Progress

e atualize o

Gate do Ato III — Entrega

da seção 13. Use

Passed

somente quando não houver gap obrigatório, todas as tarefas estiverem concluídas e a Definition of Done estiver comprovada.

执行：

bash

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

将每个少于三个TDD用例的功能、

US

、

FR

或

NFR

，以及每个没有至少一个用例的

AC

视为差距。对于手动验证或通过可观测性验证的

NFR

，需引用证据，但不得免除三个可自动化的用例；必要时调整

--kinds

参数，但不得移除适用的ID。对于

证据契约：1

的规范，添加

--full-chain

参数以要求

US/FR/NFR/AC → 测试 → 任务 → 证据

的完整链路。执行期间，保持

交付门：进行中

并更新第13节的

第三阶段交付门

。仅当没有强制差距、所有任务已完成且完成定义已验证时，才使用

已通过

。

Disciplina sob pressão

压力下的纪律要求

Tentação	Regra
“É uma mudança pequena.”	Mudanças pequenas recebem testes pequenos; tamanho não substitui RED.
“O código já está pronto.”	Escreva um teste de caracterização; não altere produção para fabricar RED. Para comportamento novo, escolha um caso ainda não atendido.
“O prazo permite pular RED.”	Sem falha observada não há prova de que o teste protege o requisito.
“O líder autorizou.”	Autoridade pode mudar escopo, não transformar ausência de evidência em TDD.
“Testar depois é equivalente.”	Test-first guia o contrato e prova sensibilidade antes da implementação.

Em uma tarefa de teste, atualize

PREP

EXECUTE

VERIFY

EVIDENCE

IMPROVE

conforme cada etapa acontecer. Não marque o pai como concluído sem arquivo, marcador, RED válido, comando/evidência e revisão do processo. Não escreva código de produção antes que o predecessor TDD informado pelo BDD da mesma fatia esteja concluído e com RED registrado na spec.

诱惑	规则
“这只是一个小改动。”	小改动对应小测试；改动大小不能替代RED阶段。
“代码已经准备好了。”	编写特性测试；不得修改生产代码来制造RED状态。对于新行为，选择尚未满足的用例。
“时间紧迫，可以跳过RED阶段。”	未观察到失败则无法证明测试能保护需求。
“领导已经批准了。”	权限可以改变范围，但不能将缺乏证据的情况视为TDD。
“事后测试是等效的。”	测试先行指导契约，并在实现前验证敏感性。

在测试任务中，根据每个步骤的执行情况更新

PREP

、

EXECUTE

、

VERIFY

、

EVIDENCE

和

IMPROVE

状态。没有文件、标记、有效的RED状态、命令/证据和流程审核，不得标记父任务为已完成。在同一功能片段的BDD指定的前置TDD测试完成并在规范中记录RED状态之前，不得编写生产代码。

Auditar QA

QA审核

Depois de executar os runners pertencentes ao repositório, registre

Passed

ou a falha na coluna Evidência da seção 12 e audite:

bash

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

O auditor não executa comandos extraídos de Markdown. AC manual exige método, responsável e evidência; AC sem resultado impede

Delivery Gate: Passed

. Quando houver atestação do runner, repita com

--attestation PATH

: o auditor exige exatamente o check

acceptance:<slug>

aprovado, detail JSON válido e cobertura de todos os ACs. Texto

Passed

isolado não substitui essa prova.

执行仓库所属的测试运行器后，在第12节的证据列中记录

已通过

或失败信息，并执行审核：

bash

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

审核器不会执行从Markdown中提取的命令。手动AC需要方法、负责人和证据；无结果的AC会阻碍

交付门：已通过

。当有运行器证明时，添加

--attestation PATH

参数重复执行：审核器要求完全匹配已批准的

acceptance:<slug>

检查、有效的详细JSON以及覆盖所有AC。单独的

已通过

文本不能替代此证明。

Relatar evidência

报告证据

Informe a fatia, IDs cobertos, arquivo do teste, comando RED, causa da falha, comando GREEN quando aplicável, suite de regressão e gaps de rastreabilidade.

报告功能片段、覆盖的ID、测试文件、RED命令、失败原因（如适用）、GREEN命令、回归测试套件和可追溯性差距。

Especialistas sob demanda

按需专家支持

Leia references/specialists.md quando o runner, boundary ou oráculo de teste for específico de uma tecnologia. O especialista complementa; esta skill preserva RED/GREEN e rastreabilidade.

当测试运行器、边界或测试预言机属于特定技术时，请阅读references/specialists.md。专家仅提供补充支持；本Skill需保留RED/GREEN流程和可追溯性。