@dewtech/dare-cli 2.16.0 → 3.0.0

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

@@ -1,100 +1,141 @@
-# TASK [ID]: [Título da Task]
-
-> **Complexidade:** LOW / MED / HIGH  
-> **Depends on:** [task-ids ou —]  
-> **Estimativa:** [X horas]
-
----
-
-## 1. OBJETIVO
-
-[Uma frase precisa do que esta task entrega. Deve ser verificável — termine com um estado observável, não uma ação.]
-
-Exemplo: _"Ao final desta task, o endpoint `POST /api/v1/users` aceita cadastro, valida unicidade de e-mail e retorna JWT."_
-
----
-
-## 2. CONTEXTO
-
-- **Fase no BLUEPRINT:** Fase [N] — [Nome da fase]
-- **Arquivos existentes relevantes:** [caminhos de arquivos que servem de referência ou serão modificados]
-- **Decisões do BLUEPRINT que afetam esta task:** [cite seção/decisão específica]
-
----
-
-## 3. ARQUIVOS A CRIAR / MODIFICAR
-
-| Ação | Caminho | Descrição |
-|------|---------|-----------|
-| CRIAR | `src/[módulo]/[arquivo]` | [o que contém] |
-| MODIFICAR | `src/[módulo]/[arquivo]` | [o que muda] |
-| CRIAR | `tests/[arquivo].test.[ext]` | Testes da feature |
-
----
-
-## 4. IMPLEMENTAÇÃO
-
-### Passo 1: [Nome do passo]
-[Descrição precisa do que fazer. Inclua assinaturas de função/struct se crítico.]
-
-```[lang]
-// Exemplo de padrão esperado
-```
-
-### Passo 2: [Nome do passo]
-[Descrição]
-
-### Passo 3: Testes
-- [ ] Teste do caminho feliz (`should_[comportamento]_when_[condição]`)
-- [ ] Teste de erro de validação (400 / erro de negócio)
-- [ ] Teste de autorização (401 / 403 quando aplicável)
-- [ ] Teste de edge case: [descrever]
-
----
-
-## 5. CONSIDERAÇÕES DE SEGURANÇA
-
-- [ ] **Input validation:** toda entrada do usuário validada no servidor antes de qualquer processamento
-- [ ] **Autenticação / Autorização:** verificar se o usuário tem permissão sobre o *recurso específico*, não só sobre a rota
-- [ ] **Dados sensíveis:** senhas, tokens e PII nunca aparecem em logs, responses de erro ou mensagens de exceção
-- [ ] **SQL / Command Injection:** usar ORM / prepared statements; nunca concatenar strings em queries
-- [ ] **Dependências novas:** se esta task adicionar uma dependência, verificar CVEs com `npm audit` / `cargo audit` / `pip-audit` antes de commitar
-- [ ] **Segredo em código:** nenhum token, chave ou credencial hardcoded — sempre via variável de ambiente
-
----
-
-## 6. VALIDATION GATES (RALPH LOOP)
-
-Execute **todos** antes de marcar a task como DONE. Se qualquer um falhar, leia o erro, corrija e reexecute.
-
-```bash
-# 1. Build — sem erros de compilação
-[comando de build da stack]
-
-# 2. Tests — todos passando, incluindo os novos
-[comando de test]
-
-# 3. Lint — sem warnings
-[comando de lint]
-
-# 4. Auditoria de dependências (se novas deps foram adicionadas nesta task)
-[npm audit --audit-level=high | cargo audit | pip-audit | composer audit]
-```
-
-> **Gate de segurança obrigatório:** se esta task adicionar dependências externas, `[audit-cmd]` não pode retornar CVE de nível HIGH ou CRITICAL.
-
----
-
-## 7. CRITÉRIOS DE DONE
-
-- [ ] Todos os 4 validation gates passaram sem erros
-- [ ] Testes cobrem caminho feliz + erros + 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/TASKS.md` atualizado com status `DONE`
-
----
-
-## 8. PRÓXIMA TASK SUGERIDA
-
-`[task-id]` — [título] _(desbloqueada após conclusão desta task)_
+# TASK [ID]: [Título da Task]
+
+> **Complexidade:** LOW / MED / HIGH  
+> **Depends on:** [task-ids ou —]  
+> **Estimativa:** [X horas]
+
+---
+
+## 1. OBJETIVO
+
+[Uma frase precisa do que esta task entrega. Deve ser verificável — termine com um estado observável, não uma ação.]
+
+Exemplo: _"Ao final desta task, o endpoint `POST /api/v1/users` aceita cadastro, valida unicidade de e-mail e retorna JWT."_
+
+---
+
+## 2. CONTEXTO
+
+- **Fase no BLUEPRINT:** Fase [N] — [Nome da fase]
+- **Arquivos existentes relevantes:** [caminhos de arquivos que servem de referência ou serão modificados]
+- **Decisões do BLUEPRINT que afetam esta task:** [cite seção/decisão específica]
+
+---
+
+## 3. ARQUIVOS A CRIAR / MODIFICAR
+
+| Ação | Caminho | Descrição |
+|------|---------|-----------|
+| CRIAR | `src/[módulo]/[arquivo]` | [o que contém] |
+| MODIFICAR | `src/[módulo]/[arquivo]` | [o que muda] |
+| CRIAR | `tests/[arquivo].test.[ext]` | Testes da feature |
+
+---
+
+## 4. IMPLEMENTAÇÃO
+
+### Passo 1: [Nome do passo]
+[Descrição precisa do que fazer. Inclua assinaturas de função/struct se crítico.]
+
+```[lang]
+// Exemplo de padrão esperado
+```
+
+### Passo 2: [Nome do passo]
+[Descrição]
+
+### Passo 3: Testes
+- [ ] Teste do caminho feliz (`should_[comportamento]_when_[condição]`)
+- [ ] Teste de erro de validação (400 / erro de negócio)
+- [ ] Teste de autorização (401 / 403 quando aplicável)
+- [ ] Teste de edge case: [descrever]
+
+---
+
+## 5. CONSIDERAÇÕES DE SEGURANÇA
+
+- [ ] **Input validation:** toda entrada do usuário validada no servidor antes de qualquer processamento
+- [ ] **Autenticação / Autorização:** verificar se o usuário tem permissão sobre o *recurso específico*, não só sobre a rota
+- [ ] **Dados sensíveis:** senhas, tokens e PII nunca aparecem em logs, responses de erro ou mensagens de exceção
+- [ ] **SQL / Command Injection:** usar ORM / prepared statements; nunca concatenar strings em queries
+- [ ] **Dependências novas:** se esta task adicionar uma dependência, verificar CVEs com `npm audit` / `cargo audit` / `pip-audit` antes de commitar
+- [ ] **Segredo em código:** nenhum token, chave ou credencial hardcoded — sempre via variável de ambiente
+
+---
+
+## 6. VALIDATION GATES (RALPH LOOP)
+
+Execute **todos** antes de marcar a task como DONE. Se qualquer um falhar, leia o erro, corrija e reexecute.
+
+```bash
+# 1. Build — sem erros de compilação
+[comando de build da stack]
+
+# 2. Tests — todos passando, incluindo os novos
+[comando de test]
+
+# 3. Lint — sem warnings
+[comando de lint]
+
+# 4. Auditoria de dependências (se novas deps foram adicionadas nesta task)
+[npm audit --audit-level=high | cargo audit | pip-audit | composer audit]
+```
+
+> **Gate de segurança obrigatório:** se esta task adicionar dependências externas, `[audit-cmd]` não pode retornar CVE de nível HIGH ou CRITICAL.
+
+---
+
+## 7. PADRÕES PROIBIDOS (ANTI-STUB / ANTI-MOCK)
+
+> 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`
+
+---
+
+## 9. PRÓXIMA TASK SUGERIDA
+
+`[task-id]` — [título] _(desbloqueada após conclusão desta task)_

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

@@ -0,0 +1,131 @@
+# /dare-ax
+
+Audita ou bootstrapa um projeto DARE com foco em **Agent Experience (AX)** — os sinais estruturados que agentes de código (Claude Code, Cursor, Antigravity) precisam para trabalhar sem refactor desnecessário.
+
+## Como usar
+
+```
+/dare-ax                          # audita projeto atual
+/dare-ax init                     # cria llms.txt + .env.example + ajustes mínimos
+/dare-ax openapi                  # valida ou gera openapi.json
+/dare-ax cli                      # adiciona --json em comandos CLI faltantes
+```
+
+## Os três planos AX
+
+### 1. Discovery — agente acha o que precisa
+
+- `llms.txt` na raiz com descrição, comandos, endpoints
+- `README.md` com bootstrap em 5 minutos
+- Estrutura de pastas previsível (`src/`, `tests/`, `docs/`, `DARE/`)
+
+### 2. Usage — agente consegue operar
+
+- `openapi.json` em `/openapi.json` (HTTP)
+- Flag `--json` em todos os CLIs
+- `Dockerfile` + `docker-compose.yml` validados
+- `.env.example` versionado
+
+### 3. Defense — agente não quebra produção
+
+- Rate limit (rack-attack, express-rate-limit, tower-governor, slowapi)
+- Validação de input (FormRequests, Pydantic, Zod, serde+validator)
+- Secrets só via env
+- `llms.txt` sem credenciais (scan no CI)
+
+## Métricas obrigatórias
+
+| ID | Métrica | Como verificar |
+|---|---|---|
+| M-01 | `llms.txt` existe e é válido (sem secrets, seções obrigatórias) | grep + parse |
+| M-02 | `openapi.json` ou `public/openapi.json` existe | `test -f` |
+| M-03 | CLI suporta `--json` | `cli --help \| grep '\-\-json'` |
+| M-04 | Rate limit configurado | grep pelo middleware da stack |
+
+Falha em CI se M-01 ou M-04 falharem em produção.
+
+## O que fazer
+
+### Passo 1: Auditar o projeto
+
+Confira na ordem:
+1. Existe `llms.txt`? Está atualizado?
+2. Existe `openapi.json` se o projeto expõe HTTP?
+3. Todos os CLIs aceitam `--json`?
+4. Existe rate limit em endpoints autenticados públicos?
+5. `.env.example` está versionado sem valores reais?
+
+### Passo 2: Gerar `llms.txt` se faltar
+
+Use este template — preencha apenas com comandos e endpoints que **existem de verdade**:
+
+```
+# <nome-do-projeto>
+
+> <descrição em 1-2 frases>
+
+## Stack
+- <linguagem + framework>
+- <banco>
+- <cache/fila>
+
+## Bootstrap
+- `make setup`
+- `make dev`
+- `make test`
+
+## Endpoints
+- `GET /healthz`
+- `GET /openapi.json`
+- `POST /api/login`
+
+## Docs
+- DARE/DESIGN.md
+- DARE/BLUEPRINT.md
+- docs/RUNBOOK.md
+```
+
+### Passo 3: Validar / gerar OpenAPI
+
+- **Node/NestJS** — `@nestjs/swagger`
+- **FastAPI** — automático em `/openapi.json`
+- **Rails** — `grape-swagger` ou `rswag`
+- **Rust/Axum** — `utoipa` + `utoipa-swagger-ui`
+- **Laravel** — `darkaonline/l5-swagger`
+
+### Passo 4: Adicionar `--json` no CLI
+
+Para cada comando:
+- Imprime JSON puro em stdout (sem cores ANSI, sem prompt)
+- Exit code 0 em sucesso, ≠ 0 em erro
+- Schema documentado no `llms.txt`
+
+### Passo 5: Configurar rate limit
+
+Adicione middleware específico da stack para todos os endpoints públicos. Padrão recomendado:
+- Login: 5 req / 15 min por IP + por usuário
+- API geral: 100 req / min por usuário autenticado
+
+## Antipatterns a evitar
+
+| AP | Por que evitar |
+|---|---|
+| Docs fora do código | Divergem |
+| OpenAPI à mão | Desatualiza |
+| CLI sem `--json` | Parsing regex frágil |
+| Rate limit só em dev | Produção vira target |
+| `llms.txt` com secrets | Credencial exposta |
+| CORS `*` em prod | Origem qualquer |
+
+## Saída esperada
+
+Reporte numerado dos 4 checks (M-01 a M-04). Para cada falha, mostre:
+- O que falta
+- Como corrigir (com comando concreto da stack)
+- Quem deve aprovar antes do CI travar release
+
+$ARGUMENTS
+
+---
+
+Skill MIT — parte do DARE Method.

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

@@ -1,78 +1,134 @@
-# /dare-blueprint
-
-Gera **somente** `DARE/BLUEPRINT.md` a partir do `DARE/DESIGN.md`.
-
-> Tasks, DAG e specs de execução são geradas depois com `/dare-tasks`, após aprovação humana do Blueprint.
-
-## Como usar
-
-```
-/dare-blueprint
-/dare-blueprint --stack node-nestjs+react
-```
-
-## O que fazer
-
-### 1. Ler `DARE/DESIGN.md`
-
-Obrigatório. Se não existir, peça para rodar `/dare-design` primeiro.
-
-Extraia e use durante todo o comando:
-- Stack técnica (linguagem, framework, versões)
-- Requisitos funcionais priorizados (RF-*)
-- Requisitos de segurança (RS-*)
-- Integrações externas confirmadas
-- Restrições e escopo
-
-### 2. Gerar `DARE/BLUEPRINT.md`
-
-Siga o template `templates/BLUEPRINT-template.md`. Seções obrigatórias:
-
-**2.1 Visão Geral da Arquitetura**
-- Diagrama Mermaid da arquitetura
-- Tabela de decisões arquiteturais com justificativa (não apenas "escolha X")
-
-**2.2 Stack Técnica Definida** — versões fixas, não ranges
-
-**2.3 Estrutura de Pastas** — árvore completa dos arquivos que serão criados
-
-**2.4 Modelo de Dados** — entidades, campos tipados, relacionamentos, índices necessários
-
-**2.5 Contratos de API** — tabela completa: método, rota, auth, request body, response, status codes
-
-**2.6 Plano de Execução (Fases)** — cada fase com:
-- Nome e objetivo
-- **Critério de DONE** — comportamento verificável e testável (não "código feito")
-- Lista de entregáveis concretos
-
-  > **Fase 1 é sempre containerização** (Dockerfile + docker-compose + healthcheck)
-  > **Fase N-1 é sempre auditoria de segurança e dependências**
-
-**2.7 Validation Gates por Stack**
-
-| Stack | Build | Test | Lint/Audit |
-|-------|-------|------|------------|
-| Rust/Axum | `cargo build` | `cargo test --workspace` | `cargo clippy && cargo audit` |
-| Node/NestJS | `npm run build` | `npm test` | `npx eslint src && npm audit --audit-level=high` |
-| Python/FastAPI | verificar imports | `pytest` | `ruff check . && pip-audit` |
-| PHP/Laravel | `php artisan config:cache` | `php artisan test` | `./vendor/bin/phpstan && composer audit` |
-| Go | `go build ./...` | `go test ./...` | `golangci-lint run` |
-
-**2.8 Controles de Segurança** — checklist com todos os RS-* do DESIGN mapeados para fases específicas
-
-**2.9 Estratégia de Testes** — unitários + integração + segurança (auditoria de deps) + E2E se frontend
-
-**2.10 Estratégia de Deploy** — por ambiente com branch, trigger e infra
-
-**2.11 Checklist de Aprovação** — checkboxes para o usuário revisar antes de prosseguir
-
-### 3. Salvar e aguardar aprovação humana
-
-Salve `DARE/BLUEPRINT.md` e informe:
-
-_"Blueprint gerado. Revise a arquitetura, os contratos de API e os critérios de DONE de cada fase — especialmente as tasks de complexidade HIGH. Quando aprovado, rode `/dare-tasks` para gerar o DAG e as specs de execução."_
-
-**Não gere** `DARE/TASKS.md`, `DARE/dare-dag.yaml` nem arquivos em `DARE/EXECUTION/`.
-Esses artefatos são responsabilidade exclusiva do `/dare-tasks`.
-
-$ARGUMENTS
+# /dare-blueprint
+
+Gera **somente** `DARE/BLUEPRINT.md` a partir do `DARE/DESIGN.md`.
+
+> Tasks, DAG e specs de execução são geradas depois com `/dare-tasks`, após aprovação humana do Blueprint.
+
+## Como usar
+
+```
+/dare-blueprint
+/dare-blueprint --stack node-nestjs+react
+```
+
+## O que fazer
+
+### 1. Ler `DARE/DESIGN.md`
+
+Obrigatório. Se não existir, peça para rodar `/dare-design` primeiro.
+
+Extraia e use durante todo o comando:
+- Stack técnica (linguagem, framework, versões)
+- Requisitos funcionais priorizados (RF-*)
+- Requisitos de segurança (RS-*)
+- Integrações externas confirmadas
+- Restrições e escopo
+
+### 2. Gerar `DARE/BLUEPRINT.md`
+
+Siga o template `templates/BLUEPRINT-template.md`. Seções obrigatórias:
+
+**2.1 Visão Geral da Arquitetura**
+- Diagrama Mermaid da arquitetura
+- Tabela de decisões arquiteturais com justificativa (não apenas "escolha X")
+
+**2.2 Stack Técnica Definida** — versões fixas, não ranges
+
+**2.3 Estrutura de Pastas** — árvore completa dos arquivos que serão criados
+
+**2.4 Modelo de Dados** — entidades, campos tipados, relacionamentos, índices necessários
+
+**2.5 Contratos de API** — tabela completa: método, rota, auth, request body, response, status codes
+
+**2.6 Plano de Execução (Fases)** — cada fase com:
+- Nome e objetivo
+- **Critério de DONE** — comportamento verificável e testável (não "código feito")
+- Lista de entregáveis concretos
+
+  > **Fase 1 é sempre containerização** (Dockerfile + docker-compose + healthcheck)
+  > **Fase N-1 é sempre auditoria de segurança e dependências**
+
+**2.7 Validation Gates por Stack**
+
+| Stack | Build | Test | Lint/Audit |
+|-------|-------|------|------------|
+| Rust/Axum | `cargo build` | `cargo test --workspace` | `cargo clippy && cargo audit` |
+| Node/NestJS | `npm run build` | `npm test` | `npx eslint src && npm audit --audit-level=high` |
+| Python/FastAPI | verificar imports | `pytest` | `ruff check . && pip-audit` |
+| PHP/Laravel | `php artisan config:cache` | `php artisan test` | `./vendor/bin/phpstan && composer audit` |
+| Go | `go build ./...` | `go test ./...` | `golangci-lint run` |
+
+**2.8 Controles de Segurança** — checklist com todos os RS-* do DESIGN mapeados para fases específicas
+
+**2.9 Estratégia de Testes** — unitários + integração + segurança (auditoria de deps) + E2E se frontend
+
+**2.10 Estratégia de Deploy** — por ambiente com branch, trigger e infra
+
+**2.11 Checklist de Aprovação** — checkboxes para o usuário revisar antes de prosseguir
+
+---
+
+## 🚫 ANTI-STUB CONTRACT (regra inegociável)
+
+> **Por que existe esta seção:** o `/dare-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` (introduzido na 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**:
+
+### Para endpoints HTTP/RPC
+
+- **Assinatura completa:** método, path, headers obrigatórios, content-type
+- **Request schema:** todos os campos com tipo, restrições (min/max/regex), opcionalidade
+- **Response schema por status code:** estrutura para 2xx, 4xx, 5xx — não apenas "200 OK"
+- **Validações server-side:** lista exaustiva de regras (`email único`, `senha ≥ 8 chars + 1 maiúscula + 1 dígito`, etc.)
+- **Edge cases enumerados:** o que acontece com input vazio, duplicado, expirado, sem permissão, com dados inconsistentes
+- **Side effects:** que tabelas/filas/caches/emails são tocados — em ordem
+- **Exemplo concreto (não placeholder):** payload real, response real
+
+### Para funções de domínio / services
+
+- **Assinatura tipada** (`fn name(args: Types) -> ReturnType` ou equivalente)
+- **Pré-condições** verificáveis (estado obrigatório do banco/cache/etc.)
+- **Pós-condições** verificáveis (o que muda no sistema após retornar OK)
+- **Estados de erro** com tipo de exceção/Result/Either esperado
+- **Comportamento em concorrência** quando relevante (idempotência, locking, retry)
+
+### Para jobs / event handlers / workers
+
+- **Trigger:** evento, cron, fila — incluir o **nome canônico**
+- **Payload schema** com tipos
+- **Retry policy** (backoff, max attempts, DLQ)
+- **Idempotência:** chave + estratégia
+- **SLA / timeout**
+
+### Para modelos de dados
+
+- Cada campo: tipo, nullable, default, constraints (unique, fk, check), índices
+- Triggers ou hooks (soft-delete, audit, encryption-at-rest)
+- Estado inicial / seed obrigatório (se aplicável)
+
+### Critério de "Blueprint detalhado o suficiente"
+
+Antes de salvar, valide internamente — se a resposta a **qualquer** pergunta abaixo for "não", o Blueprint ainda está raso e precisa ser expandido:
+
+- [ ] Para cada endpoint, um humano não-familiarizado consegue escrever request/response sem perguntar nada?
+- [ ] Para cada função pública, está claro **o que retorna** em todos os caminhos (sucesso + erros enumerados)?
+- [ ] Edge cases foram **enumerados** ou só listados como "tratar edge cases"?
+- [ ] Cada validação tem uma regra concreta (não "validar email" — `^[a-z0-9._%+-]+@...`)?
+- [ ] Cada decisão arquitetural tem **justificativa** (não só "escolhemos X")?
+
+**Anti-padrão a evitar:** seções como _"implementar autenticação"_ ou _"validar dados"_ — isso vai virar stub. Especifique **qual** algoritmo, **quais** campos, **quais** regras.
+
+---
+
+### 3. Salvar e aguardar aprovação humana
+
+Salve `DARE/BLUEPRINT.md` e informe:
+
+_"Blueprint gerado. Revise a arquitetura, os contratos de API e os critérios de DONE de cada fase — especialmente as tasks de complexidade HIGH. Quando aprovado, rode `/dare-tasks` para gerar o DAG e as specs de execução."_
+
+**Não gere** `DARE/TASKS.md`, `DARE/dare-dag.yaml` nem arquivos em `DARE/EXECUTION/`.
+Esses artefatos são responsabilidade exclusiva do `/dare-tasks`.
+
+$ARGUMENTS