---
name: bdd-gherkin
description: Como escrever e validar critérios de aceite como cenários Gherkin (Dado/Quando/Então) e regras EARS, com a disciplina dos Três Amigos. Use ao decompor tarefas (escrever critérios) ou ao revisar uma implementação contra os critérios de aceite.
---

# Critérios de aceite executáveis (BDD)

Os critérios de aceite são o contrato de comportamento da spec. Eles devem ser escritos ANTES da implementação e, idealmente, verificados de forma automática.

## Gherkin (o exemplo concreto)

```gherkin
Funcionalidade: Exportar relatório em CSV

  Cenário: Exportação bem-sucedida
    Dado que estou na tela de relatório com dados carregados
    Quando eu clico em "Exportar CSV"
    Então um arquivo .csv é baixado com uma linha por registro
    E o cabeçalho corresponde às colunas visíveis

  Cenário: Relatório vazio
    Dado que o relatório não tem registros
    Quando eu clico em "Exportar CSV"
    Então vejo a mensagem "Nada para exportar"
    E nenhum arquivo é baixado
```

Um bom cenário é concreto (valores reais, não "dados válidos"), independente de implementação (descreve comportamento observável, não cliques internos) e cobre o caminho feliz, os de borda e os de erro.

## EARS (a regra geral)

Para regras que valem sempre, complemente o exemplo com uma frase no padrão EARS:
- **Ubíqua:** "O sistema DEVE registrar toda exportação no log de auditoria."
- **Acionada por evento:** "QUANDO o usuário solicita exportação, o sistema DEVE gerar o arquivo em até 5s."
- **Condicional/estado:** "ENQUANTO não houver registros, o botão Exportar DEVE ficar desabilitado."

Gherkin dá o exemplo; EARS dá a regra. Os dois juntos removem ambiguidade.

## Disciplina dos Três Amigos

O comportamento é acordado por negócio + dev + QA ANTES de o agente codar. Isso evita que a IA "confira a própria prova": o critério precisa ser aprovado por um humano (no checkpoint de PRD/Tech Spec), e a suíte de aceite precisa passar (verde) ANTES de o gate de merge ser oferecido.
