@dewtech/dare-cli 3.2.0 → 3.4.0

package/templates/ide/antigravity/.agents/skills/dare-dag-run/SKILL.md

@@ -1,130 +1,130 @@
----
-name: dare-dag-run
-description: Executa o grafo de tasks definido em DARE/dare-dag.yaml usando Antigravity como executor e o CLI dare como orquestrador. Sem API keys — usa o plano nativo da IDE. O canvas ao vivo fica em DARE/.canvas.md.
----
-
-# DARE DAG Run Skill
-
-Você é o executor da fase EXECUTE do método DARE no Antigravity. Esta skill **executa APENAS** o grafo que já foi construído — não regenera o `dare-dag.yaml`, não modifica o BLUEPRINT, não cria specs novas. Apenas roda as tasks na ordem topológica correta.
-
-> Se você precisa **(re)construir** o grafo, use `dare-dag-build`.
-> Se você precisa **visualizar** o grafo, use `dare-dag-viz`.
-> Se você precisa **fazer tudo** (build + run num passo), use `dare-dag-runner`.
-
-> **Sem API keys.** Você (Antigravity) usa o plano nativo da IDE. O CLI `dare` apenas coordena estado, monta prompts e atualiza o canvas.
-
-## Quando usar esta skill
-
-- `DARE/dare-dag.yaml` está aprovado e pronto
-- As specs em `DARE/EXECUTION/task-<id>.md` estão geradas
-- É hora de implementar as tasks na ordem do grafo
-- O usuário aprovou os ANTI-STUB contracts
-
-## Pré-requisitos
-
-- `DARE/dare-dag.yaml` existe e foi aprovado pelo usuário
-- Specs em `DARE/EXECUTION/task-<id>.md` geradas (se não, use `dare-dag-build`)
-- `dare` disponível no PATH (`npm i -g @dewtech/dare-cli`)
-
-## Como usar
-
-```
-Invoque a skill com:
-- (sem args) — executa todas as ready do próximo rank
-- --task task-003 — executa só uma task específica
-```
-
-### Passo 1 — Validar pré-condições
-
-- Confirme que `DARE/dare-dag.yaml` existe. Se não, oriente o usuário a invocar `dare-blueprint` ou `dare-dag-build`
-- Leia o YAML e verifique: sem ciclos, ids únicos, ranks paralelizáveis
-- Liste rapidamente para o usuário: total de tasks, ranks, próximas ready
-
-### Passo 2 — Pegar próximas tasks
-
-```bash
-dare execute --next
-```
-
-O CLI imprime as tasks **ready** do rank atual com o prompt completo (snippets de até 2000 chars dos outputs dos pais já costurados). Use esses prompts diretamente — não reescreva.
-
-### Passo 3 — Sugerir abrir o canvas
-
-Antes de começar, peça ao usuário abrir `DARE/.canvas.md` em outra aba do Antigravity. Esse é o feedback visual ao vivo da execução.
-
-### Passo 4 — Executar cada task
-
-Para cada task ready:
-
-1. Leia `spec_file` se houver (`DARE/EXECUTION/task-<id>.md`)
-2. Implemente conforme o `subtask_prompt` — **não invente, não use mock fora de tests, sem TODOs**
-3. Rode o Ralph Loop completo: build → test → lint
-4. Registre o resultado no CLI:
-
-```bash
-# Sucesso
-dare execute --complete task-001 --output "Resumo curto + arquivos criados/modificados (paths)"
-
-# Falha
-dare execute --fail task-002 --reason "Mensagem clara da falha (compilação? teste? lint?)"
-```
-
-### Passo 5 — Avançar de rank
-
-```bash
-dare execute --next
-```
-
-- Se aparecer `✅ All tasks resolved`, todas terminaram. Reporte o resumo.
-- Caso contrário, continue executando o próximo rank.
-
-### Passo 6 — Pós-execução
-
-```bash
-dare execute --status
-```
-
-Mostra snapshot do canvas + sumário (X DONE, Y FAILED, Z SKIPPED).
-
-Para retentar tasks FAILED:
-
-```bash
-dare execute --reset task-002
-dare execute --next
-```
-
-## Comandos do orquestrador `dare`
-
-| Comando | Função |
-|---------|--------|
-| `dare execute --next` | Próximas tasks ready com prompts compostos |
-| `dare execute --complete <id> --output "..."` | Marca DONE |
-| `dare execute --fail <id> --reason "..."` | Marca FAILED + cascade-skip |
-| `dare execute --reset <id>` | Volta para PENDING |
-| `dare execute --status` | Snapshot do canvas + sumário |
-
-## Erros comuns
-
-| Sintoma | Causa | Correção |
-|---------|-------|----------|
-| `dare-dag.yaml not found` | Não foi gerado | Invoque `dare-blueprint` ou `dare-dag-build` |
-| Cascata de SKIPPED | Pai falhou | Corrija pai → `dare execute --reset` → `--next` |
-| Output truncado | Cap de 4000 chars | Escreva em arquivo, retorne resumo |
-| Spec inconsistente | TASKS.md ≠ dare-dag.yaml | Re-gere com `dare-dag-build` |
-
-## Referências
-
-- Schema: `DARE/dare-dag.yaml`
-- Canvas: `DARE/.canvas.md`
-- Specs: `DARE/EXECUTION/task-*.md`
-- Status: `DARE/TASKS.md`
-
-## Quando NÃO usar esta skill
-
-- Se `dare-dag.yaml` não existe — use `dare-blueprint` ou `dare-dag-build`
-- Se você quer só visualizar o grafo — use `dare-dag-viz`
-- Se você quer build + run num único passo — use `dare-dag-runner`
-
-## Licença
-
-Esta skill é parte do DARE Method e está sob licença MIT (D-001).
+---
+name: dare-dag-run
+description: Executa o grafo de tasks definido em DARE/dare-dag.yaml usando Antigravity como executor e o CLI dare como orquestrador. Sem API keys — usa o plano nativo da IDE. O canvas ao vivo fica em DARE/.canvas.md.
+---
+
+# DARE DAG Run Skill
+
+Você é o executor da fase EXECUTE do método DARE no Antigravity. Esta skill **executa APENAS** o grafo que já foi construído — não regenera o `dare-dag.yaml`, não modifica o BLUEPRINT, não cria specs novas. Apenas roda as tasks na ordem topológica correta.
+
+> Se você precisa **(re)construir** o grafo, use `dare-dag-build`.
+> Se você precisa **visualizar** o grafo, use `dare-dag-viz`.
+> Se você precisa **fazer tudo** (build + run num passo), use `dare-dag-runner`.
+
+> **Sem API keys.** Você (Antigravity) usa o plano nativo da IDE. O CLI `dare` apenas coordena estado, monta prompts e atualiza o canvas.
+
+## Quando usar esta skill
+
+- `DARE/dare-dag.yaml` está aprovado e pronto
+- As specs em `DARE/EXECUTION/task-<id>.md` estão geradas
+- É hora de implementar as tasks na ordem do grafo
+- O usuário aprovou os ANTI-STUB contracts
+
+## Pré-requisitos
+
+- `DARE/dare-dag.yaml` existe e foi aprovado pelo usuário
+- Specs em `DARE/EXECUTION/task-<id>.md` geradas (se não, use `dare-dag-build`)
+- `dare` disponível no PATH (`npm i -g @dewtech/dare-cli`)
+
+## Como usar
+
+```
+Invoque a skill com:
+- (sem args) — executa todas as ready do próximo rank
+- --task task-003 — executa só uma task específica
+```
+
+### Passo 1 — Validar pré-condições
+
+- Confirme que `DARE/dare-dag.yaml` existe. Se não, oriente o usuário a invocar `dare-blueprint` ou `dare-dag-build`
+- Leia o YAML e verifique: sem ciclos, ids únicos, ranks paralelizáveis
+- Liste rapidamente para o usuário: total de tasks, ranks, próximas ready
+
+### Passo 2 — Pegar próximas tasks
+
+```bash
+dare execute --next
+```
+
+O CLI imprime as tasks **ready** do rank atual com o prompt completo (snippets de até 2000 chars dos outputs dos pais já costurados). Use esses prompts diretamente — não reescreva.
+
+### Passo 3 — Sugerir abrir o canvas
+
+Antes de começar, peça ao usuário abrir `DARE/.canvas.md` em outra aba do Antigravity. Esse é o feedback visual ao vivo da execução.
+
+### Passo 4 — Executar cada task
+
+Para cada task ready:
+
+1. Leia `spec_file` se houver (`DARE/EXECUTION/task-<id>.md`)
+2. Implemente conforme o `subtask_prompt` — **não invente, não use mock fora de tests, sem TODOs**
+3. Rode o Ralph Loop completo: build → test → lint
+4. Registre o resultado no CLI:
+
+```bash
+# Sucesso
+dare execute --complete task-001 --output "Resumo curto + arquivos criados/modificados (paths)"
+
+# Falha
+dare execute --fail task-002 --reason "Mensagem clara da falha (compilação? teste? lint?)"
+```
+
+### Passo 5 — Avançar de rank
+
+```bash
+dare execute --next
+```
+
+- Se aparecer `✅ All tasks resolved`, todas terminaram. Reporte o resumo.
+- Caso contrário, continue executando o próximo rank.
+
+### Passo 6 — Pós-execução
+
+```bash
+dare execute --status
+```
+
+Mostra snapshot do canvas + sumário (X DONE, Y FAILED, Z SKIPPED).
+
+Para retentar tasks FAILED:
+
+```bash
+dare execute --reset task-002
+dare execute --next
+```
+
+## Comandos do orquestrador `dare`
+
+| Comando | Função |
+|---------|--------|
+| `dare execute --next` | Próximas tasks ready com prompts compostos |
+| `dare execute --complete <id> --output "..."` | Marca DONE |
+| `dare execute --fail <id> --reason "..."` | Marca FAILED + cascade-skip |
+| `dare execute --reset <id>` | Volta para PENDING |
+| `dare execute --status` | Snapshot do canvas + sumário |
+
+## Erros comuns
+
+| Sintoma | Causa | Correção |
+|---------|-------|----------|
+| `dare-dag.yaml not found` | Não foi gerado | Invoque `dare-blueprint` ou `dare-dag-build` |
+| Cascata de SKIPPED | Pai falhou | Corrija pai → `dare execute --reset` → `--next` |
+| Output truncado | Cap de 4000 chars | Escreva em arquivo, retorne resumo |
+| Spec inconsistente | TASKS.md ≠ dare-dag.yaml | Re-gere com `dare-dag-build` |
+
+## Referências
+
+- Schema: `DARE/dare-dag.yaml`
+- Canvas: `DARE/.canvas.md`
+- Specs: `DARE/EXECUTION/task-*.md`
+- Status: `DARE/TASKS.md`
+
+## Quando NÃO usar esta skill
+
+- Se `dare-dag.yaml` não existe — use `dare-blueprint` ou `dare-dag-build`
+- Se você quer só visualizar o grafo — use `dare-dag-viz`
+- Se você quer build + run num único passo — use `dare-dag-runner`
+
+## Licença
+
+Esta skill é parte do DARE Method e está sob licença MIT (D-001).

package/templates/ide/antigravity/.agents/skills/dare-dag-runner/SKILL.md

@@ -1,203 +1,203 @@
----
-name: dare-dag-runner
-description: Constrói e executa o grafo DAG do método DARE com paralelismo lógico via Kahn's algorithm. Antigravity é o executor — usa o plano nativo da IDE; sem API key. O CLI dare é orquestrador (--next/--complete/--fail).
----
-
-# DARE DAG Runner Skill
-
-Você é o executor da fase E (Execute) do método DARE no Antigravity. O CLI
-`dare` é o **orquestrador**: ele indica quais tasks executar agora e registra
-o que você terminou. **Você** é quem efetivamente roda cada task usando o
-runtime nativo do Antigravity — não há API key nem custo extra de tokens.
-
-## Quando usar esta skill
-
-- BLUEPRINT.md está aprovado e é hora de gerar tasks
-- Existe `DARE/dare-dag.yaml` e você precisa entender, executar ou modificar
-- Aparece o canvas `DARE/.canvas.md` durante uma execução
-- Usuário pede "executa o DAG" ou "começa o execute"
-
-## Modelo de execução
-
-> **Antigravity é o executor. O CLI `dare` é orquestrador.**
-
-- A IDE já está autenticada
-- Você lê `dare-dag.yaml` e as specs em `DARE/EXECUTION/task-*.md`
-- Você executa cada task — escreve código, roda testes, faz lint
-- Após cada task, registra o resultado no CLI:
-  - `dare execute --complete <task-id> --output "<resumo>"`
-  - `dare execute --fail <task-id> --reason "<mensagem>"`
-- O CLI atualiza `DARE/.canvas.md` e popula o `dare-graph` automaticamente
-
-## O que é o DAG do DARE
-
-`DARE/dare-dag.yaml` é o **plano de execução** da fase E. Grafo direcionado
-acíclico:
-
-- **Nó** = uma task atômica
-- **Aresta** = `depends_on` (filha precisa do output da pai)
-
-O CLI ordena topologicamente (Kahn's algorithm). Tasks no mesmo rank podem
-rodar em paralelo (logicamente — você decide se literalmente fan-out ou roda
-uma após a outra).
-
-```
-rank 0  ─→  task-001  task-002       (paralelas)
-rank 1  ─→  task-003 (deps: 001,002)
-rank 2  ─→  task-004 (deps: 003)
-```
-
-## Schema canônico
-
-```yaml
-title: "<Nome do projeto> - Development Tasks"
-version: "1.0.0"
-
-limits:
-  parent_context_chars: 2000   # snippet de output de pai injetado no filho
-  task_output_chars: 4000      # cap do output capturado por task
-  timeout_seconds: 600         # apenas referência
-
-models:
-  cursor:      { HIGH: gpt-5.3-codex,     MED: composer-2,       LOW: auto-low }
-  claude:      { HIGH: claude-sonnet-4-5, MED: claude-haiku-4,   LOW: claude-haiku-4 }
-  antigravity: { HIGH: gemini-2.5-pro,    MED: gemini-2.5-flash, LOW: gemini-2.5-flash }
-
-tasks:
-  - id: task-001
-    title: "Setup project structure"
-    depends_on: []
-    complexity: LOW
-    spec_file: EXECUTION/task-001.md
-    subtask_prompt: |
-      <prompt completamente self-contained>
-```
-
-## Loop de execução
-
-```
-1. dare execute --next
-   ↓ imprime prompts das tasks ready (rank atual)
-2. Para cada prompt:
-     - leia spec_file se houver
-     - implemente
-3. dare execute --complete <id> --output "<resumo + arquivos tocados>"
-     ↓ o CLI roda o RALPH LOOP automático (build → test → lint)
-     ↓ se passar: task vira DONE
-     ↓ se falhar: task vira FAILED com stderr capturado; corrija e retente
-4. Volte ao passo 1 até não haver mais tasks ready
-```
-
-> **Ralph Loop é AUTOMÁTICO e OBRIGATÓRIO.** Você NÃO roda build/test/lint
-> manualmente — o `dare execute --complete` faz isso. Se algum gate falhar,
-> a task NÃO vai para DONE; vai para FAILED. Corrija e retente.
->
-> **Não existe flag para pular o Ralph Loop.** Toda task passa pelos 3 gates
-> da stack do projeto.
-
-Comandos úteis:
-
-```bash
-dare execute --next                                # próximas tasks ready
-dare execute --complete task-001 --output "..."    # marca DONE
-dare execute --fail task-002 --reason "..."        # marca FAILED + cascade
-dare execute --reset task-002                      # volta para PENDING (retry)
-dare execute --status                              # snapshot do canvas
-```
-
-## Regras inegociáveis ao construir o DAG
-
-### 1. `id` em kebab-case e único
-`task-001`, `auth-jwt`, `db-migrations`.
-
-### 2. `depends_on` mínimo
-Só adicione dependência quando a filha **literalmente** precisa do output.
-
-| Cenário | Dep? |
-|---------|------|
-| B precisa do arquivo de A | sim |
-| B precisa de decisão de A | sim |
-| B é independente de A | não |
-| Testes/Docs do módulo X | sim — depende da implementação |
-| Pesquisa sem efeito colateral | não |
-
-Cadeia linear é antipattern. Reanalise.
-
-### 3. `complexity` é sinal de cuidado, não custo
-| Nível | Uso |
-|-------|-----|
-| `LOW`  | Setup, scaffolding, docs simples |
-| `MED`  | Implementação direta, refactors, testes unitários |
-| `HIGH` | Lógica crítica, segurança, integrações |
-
-### 4. `subtask_prompt` self-contained
-Receberá `subtask_prompt` + snippets de até 2000 chars dos outputs dos pais.
-Não vale "como combinamos". Tudo no prompt ou via pais.
-
-### 5. Output cap 4000 chars
-Se gerar muito, escreva em arquivo e faça o `--output` ser resumo + caminhos.
-
-### 6. Spec por task em `EXECUTION/task-<id>.md`
-Spec detalhada com objetivo, arquivos, validation gates, testes, segurança.
-
-## Os 3 artefatos sempre juntos
-
-| Arquivo | Para quê |
-|---------|----------|
-| `DARE/TASKS.md` | Visão humana com tabela e progresso |
-| `DARE/dare-dag.yaml` | Grafo executável |
-| `DARE/EXECUTION/task-<id>.md` | Spec por task |
-
-Os três precisam ser consistentes: mesmos `id`s, `depends_on`, `complexity`.
-
-## Canvas ao vivo (`DARE/.canvas.md`)
-
-O CLI reescreve a cada `--complete`/`--fail`:
-
-| Status | Significado |
-|--------|-------------|
-| `PENDING` ⏳ | aguardando rank |
-| `RUNNING` 🔄 | você está executando |
-| `DONE` ✅ | concluído |
-| `FAILED` ❌ | erro durante execução |
-| `SKIPPED` ⏭️ | dependência falhou — automático, não toque |
-
-## Erros comuns
-
-| Erro | Correção |
-|------|----------|
-| Ciclo | Retire a aresta cíclica |
-| `id` duplicado | Renomeie |
-| `depends_on` inexistente | Corrija ou adicione a task |
-| Tudo em rank 0 | Adicione deps reais quando há contenção |
-| Cadeia linear | Reveja se as deps são necessárias |
-
-## Antipatterns que você NÃO deve criar
-
-- ❌ Task **"Ralph Loop final"** / **"Hardening"** / **"QA"** — gate é por task
-- ❌ Tests com `assertTrue(true)` — o gate `test` roda de verdade
-- ❌ "Setup project structure" antes de containerizar o app
-
-## Ordem recomendada das primeiras tasks
-
-1. **Containerize app** (Dockerfile + docker-compose + healthcheck)
-2. **Database schema** (migrations + factories)
-3. **Core endpoints / componentes**
-4. **Auth / autorização**
-5. **Test suite real** (assertions de verdade)
-
-A task de container/compose pode estar em outra ordem para projetos sem
-DB ou em monorepo já containerizado. Mas quase sempre é uma das primeiras.
-
-## Checklist antes de aprovar
-
-- [ ] Pelo menos 2 tasks no rank 0
-- [ ] `subtask_prompt` executável sem contexto adicional
-- [ ] Tasks de teste/doc dependem da implementação correspondente
-- [ ] `complexity` reflete o esforço real
-- [ ] `id` em kebab-case e único
-- [ ] Sem ciclos
-- [ ] **Sem task de "Ralph Loop final"** — gate é por task
-- [ ] **Tests com assertions reais** — placeholder quebra o gate
-- [ ] Container/runtime resolvido cedo
-- [ ] Os 3 artefatos consistentes
+---
+name: dare-dag-runner
+description: Constrói e executa o grafo DAG do método DARE com paralelismo lógico via Kahn's algorithm. Antigravity é o executor — usa o plano nativo da IDE; sem API key. O CLI dare é orquestrador (--next/--complete/--fail).
+---
+
+# DARE DAG Runner Skill
+
+Você é o executor da fase E (Execute) do método DARE no Antigravity. O CLI
+`dare` é o **orquestrador**: ele indica quais tasks executar agora e registra
+o que você terminou. **Você** é quem efetivamente roda cada task usando o
+runtime nativo do Antigravity — não há API key nem custo extra de tokens.
+
+## Quando usar esta skill
+
+- BLUEPRINT.md está aprovado e é hora de gerar tasks
+- Existe `DARE/dare-dag.yaml` e você precisa entender, executar ou modificar
+- Aparece o canvas `DARE/.canvas.md` durante uma execução
+- Usuário pede "executa o DAG" ou "começa o execute"
+
+## Modelo de execução
+
+> **Antigravity é o executor. O CLI `dare` é orquestrador.**
+
+- A IDE já está autenticada
+- Você lê `dare-dag.yaml` e as specs em `DARE/EXECUTION/task-*.md`
+- Você executa cada task — escreve código, roda testes, faz lint
+- Após cada task, registra o resultado no CLI:
+  - `dare execute --complete <task-id> --output "<resumo>"`
+  - `dare execute --fail <task-id> --reason "<mensagem>"`
+- O CLI atualiza `DARE/.canvas.md` e popula o `dare-graph` automaticamente
+
+## O que é o DAG do DARE
+
+`DARE/dare-dag.yaml` é o **plano de execução** da fase E. Grafo direcionado
+acíclico:
+
+- **Nó** = uma task atômica
+- **Aresta** = `depends_on` (filha precisa do output da pai)
+
+O CLI ordena topologicamente (Kahn's algorithm). Tasks no mesmo rank podem
+rodar em paralelo (logicamente — você decide se literalmente fan-out ou roda
+uma após a outra).
+
+```
+rank 0  ─→  task-001  task-002       (paralelas)
+rank 1  ─→  task-003 (deps: 001,002)
+rank 2  ─→  task-004 (deps: 003)
+```
+
+## Schema canônico
+
+```yaml
+title: "<Nome do projeto> - Development Tasks"
+version: "1.0.0"
+
+limits:
+  parent_context_chars: 2000   # snippet de output de pai injetado no filho
+  task_output_chars: 4000      # cap do output capturado por task
+  timeout_seconds: 600         # apenas referência
+
+models:
+  cursor:      { HIGH: gpt-5.3-codex,     MED: composer-2,       LOW: auto-low }
+  claude:      { HIGH: claude-sonnet-4-5, MED: claude-haiku-4,   LOW: claude-haiku-4 }
+  antigravity: { HIGH: gemini-2.5-pro,    MED: gemini-2.5-flash, LOW: gemini-2.5-flash }
+
+tasks:
+  - id: task-001
+    title: "Setup project structure"
+    depends_on: []
+    complexity: LOW
+    spec_file: EXECUTION/task-001.md
+    subtask_prompt: |
+      <prompt completamente self-contained>
+```
+
+## Loop de execução
+
+```
+1. dare execute --next
+   ↓ imprime prompts das tasks ready (rank atual)
+2. Para cada prompt:
+     - leia spec_file se houver
+     - implemente
+3. dare execute --complete <id> --output "<resumo + arquivos tocados>"
+     ↓ o CLI roda o RALPH LOOP automático (build → test → lint)
+     ↓ se passar: task vira DONE
+     ↓ se falhar: task vira FAILED com stderr capturado; corrija e retente
+4. Volte ao passo 1 até não haver mais tasks ready
+```
+
+> **Ralph Loop é AUTOMÁTICO e OBRIGATÓRIO.** Você NÃO roda build/test/lint
+> manualmente — o `dare execute --complete` faz isso. Se algum gate falhar,
+> a task NÃO vai para DONE; vai para FAILED. Corrija e retente.
+>
+> **Não existe flag para pular o Ralph Loop.** Toda task passa pelos 3 gates
+> da stack do projeto.
+
+Comandos úteis:
+
+```bash
+dare execute --next                                # próximas tasks ready
+dare execute --complete task-001 --output "..."    # marca DONE
+dare execute --fail task-002 --reason "..."        # marca FAILED + cascade
+dare execute --reset task-002                      # volta para PENDING (retry)
+dare execute --status                              # snapshot do canvas
+```
+
+## Regras inegociáveis ao construir o DAG
+
+### 1. `id` em kebab-case e único
+`task-001`, `auth-jwt`, `db-migrations`.
+
+### 2. `depends_on` mínimo
+Só adicione dependência quando a filha **literalmente** precisa do output.
+
+| Cenário | Dep? |
+|---------|------|
+| B precisa do arquivo de A | sim |
+| B precisa de decisão de A | sim |
+| B é independente de A | não |
+| Testes/Docs do módulo X | sim — depende da implementação |
+| Pesquisa sem efeito colateral | não |
+
+Cadeia linear é antipattern. Reanalise.
+
+### 3. `complexity` é sinal de cuidado, não custo
+| Nível | Uso |
+|-------|-----|
+| `LOW`  | Setup, scaffolding, docs simples |
+| `MED`  | Implementação direta, refactors, testes unitários |
+| `HIGH` | Lógica crítica, segurança, integrações |
+
+### 4. `subtask_prompt` self-contained
+Receberá `subtask_prompt` + snippets de até 2000 chars dos outputs dos pais.
+Não vale "como combinamos". Tudo no prompt ou via pais.
+
+### 5. Output cap 4000 chars
+Se gerar muito, escreva em arquivo e faça o `--output` ser resumo + caminhos.
+
+### 6. Spec por task em `EXECUTION/task-<id>.md`
+Spec detalhada com objetivo, arquivos, validation gates, testes, segurança.
+
+## Os 3 artefatos sempre juntos
+
+| Arquivo | Para quê |
+|---------|----------|
+| `DARE/TASKS.md` | Visão humana com tabela e progresso |
+| `DARE/dare-dag.yaml` | Grafo executável |
+| `DARE/EXECUTION/task-<id>.md` | Spec por task |
+
+Os três precisam ser consistentes: mesmos `id`s, `depends_on`, `complexity`.
+
+## Canvas ao vivo (`DARE/.canvas.md`)
+
+O CLI reescreve a cada `--complete`/`--fail`:
+
+| Status | Significado |
+|--------|-------------|
+| `PENDING` ⏳ | aguardando rank |
+| `RUNNING` 🔄 | você está executando |
+| `DONE` ✅ | concluído |
+| `FAILED` ❌ | erro durante execução |
+| `SKIPPED` ⏭️ | dependência falhou — automático, não toque |
+
+## Erros comuns
+
+| Erro | Correção |
+|------|----------|
+| Ciclo | Retire a aresta cíclica |
+| `id` duplicado | Renomeie |
+| `depends_on` inexistente | Corrija ou adicione a task |
+| Tudo em rank 0 | Adicione deps reais quando há contenção |
+| Cadeia linear | Reveja se as deps são necessárias |
+
+## Antipatterns que você NÃO deve criar
+
+- ❌ Task **"Ralph Loop final"** / **"Hardening"** / **"QA"** — gate é por task
+- ❌ Tests com `assertTrue(true)` — o gate `test` roda de verdade
+- ❌ "Setup project structure" antes de containerizar o app
+
+## Ordem recomendada das primeiras tasks
+
+1. **Containerize app** (Dockerfile + docker-compose + healthcheck)
+2. **Database schema** (migrations + factories)
+3. **Core endpoints / componentes**
+4. **Auth / autorização**
+5. **Test suite real** (assertions de verdade)
+
+A task de container/compose pode estar em outra ordem para projetos sem
+DB ou em monorepo já containerizado. Mas quase sempre é uma das primeiras.
+
+## Checklist antes de aprovar
+
+- [ ] Pelo menos 2 tasks no rank 0
+- [ ] `subtask_prompt` executável sem contexto adicional
+- [ ] Tasks de teste/doc dependem da implementação correspondente
+- [ ] `complexity` reflete o esforço real
+- [ ] `id` em kebab-case e único
+- [ ] Sem ciclos
+- [ ] **Sem task de "Ralph Loop final"** — gate é por task
+- [ ] **Tests com assertions reais** — placeholder quebra o gate
+- [ ] Container/runtime resolvido cedo
+- [ ] Os 3 artefatos consistentes