@dewtech/dare-cli 2.15.0 → 2.17.0

package/templates/ide/claude/.claude/commands/dare-review.md

@@ -0,0 +1,113 @@
+# Comando: /dare-review
+
+## Descrição
+
+Audita uma task **implementada** cruzando a spec (`DARE/EXECUTION/<id>.md`) com os arquivos reais que ela tocou. Detecta stubs, mocks fora de testes, funções vazias, TODOs, retorno-fantasma — **e** valida critério-a-critério se a implementação satisfaz o que a spec prometeu.
+
+Esta é a camada **semântica** do review. A camada estática (regex / patterns) já é feita automaticamente pelo CLI quando você roda `dare review <task-id>`. Este comando combina as duas: rode a estática via CLI, gere um verdito semântico aqui, e produza um relatório fundido.
+
+## Quando rodar
+
+- Antes de marcar uma task como DONE (gate obrigatório no Definition of Done do TASK-SPEC)
+- Quando o `dare review <id>` estático passa mas você quer validação adicional contra a spec
+- Quando o dev pede revisão manual: `/dare-review task-034`
+
+## Como executar
+
+### 1. Validar argumento
+
+`$ARGUMENTS` deve conter o `task-id` (ex.: `task-034`). Se vazio, peça.
+
+### 2. Rodar a camada estática primeiro
+
+```bash
+dare review $ARGUMENTS --format json > .dare/review-static-$ARGUMENTS.json
+```
+
+Leia esse JSON. Se já houver erros estáticos, **reporte-os primeiro** e pergunte se quer prosseguir com a análise semântica mesmo assim (geralmente não vale — corrige os erros estáticos antes).
+
+### 3. Carregar contexto
+
+- `DARE/EXECUTION/$ARGUMENTS.md` — spec da task
+- Cada arquivo listado na seção 3 da spec ("ARQUIVOS A CRIAR / MODIFICAR")
+- `DARE/BLUEPRINT.md` — contratos de API / modelos referenciados
+
+### 4. Auditoria critério-a-critério
+
+Para **cada** item nas seções abaixo da spec, marque ✅ / ❌:
+
+#### 4.1 Objetivo (seção 1)
+A implementação atinge o estado observável que a seção 1 promete? Encontre **evidência concreta** (arquivo + linha) ou marque como não atendido.
+
+#### 4.2 Arquivos a criar / modificar (seção 3)
+- Todos os arquivos da tabela existem com o conteúdo descrito?
+- Há arquivos não listados que deveriam estar lá?
+
+#### 4.3 Implementação (seção 4)
+- Cada passo numerado foi executado?
+- Assinaturas exatas correspondem ao que a spec pede?
+- Validações implementadas correspondem às regras descritas (não "valida email" — a regex específica)?
+
+#### 4.4 Testes (seção 4, subitem)
+Para cada teste listado:
+- Existe um teste com nome correspondente?
+- O teste tem **assertions reais** que validariam o comportamento (não `expect(true).toBe(true)`)?
+- Edge cases enumerados têm cobertura?
+
+#### 4.5 Segurança (seção 5)
+- Input validation cobre o que a spec lista?
+- Não há secrets/tokens hardcoded?
+- SQL/Command injection mitigado via ORM / prepared statements?
+
+#### 4.6 Padrões Proibidos (seção 7 — ANTI-STUB)
+A camada estática já checou. **Não duplique** — só anote se você encontrar algo que o regex não pegaria (ex.: dados hardcoded que parecem reais mas vêm de uma constante embutida no controller).
+
+### 5. Emitir o verdito semântico
+
+Salve em `.dare/review-semantic-$ARGUMENTS.json`:
+
+```json
+{
+  "passed": true,
+  "unmetCriteria": [],
+  "notes": "Resumo de 1-3 frases do que foi verificado"
+}
+```
+
+Se algo falhou:
+
+```json
+{
+  "passed": false,
+  "unmetCriteria": [
+    "Seção 4.3: validação de senha não implementa regex de força (≥8 chars + maiúscula + dígito)",
+    "Seção 4.4: teste de edge case 'email duplicado' não existe"
+  ],
+  "notes": "2 critérios não atendidos em src/auth/register.ts e tests/auth.test.ts"
+}
+```
+
+### 6. Rodar o review fundido
+
+```bash
+dare review $ARGUMENTS --from-agent .dare/review-semantic-$ARGUMENTS.json
+```
+
+O CLI vai fundir estática + semântica e exibir o relatório final. Exit code 0 = task pode ir para DONE; exit code 1 = não pode.
+
+### 7. Mensagem final ao usuário
+
+Se passou:
+> ✅ Task `$ARGUMENTS` aprovada na review. Pode marcar como DONE: `dare execute --complete $ARGUMENTS`
+
+Se falhou:
+> ❌ Task `$ARGUMENTS` não passou na review. Itens a corrigir:
+> [lista de unmetCriteria + violations estáticas]
+>
+> Após corrigir, rode `/dare-review $ARGUMENTS` novamente.
+
+## Regras inegociáveis
+
+- **Não invente** que algo está implementado se você não viu o código. Se um arquivo não existe, isso é `unmetCriteria`.
+- **Não aceite** mocks/stubs em código de produção mesmo que "façam o teste passar". Eles violam o Anti-Stub Contract.
+- **Mocks são OK** dentro de `*.test.*`, `*.spec.*`, `__tests__/`, `tests/`, `spec/` — a camada estática já distingue.

package/templates/ide/claude/templates/TASK-SPEC-template.md

@@ -85,16 +85,57 @@ Execute **todos** antes de marcar a task como DONE. Se qualquer um falhar, leia
 
 ---
 
-## 7. CRITÉRIOS DE DONE
+## 7. PADRÕES PROIBIDOS (ANTI-STUB / ANTI-MOCK)
 
-- [ ] Todos os 4 validation gates passaram sem erros
-- [ ] Testes cobrem caminho feliz + erros + edge cases da seção 4
+> Esta seção é **inegociável**. O comando `dare review` (v2.17+) escaneia o código modificado por esta task e reprova se encontrar qualquer padrão abaixo.
+
+### Em código de produção (qualquer arquivo **fora** de `*.test.*`, `*.spec.*`, `__tests__/`, `tests/`, `spec/`)
+
+- ❌ **TODO / FIXME / XXX / HACK** — qualquer um desses marcadores em comentário
+- ❌ **Função vazia** — `fn x() {}`, `function x() {}`, `def x(): pass`, `def x(): ...`
+- ❌ **Stub explícito** — `throw new Error('not implemented')`, `unimplemented!()`, `todo!()`, `raise NotImplementedError`
+- ❌ **Retorno-fantasma** — `return null` / `return undefined` / `return {}` / `return []` como **única** statement de função pública declarada nesta task
+- ❌ **Mocks fora de testes** — `jest.fn()`, `sinon.stub()`, `mockReturnValue`, dados hardcoded fingindo ser do banco, fixtures injetadas em controllers/services
+- ❌ **Comentário de placeholder** — `// implement later`, `# placeholder`, `// stub`, `// FIXME implement`
+
+### Mocks são permitidos APENAS em
+
+- Arquivos de teste (`*.test.*`, `*.spec.*`, `__tests__/`, `tests/`, `spec/`)
+- Seeds / fixtures dentro de `database/seeders/`, `tests/fixtures/`
+- Helpers explicitamente marcados como auxiliares de teste
+
+### Verificação automática
+
+Antes de marcar a task como DONE, rode:
+
+```bash
+dare review <task-id>
+```
+
+Output esperado:
+
+```
+✅ task-XYZ: nenhum padrão proibido detectado em N arquivos modificados.
+```
+
+Se a review falhar, a task **não pode** ir para DONE — corrija os achados e re-rode.
+
+---
+
+## 8. CRITÉRIOS DE DONE
+
+- [ ] Todos os 4 validation gates passaram sem erros (build + test + lint + audit)
+- [ ] Testes cobrem caminho feliz + erros enumerados + edge cases da seção 4
 - [ ] Considerações de segurança da seção 5 todas checadas
 - [ ] Arquivos listados na seção 3 criados/modificados conforme spec
+- [ ] **`dare review <task-id>` passou** (seção 7 — sem stubs, mocks, TODOs)
+- [ ] Cada validação declarada na spec tem teste demonstrando o erro real (não placeholder)
+- [ ] Cada edge case enumerado tem teste cobrindo
+- [ ] Endpoints retornam dados reais do banco/service, não hardcoded
 - [ ] `DARE/TASKS.md` atualizado com status `DONE`
 
 ---
 
-## 8. PRÓXIMA TASK SUGERIDA
+## 9. PRÓXIMA TASK SUGERIDA
 
 `[task-id]` — [título] _(desbloqueada após conclusão desta task)_

package/templates/ide/cursor/.cursor/commands/generate-blueprint.md

@@ -34,6 +34,51 @@ Avança o DARE para a fase Architect: lê `DARE/DESIGN.md` aprovado e gera **som
    - **Estratégia de Deploy** — por ambiente
    - **Checklist de Aprovação** — checkboxes para revisão humana
 
+   ---
+
+   ### 🚫 ANTI-STUB CONTRACT (regra inegociável)
+
+   > **Por que existe esta seção:** o `/generate-tasks` que vem depois usa este Blueprint como **única fonte de verdade**. Se um endpoint, função ou regra ficar genérico aqui, o agente que implementar a task **será forçado a inventar** — e vai produzir mocks, stubs e esqueletos para "preencher o vazio". Detalhe agora.
+   >
+   > Tasks que produzem mock/stub/skeleton **falham** no `dare review` (v2.17+) e bloqueiam o `dare execute --complete`.
+
+   Para **cada** endpoint, função pública, evento ou job declarado no Blueprint, especifique de forma **executável**:
+
+   **Endpoints HTTP/RPC:**
+   - Assinatura completa (método, path, headers, content-type)
+   - Request schema (campos, tipos, restrições, opcionalidade)
+   - Response schema **por status code** (2xx, 4xx, 5xx)
+   - Validações server-side (lista exaustiva — `email único`, `senha ≥ 8 chars + maiúscula + dígito`)
+   - Edge cases enumerados (input vazio, duplicado, expirado, sem permissão)
+   - Side effects (tabelas/filas/caches/emails tocados — em ordem)
+   - Exemplo concreto (payload real, response real — não placeholder)
+
+   **Funções de domínio / services:**
+   - Assinatura tipada (`fn name(args: Types) -> ReturnType`)
+   - Pré-condições e pós-condições verificáveis
+   - Estados de erro com tipo de exceção esperado
+   - Comportamento em concorrência (idempotência, locking, retry)
+
+   **Jobs / event handlers / workers:**
+   - Trigger (evento, cron, fila — nome canônico)
+   - Payload schema tipado
+   - Retry policy (backoff, max attempts, DLQ)
+   - Idempotência (chave + estratégia)
+
+   **Modelos de dados:**
+   - Cada campo: tipo, nullable, default, constraints (unique, fk, check), índices
+   - Triggers / hooks (soft-delete, audit, encryption-at-rest)
+
+   **Critério de "Blueprint detalhado o suficiente"** (auto-validação antes de salvar):
+
+   - [ ] Para cada endpoint, um humano consegue escrever request/response sem perguntar?
+   - [ ] Para cada função pública, está claro o que retorna em todos os caminhos (sucesso + erros enumerados)?
+   - [ ] Edge cases enumerados explicitamente — não "tratar edge cases"?
+   - [ ] Cada validação tem regra concreta — não só "validar email"?
+   - [ ] Cada decisão arquitetural tem **justificativa**?
+
+   **Anti-padrão a evitar:** seções como _"implementar autenticação"_ ou _"validar dados"_ — isso vira stub. Especifique algoritmo, campos, regras.
+
 4. **Salve `DARE/BLUEPRINT.md`** e informe:
 
    _"Blueprint gerado. Revise a arquitetura, os contratos de API e os critérios de DONE de cada fase. Quando aprovado, execute `/generate-tasks` para gerar o DAG e as specs de execução."_

package/templates/ide/cursor/.cursor/commands/generate-tasks.md

@@ -112,6 +112,48 @@ O `subtask_prompt` no YAML pode referenciar a spec via
 `spec_file: EXECUTION/task-<id>.md` para que o subagente leia a spec na hora
 de executar.
 
+### 5.1 ANTI-STUB CONTRACT (inegociável)
+
+> Tasks geradas com `subtask_prompt` ou spec genéricos forçam o agente a inventar — e ele vai produzir mock, stub ou esqueleto. **Não é negociável**. O comando `dare review <task-id>` (v2.17+) detecta isso e marca a task como FAILED.
+
+Cada `subtask_prompt` e `EXECUTION/task-<id>.md` deve atender este contrato:
+
+**O `subtask_prompt` deve ser auto-suficiente**
+
+O subagente recebe **apenas** o `subtask_prompt` + snippets de 2000 chars dos pais. Tudo que ele precisa para implementar **sem inventar** deve estar ali ou na `spec_file`. Inclua:
+
+- Caminho exato dos arquivos a criar/modificar
+- Assinaturas exatas das funções/endpoints (`fn name(params: T) -> R`)
+- Schema de request/response com tipos
+- Validações específicas (não "validar input" — `email: regex /^.../`, `senha: ≥ 8 chars + 1 maiúscula + 1 dígito`)
+- Edge cases enumerados (input vazio, duplicado, expirado, sem permissão)
+- Lista de testes esperados com nome + comportamento (`should_reject_duplicate_email_with_409`)
+
+**A `spec_file` (`EXECUTION/task-<id>.md`) deve ter Definition of Done anti-stub:**
+
+```markdown
+## Definition of Done (ANTI-STUB)
+
+- [ ] Nenhum `TODO`, `FIXME`, `XXX` ou `HACK` em arquivos modificados
+- [ ] Nenhuma função vazia (`fn x() {}`, `def x(): pass`, `function x() {}`)
+- [ ] Nenhum `throw new Error('not implemented')`, `unimplemented!()`, `todo!()`, `NotImplementedError`
+- [ ] Nenhum `return null` / `return undefined` / `return {}` como única statement de função pública
+- [ ] Mocks **somente** dentro de `*.test.*`, `*.spec.*`, `__tests__/`, `tests/`, `spec/` — NUNCA em código de produção
+- [ ] Todos os endpoints declarados na seção 3 retornam dados reais (não fixos / hardcoded)
+- [ ] Cada validação da spec produz erro real com status code correto (testado)
+- [ ] Cada edge case da spec tem teste unitário ou integração demonstrando comportamento
+```
+
+**Verificação automatizável:** o agente que executar a task vai rodar `dare review <id>` antes de marcar DONE. Se a review falhar, a task volta para revisão.
+
+**Sinais de spec rasa** (auto-validar antes de salvar):
+
+- ❌ "Implementar X" — sem assinatura, sem retorno, sem validações
+- ❌ "Tratar erros adequadamente" — quais erros? como? que código?
+- ❌ "Adicionar validações" — quais regras?
+- ❌ Arquivos listados sem dizer **o que cada um contém**
+- ✅ "Implementar `POST /auth/login` retornando `{ token: string, refresh: string }` com 200 se credenciais válidas, 401 se inválidas, 429 se rate limit"
+
 ### 6. Validar consistência dos 3 artefatos
 
 - Mesmos `id`s em `TASKS.md`, `dare-dag.yaml` e `EXECUTION/task-*.md`.

package/templates/ide/cursor/.cursor/commands/refine-task.md

@@ -0,0 +1,107 @@
+# Comando: /refine-task
+
+## Descrição
+
+Analisa a complexidade de uma task e, quando alta, **quebra em sub-tasks menores** com escopo bem delimitado. Pode ser chamada:
+
+- Automaticamente pela skill `/generate-tasks` após gerar o DAG (para cada task ≥ MED)
+- Manualmente pelo dev: `/refine-task task-034`
+- Após mudança de escopo: quando o BLUEPRINT mudou e uma task ficou grande
+
+A camada determinística (heurística de complexidade) é feita pelo CLI: `dare refine <id>`. Este comando adiciona a camada **semântica** — você lê a spec, decide se a quebra é necessária e produz sub-tasks coerentes.
+
+## Instruções para o Cursor Composer
+
+### 1. Rodar a heurística determinística
+
+```bash
+dare refine $ARGUMENTS --split --format json > .dare/refine-$ARGUMENTS.json
+```
+
+Esse JSON traz:
+- `report.score`, `report.level` (LOW/MED/HIGH/CRITICAL)
+- `report.signals` — explica a pontuação
+- `report.recommendsSplit` — true se HIGH/CRITICAL
+- `proposal.subtasks` — quebra inicial coarse (por diretório)
+
+### 2. Decidir se vale quebrar
+
+**Quebrar quando:**
+- `recommendsSplit: true` (HIGH/CRITICAL)
+- Mais de 6 arquivos a criar/modificar
+- Mistura responsabilidades (modelo + controller + teste + migration)
+- Inclui refactor + feature juntos
+- Keyword "pesada" (refactor/migrate/integrate) + score MED+
+
+**Manter inteira quando:**
+- LOW ou MED baixo
+- Todos arquivos no mesmo módulo
+- Cabe em uma conversa do Composer (15–60 min)
+
+### 3. Se quebrar — eixos de split
+
+| Eixo | Quando |
+|---|---|
+| **Por camada** | Modelo / Controller / Service / Test separados |
+| **Por endpoint** | 4 endpoints REST → 4 sub-tasks |
+| **Por feature** | Auth = register + login + refresh → split por verbo |
+| **Refactor + feature** | "1. refactor X" + "2. feature Y em cima" |
+| **Migration + código** | "1. migration + seeds" + "2. código novo" |
+
+Cada sub-task precisa de:
+- `subtask_prompt` auto-suficiente (Anti-Stub Contract!)
+- spec própria em `DARE/EXECUTION/<sub-id>.md`
+- `depends_on` mínimo mas correto
+- complexity honesta — se sub ainda for HIGH, quebrar de novo
+
+### 4. Emitir verdito
+
+`.dare/refine-verdict-$ARGUMENTS.json`:
+
+```json
+{
+  "manageable": false,
+  "reasons": ["Score 18 (HIGH) — 7 endpoints + migration", "Mistura refactor com features novas"],
+  "proposedSubtasks": [
+    {
+      "id": "task-034a",
+      "title": "Refactor UserService",
+      "files": ["src/services/UserService.ts", "tests/services/UserService.test.ts"],
+      "rationale": "Refactor isolado antes da feature",
+      "estimatedLevel": "MED"
+    }
+  ]
+}
+```
+
+Se manuseável:
+
+```json
+{
+  "manageable": true,
+  "reasons": ["Score 7 (MED), 4 arquivos mesmo módulo, 6 testes"]
+}
+```
+
+### 5. Aplicar o split
+
+1. Edite `DARE/dare-dag.yaml` substituindo a task pelas sub-tasks
+2. Crie as specs em `DARE/EXECUTION/<sub-id>.md` (template + Anti-Stub Contract)
+3. Atualize `DARE/TASKS.md` (visão humana)
+4. Regenere Mermaid: `dare dag viz -o DARE/dag-graph.mmd`
+5. Marque a task original como SPLIT no TASKS.md
+
+### 6. Mensagem ao usuário
+
+Manuseável:
+> ✅ Task `$ARGUMENTS` está bem-dimensionada (score X, level Y). Sem split.
+
+Quebrada:
+> 🪓 Task `$ARGUMENTS` quebrada em N sub-tasks: [lista]. Revise com `dare validate` e `dare dag viz`.
+
+## Regras inegociáveis
+
+- Não quebrar tasks LOW
+- Não inventar dependências falsas
+- Cada sub-task testável independentemente
+- Anti-Stub Contract aplica em cada sub-task

package/templates/ide/cursor/.cursor/commands/review-task.md

@@ -0,0 +1,91 @@
+# Comando: /review-task
+
+## Descrição
+
+Audita uma task **implementada** cruzando a spec (`DARE/EXECUTION/<id>.md`) com os arquivos reais que ela tocou. Detecta stubs, mocks fora de testes, funções vazias, TODOs, retorno-fantasma — **e** valida critério-a-critério se a implementação satisfaz o que a spec prometeu.
+
+Esta é a camada **semântica** do review. A camada estática (regex / patterns) já é feita automaticamente pelo CLI quando você roda `dare review <task-id>`. Este comando combina as duas: rode a estática via CLI, gere um verdito semântico aqui, e produza um relatório fundido.
+
+## Quando rodar
+
+- Antes de marcar uma task como DONE (gate obrigatório no Definition of Done do TASK-SPEC)
+- Quando o `dare review <id>` estático passa mas você quer validação adicional contra a spec
+- Quando o dev pede revisão manual: `/review-task task-034`
+
+## Instruções para o Cursor Composer
+
+### 1. Validar argumento
+
+`$ARGUMENTS` deve conter o `task-id`. Se vazio, peça.
+
+### 2. Rodar a camada estática primeiro
+
+```bash
+dare review $ARGUMENTS --format json > .dare/review-static-$ARGUMENTS.json
+```
+
+Leia esse JSON. Se houver erros estáticos, reporte-os e pergunte se quer prosseguir com a análise semântica (geralmente não vale — corrija primeiro).
+
+### 3. Carregar contexto
+
+- `DARE/EXECUTION/$ARGUMENTS.md` — spec
+- Cada arquivo listado na seção 3 da spec
+- `DARE/BLUEPRINT.md` — contratos referenciados
+
+### 4. Auditoria critério-a-critério
+
+Para **cada** item das seções abaixo da spec, marque ✅ / ❌ com evidência (arquivo + linha):
+
+- **4.1 Objetivo (seção 1):** estado observável foi atingido?
+- **4.2 Arquivos (seção 3):** todos existem com conteúdo descrito? Há arquivos extras suspeitos?
+- **4.3 Implementação (seção 4):** cada passo executado? assinaturas exatas? validações com regras concretas (não "valida email" — a regex específica)?
+- **4.4 Testes:** cada teste listado existe? Tem assertions reais? Edge cases cobertos?
+- **4.5 Segurança (seção 5):** input validation, autorização, secrets, SQL injection — tudo conforme spec?
+- **4.6 Anti-Stub (seção 7):** a camada estática já checou — só anote se você encontrar algo que regex não pegaria (ex.: dados hardcoded disfarçados de "do banco").
+
+### 5. Emitir verdito semântico
+
+Salve em `.dare/review-semantic-$ARGUMENTS.json`:
+
+```json
+{
+  "passed": true,
+  "unmetCriteria": [],
+  "notes": "Resumo de 1-3 frases do que foi verificado"
+}
+```
+
+Se algo falhou:
+
+```json
+{
+  "passed": false,
+  "unmetCriteria": [
+    "Seção 4.3: validação de senha não implementa regex de força",
+    "Seção 4.4: teste de 'email duplicado' não existe"
+  ],
+  "notes": "2 critérios não atendidos em src/auth/register.ts"
+}
+```
+
+### 6. Rodar o review fundido
+
+```bash
+dare review $ARGUMENTS --from-agent .dare/review-semantic-$ARGUMENTS.json
+```
+
+Exit code 0 = task pode ir para DONE; 1 = não pode.
+
+### 7. Mensagem final
+
+Se passou:
+> ✅ Task `$ARGUMENTS` aprovada. Marque como DONE: `dare execute --complete $ARGUMENTS`
+
+Se falhou:
+> ❌ Task `$ARGUMENTS` não passou. Itens a corrigir: [lista]. Após corrigir, rode `/review-task $ARGUMENTS` novamente.
+
+## Regras inegociáveis
+
+- **Não invente** que algo está implementado se você não viu o código.
+- **Não aceite** mocks/stubs em código de produção mesmo que "façam o teste passar".
+- **Mocks são OK** dentro de `*.test.*`, `*.spec.*`, `__tests__/`, `tests/`, `spec/`.

package/templates/ide/cursor/templates/TASK-SPEC-template.md

@@ -85,16 +85,57 @@ Execute **todos** antes de marcar a task como DONE. Se qualquer um falhar, leia
 
 ---
 
-## 7. CRITÉRIOS DE DONE
+## 7. PADRÕES PROIBIDOS (ANTI-STUB / ANTI-MOCK)
 
-- [ ] Todos os 4 validation gates passaram sem erros
-- [ ] Testes cobrem caminho feliz + erros + edge cases da seção 4
+> Esta seção é **inegociável**. O comando `dare review` (v2.17+) escaneia o código modificado por esta task e reprova se encontrar qualquer padrão abaixo.
+
+### Em código de produção (qualquer arquivo **fora** de `*.test.*`, `*.spec.*`, `__tests__/`, `tests/`, `spec/`)
+
+- ❌ **TODO / FIXME / XXX / HACK** — qualquer um desses marcadores em comentário
+- ❌ **Função vazia** — `fn x() {}`, `function x() {}`, `def x(): pass`, `def x(): ...`
+- ❌ **Stub explícito** — `throw new Error('not implemented')`, `unimplemented!()`, `todo!()`, `raise NotImplementedError`
+- ❌ **Retorno-fantasma** — `return null` / `return undefined` / `return {}` / `return []` como **única** statement de função pública declarada nesta task
+- ❌ **Mocks fora de testes** — `jest.fn()`, `sinon.stub()`, `mockReturnValue`, dados hardcoded fingindo ser do banco, fixtures injetadas em controllers/services
+- ❌ **Comentário de placeholder** — `// implement later`, `# placeholder`, `// stub`, `// FIXME implement`
+
+### Mocks são permitidos APENAS em
+
+- Arquivos de teste (`*.test.*`, `*.spec.*`, `__tests__/`, `tests/`, `spec/`)
+- Seeds / fixtures dentro de `database/seeders/`, `tests/fixtures/`
+- Helpers explicitamente marcados como auxiliares de teste
+
+### Verificação automática
+
+Antes de marcar a task como DONE, rode:
+
+```bash
+dare review <task-id>
+```
+
+Output esperado:
+
+```
+✅ task-XYZ: nenhum padrão proibido detectado em N arquivos modificados.
+```
+
+Se a review falhar, a task **não pode** ir para DONE — corrija os achados e re-rode.
+
+---
+
+## 8. CRITÉRIOS DE DONE
+
+- [ ] Todos os 4 validation gates passaram sem erros (build + test + lint + audit)
+- [ ] Testes cobrem caminho feliz + erros enumerados + edge cases da seção 4
 - [ ] Considerações de segurança da seção 5 todas checadas
 - [ ] Arquivos listados na seção 3 criados/modificados conforme spec
+- [ ] **`dare review <task-id>` passou** (seção 7 — sem stubs, mocks, TODOs)
+- [ ] Cada validação declarada na spec tem teste demonstrando o erro real (não placeholder)
+- [ ] Cada edge case enumerado tem teste cobrindo
+- [ ] Endpoints retornam dados reais do banco/service, não hardcoded
 - [ ] `DARE/TASKS.md` atualizado com status `DONE`
 
 ---
 
-## 8. PRÓXIMA TASK SUGERIDA
+## 9. PRÓXIMA TASK SUGERIDA
 
 `[task-id]` — [título] _(desbloqueada após conclusão desta task)_