@dewtech/dare-cli 2.17.0 → 3.1.0

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

@@ -1,141 +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. 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)_
+# 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/cursor/.cursor/commands/dag-viz.md

@@ -0,0 +1,139 @@
+# Comando: /dag-viz
+
+## Descrição
+
+Gera diagrama interativo `.excalidraw` a partir do `DARE/dare-dag.yaml` atual. Cada task vira um retângulo com cor baseada em complexidade e status visual, agrupado em colunas verticais (swim lanes) por rank, com setas conectando dependências.
+
+## Instruções para o Cursor Composer
+
+1. **Leia o DAG:** Abra `DARE/dare-dag.yaml`. Valide sintaxe YAML. Extraia tasks, complexidade, dependências e status.
+
+2. **Leia a skill de visualização:** Consulte `.cursor/rules/skill-dag-viz.mdc` (se existir) para convenções visuais e tokens de design.
+
+3. **Calcule ranks:**
+   - Tasks sem `depends_on` → rank 1
+   - Demais: rank = 1 + max(rank das dependências)
+   - Agrupe por rank para formar swim lanes verticais
+
+4. **Gere elementos Excalidraw:**
+   - Para cada task, crie retângulo 120×60px:
+     - Cor de fundo por `complexity`:
+       - LOW → azul `#e3f2fd`, stroke `#1976d2`
+       - MEDIUM → laranja `#fff3e0`, stroke `#f57c00`
+       - HIGH → rosa `#fce4ec`, stroke `#c2185b`
+     - Stroke por `status`:
+       - PENDING → linha sólida cinza padrão
+       - RUNNING → linha pontilhada azul
+       - DONE → linha sólida verde `#388e3c`
+       - FAILED → linha sólida vermelha `#d32f2f`
+     - Texto: `task-id\ntask-name\n[COMPLEXITY]`
+   - Para cada dependência em `depends_on`, crie seta de source → target, stroke cinza `#999`.
+
+5. **Posicione elementos:**
+   - X = 20 + (taskIndex_no_rank × 140)
+   - Y = 20 + (rank − 1) × 160
+
+6. **Salve:** Escreva resultado em `DARE/dag-graph.excalidraw` no formato JSON Excalidraw 2.x.
+
+7. **Mensagem final:**
+   ```
+   DAG gerado: DARE/dag-graph.excalidraw
+   Abra em https://excalidraw.com (File → Open) para visualizar e editar.
+   ```
+
+## Estrutura JSON Excalidraw esperada
+
+```json
+{
+  "type": "excalidraw",
+  "version": 2,
+  "source": "dare-dag-viz",
+  "elements": [
+    {
+      "id": "task-001",
+      "type": "rectangle",
+      "x": 20, "y": 20,
+      "width": 120, "height": 60,
+      "backgroundColor": "#e3f2fd",
+      "strokeColor": "#1976d2",
+      "strokeStyle": "solid",
+      "fillStyle": "solid",
+      "roundness": { "type": 2, "value": 6 }
+    },
+    {
+      "type": "text",
+      "x": 25, "y": 25,
+      "text": "task-001\nSetup Auth\n[LOW]",
+      "fontSize": 12,
+      "containerId": "task-001"
+    },
+    {
+      "type": "arrow",
+      "startBinding": { "elementId": "task-001" },
+      "endBinding": { "elementId": "task-003" },
+      "strokeColor": "#999"
+    }
+  ],
+  "appState": {
+    "gridMode": "grid",
+    "gridSize": 20
+  },
+  "files": {}
+}
+```
+
+## Campos esperados em `dare-dag.yaml`
+
+```yaml
+tasks:
+  task-001:
+    name: "Setup Auth"
+    complexity: "LOW"          # LOW | MEDIUM | HIGH
+    rank: 1                    # opcional (calculado se ausente)
+    depends_on: []             # default []
+    status: "DONE"             # PENDING | RUNNING | DONE | FAILED (default PENDING)
+    subtask_prompt: "..."      # opcional
+```
+
+**Obrigatórios:** `name`, `complexity`.
+**Opcionais:** `rank`, `depends_on`, `status`.
+
+## Como abrir o resultado
+
+1. Acesse https://excalidraw.com
+2. File → Open → selecione `DARE/dag-graph.excalidraw`
+3. Edite livremente (mover, colorir, anotar)
+4. Salve no mesmo arquivo
+
+## Atualizar após mudanças
+
+Sempre que `dare-dag.yaml` for modificado, rode `/dag-viz` para regenerar.
+
+> Dica: faça backup se editou manualmente — a regeneração sobrescreve.
+
+## Troubleshooting
+
+- **"File not found: DARE/dare-dag.yaml"** — projeto não tem DAG. Rode `/generate-tasks` primeiro para gerá-lo.
+- **"JSON inválido"** — valide com `dare dag validate` (se CLI disponível) ou inspecione manualmente.
+- **Diagrama muito grande** — abra em Excalidraw e ajuste com Ctrl+Mouse / pinch zoom.
+
+## Convenções visuais
+
+- **Azul** (`#e3f2fd`) = LOW complexity
+- **Laranja** (`#fff3e0`) = MEDIUM
+- **Rosa** (`#fce4ec`) = HIGH
+- **Verde** (`#388e3c`) = DONE
+- **Vermelho** (`#d32f2f`) = FAILED
+- **Pontilhado azul** = RUNNING
+- **Cinza padrão** = PENDING
+
+## Próximos passos
+
+- Exporte para PNG no Excalidraw para incluir em README ou PR
+- Compartilhe o link colaborativo do Excalidraw com stakeholders
+- Atualize após cada `/generate-tasks` ou `/run-dag`
+
+---
+
+Skill MIT — parte do DARE Method.
+Inspiração: [Excalidraw Diagram Skill](https://github.com/coleam00/excalidraw-diagram-skill) por Cole Medin.

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

@@ -1,86 +1,86 @@
-# Comando: /generate-blueprint
-
-## Descrição
-Avança o DARE para a fase Architect: lê `DARE/DESIGN.md` aprovado e gera **somente** `DARE/BLUEPRINT.md`.
-
-> As tasks, DAG e specs de execução são geradas depois com `/generate-tasks`, após você revisar e aprovar o Blueprint.
-
-## Instruções para o Cursor Composer
-
-1. **Leia `DARE/DESIGN.md`** — obrigatório. Se não existir, peça `/generate-design` primeiro. Extraia: stack, RF-*, RNF-*, RS-*, integrações, restrições, escopo.
-
-2. **Leia o template:** `templates/BLUEPRINT-template.md` — siga a estrutura fielmente.
-
-3. **Gere `DARE/BLUEPRINT.md`** com seções obrigatórias:
-
-   - **Visão Geral da Arquitetura** — diagrama Mermaid + tabela de decisões com justificativa
-   - **Stack Técnica Definida** — versões fixas (não ranges)
-   - **Estrutura de Pastas** — árvore completa dos arquivos a criar
-   - **Modelo de Dados** — entidades, campos tipados, relacionamentos, índices
-   - **Contratos de API** — método, rota, auth, request/response, status codes
-   - **Plano de Execução (Fases)** — cada fase com critério de DONE verificável:
-     - Fase 1 = containerização (Dockerfile + docker-compose + healthcheck) — sempre
-     - Fase N-1 = auditoria de segurança + dependências — sempre
-   - **Validation Gates por stack:**
-     | Stack | Build | Test | Lint/Audit |
-     |-------|-------|------|------------|
-     | Rust | `cargo build` | `cargo test --workspace` | `cargo clippy && cargo audit` |
-     | Node | `npm run build` | `npm test` | `npx eslint src && npm audit --audit-level=high` |
-     | Python | verificar imports | `pytest` | `ruff check . && pip-audit` |
-     | PHP | `php artisan config:cache` | `php artisan test` | `./vendor/bin/phpstan && composer audit` |
-     | Go | `go build ./...` | `go test ./...` | `golangci-lint run` |
-   - **Controles de Segurança** — checklist mapeando cada RS-* do DESIGN para fases específicas
-   - **Estratégia de Testes** — unitários + integração + auditoria de deps + E2E
-   - **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."_
-
-**Não gere** `TASKS.md`, `dare-dag.yaml` nem arquivos em `EXECUTION/` — isso é responsabilidade do `/generate-tasks`.
+# Comando: /generate-blueprint
+
+## Descrição
+Avança o DARE para a fase Architect: lê `DARE/DESIGN.md` aprovado e gera **somente** `DARE/BLUEPRINT.md`.
+
+> As tasks, DAG e specs de execução são geradas depois com `/generate-tasks`, após você revisar e aprovar o Blueprint.
+
+## Instruções para o Cursor Composer
+
+1. **Leia `DARE/DESIGN.md`** — obrigatório. Se não existir, peça `/generate-design` primeiro. Extraia: stack, RF-*, RNF-*, RS-*, integrações, restrições, escopo.
+
+2. **Leia o template:** `templates/BLUEPRINT-template.md` — siga a estrutura fielmente.
+
+3. **Gere `DARE/BLUEPRINT.md`** com seções obrigatórias:
+
+   - **Visão Geral da Arquitetura** — diagrama Mermaid + tabela de decisões com justificativa
+   - **Stack Técnica Definida** — versões fixas (não ranges)
+   - **Estrutura de Pastas** — árvore completa dos arquivos a criar
+   - **Modelo de Dados** — entidades, campos tipados, relacionamentos, índices
+   - **Contratos de API** — método, rota, auth, request/response, status codes
+   - **Plano de Execução (Fases)** — cada fase com critério de DONE verificável:
+     - Fase 1 = containerização (Dockerfile + docker-compose + healthcheck) — sempre
+     - Fase N-1 = auditoria de segurança + dependências — sempre
+   - **Validation Gates por stack:**
+     | Stack | Build | Test | Lint/Audit |
+     |-------|-------|------|------------|
+     | Rust | `cargo build` | `cargo test --workspace` | `cargo clippy && cargo audit` |
+     | Node | `npm run build` | `npm test` | `npx eslint src && npm audit --audit-level=high` |
+     | Python | verificar imports | `pytest` | `ruff check . && pip-audit` |
+     | PHP | `php artisan config:cache` | `php artisan test` | `./vendor/bin/phpstan && composer audit` |
+     | Go | `go build ./...` | `go test ./...` | `golangci-lint run` |
+   - **Controles de Segurança** — checklist mapeando cada RS-* do DESIGN para fases específicas
+   - **Estratégia de Testes** — unitários + integração + auditoria de deps + E2E
+   - **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."_
+
+**Não gere** `TASKS.md`, `dare-dag.yaml` nem arquivos em `EXECUTION/` — isso é responsabilidade do `/generate-tasks`.