@dewtech/dare-cli 2.0.1 → 2.2.0

package/templates/ide/claude/.claude/commands/dare-dag-build.md

@@ -0,0 +1,110 @@
+# /dare-dag-build
+
+Regenera **apenas** o `DARE/dare-dag.yaml` a partir do `DARE/BLUEPRINT.md` já
+existente, sem refazer o blueprint nem as specs. Útil quando o BLUEPRINT
+mudou pouco mas você precisa que o grafo reflita o novo estado.
+
+## Quando usar
+
+- O BLUEPRINT foi ajustado e o grafo precisa refletir
+- Você quer experimentar uma decomposição diferente sem refazer o blueprint
+- O `dare-dag.yaml` ficou inconsistente com `EXECUTION/task-*.md`
+- Precisa adicionar/remover/reordenar tasks no grafo
+
+## Pré-requisitos
+
+- `DARE/BLUEPRINT.md` existe e está aprovado
+- (Opcional) `DARE/EXECUTION/task-*.md` específicas serão preservadas se não
+  forem mencionadas
+
+## O que fazer
+
+### 1. Ler `DARE/BLUEPRINT.md`
+
+Obrigatório. Se faltar, peça `/dare-blueprint` antes.
+
+### 2. Ler `DARE/dare-dag.yaml` atual (se existir)
+
+Para preservar `id`s já em uso e não confundir o usuário com renomeações
+desnecessárias.
+
+### 3. Gerar o novo `dare-dag.yaml`
+
+Schema canônico:
+
+```yaml
+title: "<Nome do Projeto> - Development Tasks"
+version: "1.0.0"
+
+limits:
+  parent_context_chars: 2000
+  task_output_chars: 4000
+  timeout_seconds: 600
+
+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: "..."
+    depends_on: []
+    complexity: LOW
+    spec_file: EXECUTION/task-001.md
+    subtask_prompt: |
+      <self-contained>
+```
+
+**Regras inegociáveis:**
+
+- `id` em kebab-case e único
+- `depends_on` mínimo — só quando filha *literalmente* precisa do output
+- `subtask_prompt` self-contained
+- Pelo menos 2 tasks no rank 0
+- Cadeia linear é antipattern
+- `complexity` honesta
+
+### 4. Validar consistência com `EXECUTION/task-*.md`
+
+Se uma spec existe em `DARE/EXECUTION/task-<id>.md`:
+- Mantenha o mesmo `id` no YAML
+- Aponte `spec_file: EXECUTION/task-<id>.md`
+- Se a `complexity` ou `depends_on` mudou, atualize **também** a spec e o
+  `TASKS.md`
+
+Se uma task nova entrou no YAML mas não tem spec:
+- Crie a spec correspondente em `EXECUTION/task-<id>.md`
+
+Se uma task saiu do YAML mas a spec ficou:
+- Pergunte ao usuário: arquivar (mover para `EXECUTION/_archived/`) ou
+  apagar?
+
+### 5. Validar grafo
+
+- Sem ciclos
+- Todos os `depends_on` apontam para `id`s existentes
+- `id`s únicos
+- Pelo menos 2 tasks no rank 0
+
+### 6. Atualizar `DARE/TASKS.md`
+
+Reflita o novo grafo na tabela master.
+
+### 7. Mensagem ao usuário
+
+> `dare-dag.yaml` regenerado:
+> - Total de tasks: N
+> - Ranks paralelos: N
+> - Adicionadas: [...]
+> - Removidas: [...]
+> - Modificadas: [...]
+>
+> Revise e aprove. Para executar: `/dare-dag-run`.
+
+## Quando NÃO usar
+
+- Se você nunca rodou `/dare-blueprint` antes — use `/dare-blueprint` primeiro
+- Se o BLUEPRINT está desatualizado — atualize o BLUEPRINT primeiro
+
+$ARGUMENTS

package/templates/ide/claude/.claude/commands/dare-dag-run.md

@@ -0,0 +1,110 @@
+# /dare-dag-run
+
+Executa o grafo de tasks definido em `DARE/dare-dag.yaml` em paralelo,
+respeitando dependências (Kahn's algorithm + execução por rank). O canvas
+ao vivo é gravado em `DARE/.canvas.md`.
+
+## Pré-requisitos
+
+- `DARE/dare-dag.yaml` existe e foi aprovado pelo usuário
+- Specs em `DARE/EXECUTION/task-<id>.md` geradas
+- `ANTHROPIC_API_KEY` exportada no ambiente (runner padrão para o Claude)
+
+## Como usar
+
+```
+/dare-dag-run                    # paralelo, runner claude
+/dare-dag-run --resume           # só PENDING/FAILED
+/dare-dag-run --task task-003    # task única
+/dare-dag-run --sequential       # debug
+/dare-dag-run --runner cursor    # trocar de runner
+```
+
+## O que fazer
+
+### 1. Validar pré-condições
+
+- Confirme que `DARE/dare-dag.yaml` existe. Se não, oriente
+  `/dare-blueprint` ou `/dare-dag-build`.
+- Leia o YAML e verifique:
+  - Sem ciclos
+  - Pelo menos 2 tasks no rank 0
+  - Cada task tem `id` único, `complexity`, `subtask_prompt`
+- Confirme `ANTHROPIC_API_KEY` (ou a env var do runner escolhido).
+
+### 2. Escolher modo de execução
+
+| Modo | Comando |
+|------|---------|
+| Paralelo (recomendado) | `dare execute --parallel --runner claude` |
+| Sequencial (debug) | `dare execute --runner claude` |
+| Task única | `dare execute --task <id> --runner claude` |
+| Resume (PENDING/FAILED) | `dare execute --parallel --runner claude --resume` |
+
+### 3. Sugerir abrir o canvas ao vivo
+
+Antes de rodar, peça ao usuário abrir `DARE/.canvas.md` em outra aba do
+editor. O runner reescreve o arquivo a cada transição de status:
+
+```
+| ID       | Title              | Status        | Duration | Tokens |
+|----------|--------------------|---------------|----------|--------|
+| task-001 | Setup structure    | ✅ DONE       | 1240ms   | 850    |
+| task-002 | DB schema          | 🔄 RUNNING    | -        | -      |
+| task-003 | Core endpoints     | ⏳ PENDING    | -        | -      |
+```
+
+### 4. Executar e monitorar
+
+Rode o comando escolhido. Durante a execução:
+
+- **Não interrompa por `SKIPPED`** — o runner pula automaticamente quando
+  uma dependência falha. Esse é comportamento esperado.
+- Se uma task falhar, leia o erro no terminal/canvas e corrija a spec em
+  `EXECUTION/task-<id>.md` ou o `subtask_prompt` no `dare-dag.yaml`. Depois
+  re-execute com `--resume`.
+- Use `Ctrl+C` para cancelar — o runner trata SIGINT e finaliza limpamente.
+
+### 5. Pós-execução
+
+Ao terminar:
+
+- Atualize `DARE/TASKS.md` com os status finais (DONE/FAILED/SKIPPED)
+- Mostre um resumo:
+  - Total DONE / FAILED / SKIPPED
+  - Duração total
+  - Tokens consumidos
+  - Tasks que precisam atenção (FAILED)
+- Se houver FAILED, sugira:
+  1. Ler `EXECUTION/task-<id>.md` da que falhou
+  2. Corrigir spec ou prompt
+  3. Re-executar: `/dare-dag-run --resume`
+- Se tudo DONE, parabenize e oriente próxima feature/blueprint
+
+## Variáveis de ambiente por runner
+
+| Runner | Env var |
+|--------|---------|
+| `claude` (default no Claude Code) | `ANTHROPIC_API_KEY` |
+| `cursor` | `CURSOR_API_KEY` |
+| `antigravity` | `ANTIGRAVITY_API_KEY` |
+
+## Erros comuns
+
+| Sintoma | Causa | Correção |
+|---------|-------|----------|
+| `dare-dag.yaml not found` | Grafo não foi gerado | `/dare-blueprint` ou `/dare-dag-build` |
+| `Circular dependency detected` | Ciclo no grafo | Edite o YAML para remover |
+| `ANTHROPIC_API_KEY not set` | Env var faltando | `export ANTHROPIC_API_KEY=...` |
+| Cascata de SKIPPED | Pai falhou e bloqueou descendentes | Corrija pai, use `--resume` |
+| Output truncado em 4000 chars | Cap de output | Faça a task escrever em arquivo e retornar resumo |
+| Timeout (>600s) | Task longa demais | Quebre em sub-tasks ou aumente `limits.timeout_seconds` |
+
+## Referências
+
+- Schema do grafo: `DARE/dare-dag.yaml`
+- Canvas ao vivo: `DARE/.canvas.md`
+- Specs por task: `DARE/EXECUTION/task-*.md`
+- Status humano: `DARE/TASKS.md`
+
+$ARGUMENTS

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

@@ -1,20 +1,117 @@
-# Comando: /generate-tasks
-
-## Descrição
-Este comando avança o Método DARE lendo o Blueprint aprovado e gerando as tarefas atômicas isoladas para execução.
-
-## Instruções para o Cursor Composer
-
-1. **Leia o Documento Blueprint:** Acesse e leia o arquivo `$ARGUMENTS` (geralmente `DARE/BLUEPRINT.md`) que contém a arquitetura completa.
-2. **Leia os Templates:** Utilize a estrutura definida em `templates/TASKS-template.md` e `templates/TASK-SPEC-template.md`.
-3. **Analise o Contexto Global:** Leia o arquivo `.cursorrules` (ou equivalente) para garantir que as instruções de código sigam as convenções do projeto.
-4. **Desdobre as Fases em Tarefas Atômicas:**
-   - Para cada Fase definida no Blueprint, crie tarefas granulares e executáveis.
-   - Uma tarefa deve ser pequena o suficiente para ser concluída em um único prompt do Composer.
-   - **Tarefas de Segurança:** Garanta que requisitos de segurança (ex: Middlewares, Validação de FormRequests, Criptografia) tenham tarefas específicas ou estejam explicitamente incluídos nas tarefas relevantes.
-   - Exemplo: "Fase 2: Autenticação" vira "Task 003: Migration de Users", "Task 004: AuthController (com Rate Limit e Bcrypt)", etc.
-5. **Gere os Arquivos de Tarefas:**
-   - **TASKS.md:** Crie o arquivo `DARE/TASKS.md` com a visão geral de todas as tarefas e suas dependências.
-   - **Especificações Isoladas:** Para CADA tarefa criada, crie um arquivo em `DARE/EXECUTION/task-[id].md` seguindo o template `TASK-SPEC-template.md`.
-   - Preencha as instruções de implementação detalhadas para cada arquivo de task isolada, incluindo os Validation Gates apropriados para a stack (ex: PHPUnit para Laravel, Pytest para Python).
-6. **Mensagem Final:** Informe ao usuário: "Documento TASKS.md e especificações isoladas geradas em DARE/EXECUTION/ com sucesso. Revise as tarefas. Para iniciar a implementação, execute `/execute-task task-001`."
+# Comando: /generate-tasks
+
+## Descrição
+Avança o Método DARE lendo o Blueprint aprovado e gerando os **três artefatos**
+da fase de execução: `TASKS.md` (visão humana), `dare-dag.yaml` (grafo
+executável pelo CLI) e `EXECUTION/task-<id>.md` (specs detalhadas por task).
+
+## Pré-requisitos
+
+- `DARE/BLUEPRINT.md` aprovado pelo usuário.
+- Você deve seguir as regras de construção do DAG definidas em
+  `.cursor/rules/skill-dag-runner.mdc` — leia antes de gerar.
+
+## Instruções para o Cursor Composer
+
+### 1. Ler o contexto
+
+- Leia `$ARGUMENTS` (geralmente `DARE/BLUEPRINT.md`).
+- Leia os templates: `templates/TASKS-template.md` e `templates/TASK-SPEC-template.md`.
+- Leia `.cursorrules` para convenções do projeto.
+- Leia a skill `skill-dag-runner.mdc` para regras de DAG (depends_on mínimo,
+  complexity, prompt self-contained, output cap 4000, parent context 2000).
+
+### 2. Decompor o Blueprint em tasks atômicas
+
+- Cada fase do Blueprint vira tasks pequenas o suficiente para um único prompt
+  do Composer.
+- Tarefas de segurança (FormRequests, middlewares, Bcrypt, rate limit) devem
+  ter tasks específicas ou estar explícitas nas tasks relevantes.
+- Atribua `complexity` a cada task: LOW / MED / HIGH.
+
+### 3. Gerar `DARE/TASKS.md` (visão humana)
+
+Tabela com todas as tasks e dependências em formato legível:
+
+```markdown
+| ID       | Título                    | Status      | Depends On       | Complexity |
+|----------|---------------------------|-------------|------------------|------------|
+| task-001 | Setup project structure   | ⏳ PENDING  | —                | LOW        |
+| task-002 | DB migrations             | ⏳ PENDING  | —                | MED        |
+| task-003 | Auth controllers          | ⏳ PENDING  | task-001, 002    | HIGH       |
+```
+
+Inclua: total de tasks, fases agrupadas, tempo estimado, próximos passos.
+
+### 4. Gerar `DARE/dare-dag.yaml` (grafo executável)
+
+Schema canônico (alinhado com `skill-dag-runner.mdc`):
+
+```yaml
+title: "<Nome do Projeto> - Development Tasks"
+version: "1.0.0"
+
+limits:
+  parent_context_chars: 2000
+  task_output_chars: 4000
+  timeout_seconds: 600
+
+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: |
+      Setup base project structure following DARE/BLUEPRINT.md.
+      Create directories: src/, tests/, docs/. Initialize package files.
+      No business logic yet. Validation gate: project builds.
+```
+
+**Regras inegociáveis:**
+- `id` em kebab-case e único.
+- `depends_on` mínimo — só adicione quando a task filha **literalmente** não
+  pode começar sem o output da pai (arquivo, schema, decisão exportada).
+- `subtask_prompt` totalmente self-contained (o subagente recebe só ele +
+  snippets de 2000 chars dos pais).
+- Pelo menos 2 tasks no rank 0 (com `depends_on: []`) para haver paralelismo
+  real.
+- Cadeia linear (`001 → 002 → 003 → ...`) é antipattern. Reanalise.
+
+### 5. Gerar `DARE/EXECUTION/task-<id>.md` (uma spec por task)
+
+Para CADA task em `dare-dag.yaml`, crie a spec correspondente seguindo
+`templates/TASK-SPEC-template.md`:
+
+- **Objetivo** claro
+- **Arquivos a criar/modificar**
+- **Validation Gates** (build, test, lint específicos da stack)
+- **Testes esperados**
+- **Considerações de segurança**
+- **Próxima task** sugerida
+
+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.
+
+### 6. Validar consistência dos 3 artefatos
+
+- Mesmos `id`s em `TASKS.md`, `dare-dag.yaml` e `EXECUTION/task-*.md`.
+- Mesmas `depends_on` em `TASKS.md` e `dare-dag.yaml`.
+- Mesmas `complexity`.
+- Sem ciclos.
+
+### 7. Mensagem final ao usuário
+
+> Gerados 3 artefatos da fase de execução:
+> - `DARE/TASKS.md` ([N] tasks, visão humana)
+> - `DARE/dare-dag.yaml` (grafo executável, [N] ranks paralelos)
+> - `DARE/EXECUTION/task-*.md` ([N] specs detalhadas)
+>
+> Revise. Para executar tudo em paralelo: `/run-dag` ou `dare execute --parallel`.
+> Para uma task isolada: `/execute-task task-001`.

package/templates/ide/cursor/.cursor/commands/run-dag.md

@@ -0,0 +1,87 @@
+# Comando: /run-dag
+
+## Descrição
+Executa o grafo de tasks definido em `DARE/dare-dag.yaml` em paralelo
+respeitando dependências (Kahn's algorithm + Promise.all por rank). O canvas
+ao vivo é gravado em `DARE/.canvas.md`.
+
+## Pré-requisitos
+
+- `DARE/dare-dag.yaml` existe e foi aprovado pelo usuário
+- Specs em `DARE/EXECUTION/task-<id>.md` geradas
+- `CURSOR_API_KEY` exportada no ambiente
+
+## Instruções para o Cursor Composer
+
+### 1. Validar pré-condições
+
+- Confirme que `DARE/dare-dag.yaml` existe. Se não, oriente o usuário a rodar
+  `/generate-tasks` primeiro.
+- Leia o YAML e verifique:
+  - Sem ciclos
+  - Pelo menos 2 tasks no rank 0 (paralelismo real)
+  - Cada `task` tem `id` único, `complexity`, `subtask_prompt`
+- Confira `CURSOR_API_KEY`. Se faltar, peça ao usuário exportar.
+
+### 2. Escolher o modo de execução
+
+Pergunte ao usuário (ou infira do `$ARGUMENTS`) qual modo:
+
+| Modo | Comando |
+|------|---------|
+| Paralelo (recomendado) | `dare execute --parallel --runner cursor` |
+| Sequencial (debug) | `dare execute --runner cursor` |
+| Task única | `dare execute --task <id> --runner cursor` |
+| Resume (só PENDING/FAILED) | `dare execute --parallel --runner cursor --resume` |
+
+### 3. Abrir o canvas em paralelo à execução
+
+Antes de rodar, sugira ao usuário abrir `DARE/.canvas.md` em uma aba para
+acompanhar o progresso ao vivo. O runner reescreve o arquivo a cada transição
+de status.
+
+### 4. Executar e monitorar
+
+Rode o comando escolhido. Durante a execução:
+
+- Não interrompa por `SKIPPED` — o runner pula automaticamente quando uma
+  dependência falha
+- Se uma task falhar, leia o erro no terminal/canvas e corrija a spec em
+  `EXECUTION/task-<id>.md` ou o `subtask_prompt` no `dare-dag.yaml`
+- Use `--resume` para retomar sem refazer tasks DONE
+
+### 5. Pós-execução
+
+Ao terminar:
+
+- Atualize `DARE/TASKS.md` com os status finais (DONE/FAILED/SKIPPED)
+- Mostre um resumo: total DONE, FAILED, SKIPPED, duração total, tokens
+- Se houver FAILED, sugira diagnóstico e re-execução com `--resume`
+- Se tudo DONE, parabenize e oriente próximo blueprint/feature
+
+## Variáveis de ambiente por runner
+
+| Runner | Env var |
+|--------|---------|
+| `cursor` (default) | `CURSOR_API_KEY` |
+| `claude` | `ANTHROPIC_API_KEY` |
+| `antigravity` | `ANTIGRAVITY_API_KEY` |
+
+## Erros comuns
+
+| Sintoma | Causa | Correção |
+|---------|-------|----------|
+| `dare-dag.yaml not found` | Arquivo não foi gerado | Rode `/generate-tasks` |
+| `Circular dependency detected` | Ciclo no grafo | Edite `dare-dag.yaml` para remover |
+| `CURSOR_API_KEY not set` | Env var faltando | `export CURSOR_API_KEY=...` |
+| Muitos `SKIPPED` em cascata | Pai falhou e bloqueou descendentes | Corrija o pai e use `--resume` |
+| Output truncado | Cap de 4000 chars | Faça a task escrever em arquivo e retornar resumo |
+
+## Referências
+
+- Skill: `.cursor/rules/skill-dag-runner.mdc` (regras do DAG)
+- Schema: `DARE/dare-dag.yaml`
+- Canvas: `DARE/.canvas.md`
+- Specs: `DARE/EXECUTION/task-*.md`
+
+$ARGUMENTS

package/templates/ide/cursor/.cursor/rules/skill-dag-runner.mdc

@@ -0,0 +1,176 @@
+---
+description: Como construir e executar grafos de tasks (DAG) do método DARE com paralelismo real via dare-dag.yaml
+globs: DARE/dare-dag.yaml,DARE/EXECUTION/**,DARE/.canvas.md
+alwaysApply: false
+---
+
+# Skill: DAG Task Runner
+
+## Quando usar
+
+- O `BLUEPRINT.md` foi aprovado e você precisa decompor em tasks executáveis
+- O usuário pediu execução paralela (`dare execute --parallel`)
+- Existe `DARE/dare-dag.yaml` e você precisa entender ou modificar o grafo
+- Aparece o canvas `DARE/.canvas.md` e você precisa interpretar os status
+
+## O que é o DAG do DARE
+
+`DARE/dare-dag.yaml` é o **plano de execução**: um grafo direcionado acíclico
+em que cada nó é uma task atômica e as arestas são `depends_on`. O DAG runner
+do CLI (`dare execute --parallel`) lê o YAML, ordena topologicamente
+(Kahn's algorithm) e roda em paralelo todas as tasks do mesmo rank via
+`Promise.all`.
+
+```
+rank 0:  task-001    task-002      ←  rodam juntas (sem depends_on)
+rank 1:  task-003 (deps: 001, 002) ←  só após rank 0
+rank 2:  task-004 (deps: 003)
+```
+
+## Schema canônico do `dare-dag.yaml`
+
+```yaml
+title: "<Nome do projeto> - Development Tasks"
+version: "1.0.0"
+
+# Limites de contexto/output (alinhados com Cursor SDK DAG runner)
+limits:
+  parent_context_chars: 2000   # snippet de cada output de pai injetado no filho
+  task_output_chars: 4000      # cap do output capturado por task
+  timeout_seconds: 600         # AbortController por task
+
+# Mapeamento complexity → modelo, por runner
+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   # opcional; fallback é subtask_prompt
+    subtask_prompt: |
+      <prompt completamente self-contained>
+```
+
+## Regras inegociáveis ao construir o DAG
+
+### 1. `id` em kebab-case e único
+Use prefixo + número (`task-001`, `auth-jwt`, `db-migrations`). Sem espaços, sem
+maiúsculas. O ID aparece no canvas e nos logs do runner.
+
+### 2. `depends_on` mínimo — maximize paralelismo
+Só adicione uma dependência quando a task filha **literalmente não pode começar**
+sem o output da pai (arquivo, schema, constante exportada).
+
+| Situação | `depends_on`? |
+|----------|---------------|
+| Task B precisa do arquivo que A cria | ✅ sim |
+| Task B precisa de uma decisão tomada em A | ✅ sim |
+| Task B faz coisa parecida com A mas independente | ❌ não |
+| Tasks de pesquisa/leitura sem efeito colateral | ❌ raramente — fan out wide |
+| Testes para módulo X | ✅ depende da implementação de X |
+| Documentação de módulo X | ✅ depende da implementação de X |
+
+**Antipattern:** cadeia linear `001 → 002 → 003 → 004 → ...`. Se virar isso, você
+está adicionando dependências falsas. Reanalise.
+
+### 3. `complexity` define qual modelo executa
+| Nível | Quando usar | Modelo Cursor |
+|-------|-------------|---------------|
+| `LOW`  | Setup, scaffolding, docs simples, leitura/pesquisa | `auto-low` |
+| `MED`  | Implementação direta, refactors, testes unitários | `composer-2` |
+| `HIGH` | Lógica de negócio crítica, segurança, integrações | `gpt-5.3-codex` |
+
+Não force `HIGH` em tudo — encarece e gasta contexto.
+
+### 4. `subtask_prompt` totalmente self-contained
+A task vai rodar como subagente isolado. Ele recebe apenas:
+- O próprio `subtask_prompt`
+- Snippets de até **2000 chars** dos outputs de cada pai
+- Acesso ao filesystem do projeto
+
+Não dá para referenciar "como combinamos antes" ou "use o padrão da task-001".
+Tudo o que o subagente precisa saber tem que estar no prompt ou virá pelos pais.
+
+### 5. Output cap de 4000 chars
+Se a task vai produzir muita coisa, escreva em arquivo (ele permanece no FS) e
+faça o output da task ser um resumo curto + caminhos dos arquivos criados.
+
+### 6. Cada task vira também `EXECUTION/task-<id>.md`
+Spec detalhada com: objetivo, arquivos a criar/modificar, validation gates,
+testes esperados. O `subtask_prompt` no YAML pode referenciar
+`spec_file: EXECUTION/task-001.md` para que o agente leia a spec na hora de
+executar.
+
+## Geração: o que o `/generate-tasks` deve produzir
+
+Sempre os **três artefatos juntos**:
+
+1. **`DARE/TASKS.md`** — tabela master legível por humano
+2. **`DARE/dare-dag.yaml`** — grafo executável pelo CLI
+3. **`DARE/EXECUTION/task-<id>.md`** — uma spec por task
+
+O `TASKS.md` é a fonte de leitura humana; o `dare-dag.yaml` é a fonte de
+execução; os `EXECUTION/task-*.md` são as specs detalhadas. Os três precisam
+estar consistentes (mesmo `id`, mesmo `depends_on`, mesma `complexity`).
+
+## Execução: como rodar o DAG
+
+```bash
+# Paralelo (recomendado) — runner padrão é cursor
+dare execute --parallel
+
+# Sequencial (debug)
+dare execute
+
+# Task única
+dare execute --task task-003
+
+# Resume — só PENDING/FAILED
+dare execute --parallel --resume
+```
+
+Variáveis de ambiente:
+- `CURSOR_API_KEY` — necessário para runner cursor
+- `ANTHROPIC_API_KEY` — runner claude
+- `ANTIGRAVITY_API_KEY` — runner antigravity
+
+## Canvas ao vivo (`DARE/.canvas.md`)
+
+O runner reescreve `DARE/.canvas.md` a cada transição de status:
+
+```
+| ID       | Title              | Status        | Duration | Tokens |
+|----------|--------------------|---------------|----------|--------|
+| task-001 | Setup structure    | ✅ DONE       | 1240ms   | 850    |
+| task-002 | DB schema          | 🔄 RUNNING    | -        | -      |
+| task-003 | Core endpoints     | ⏳ PENDING    | -        | -      |
+```
+
+Status possíveis: `PENDING` ⏳, `RUNNING` 🔄, `DONE` ✅, `FAILED` ❌, `SKIPPED` ⏭️.
+
+`SKIPPED` significa que uma dependência falhou — você não precisa intervir, o
+runner pula automaticamente.
+
+## Erros comuns ao construir DAG
+
+| Erro | Sintoma | Como corrigir |
+|------|---------|---------------|
+| Ciclo em `depends_on` | `Circular dependency detected: <id>` | Reveja o grafo, retire a aresta cíclica |
+| `id` duplicado | Comportamento indefinido no runner | Renomeie para únicos |
+| `depends_on` aponta para `id` inexistente | `Task not found: <id>` | Corrija o nome ou adicione a task |
+| Tudo em rank 0 (sem dependências reais) | Conflito de escrita no mesmo arquivo | Adicione `depends_on` quando há contenção |
+| Cadeia linear longa | Sem ganho de paralelismo | Reveja se as dependências são reais |
+
+## Checklist antes de aprovar um DAG
+
+- [ ] Pelo menos 2 tasks no rank 0 (caso contrário não há paralelismo)
+- [ ] Cada `subtask_prompt` é executável sem contexto adicional
+- [ ] Tasks de teste/doc dependem da implementação correspondente
+- [ ] `complexity` reflete o esforço real (não tudo HIGH)
+- [ ] `id` em kebab-case e único
+- [ ] Sem ciclos
+- [ ] `TASKS.md` + `dare-dag.yaml` + `EXECUTION/task-*.md` consistentes