@dewtech/dare-cli 3.2.0 → 3.4.0

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

@@ -1,86 +1,86 @@
-# Comando: /dare-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: /dare-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`.

package/templates/ide/cursor/.cursor/commands/dare-bootstrap.md

@@ -1,27 +1,27 @@
-# Comando: /dare-bootstrap
-
-Executa o scaffolder oficial da stack registrada em `dare.config.json` para materializar o esqueleto do framework no projeto atual.
-
-> Este comando expõe o CLI `dare bootstrap` na IDE. O agente pode **rodar o comando no terminal** e interpretar a saída.
-
-## Quando usar
-
-- Logo após `dare init`, para gerar o esqueleto real do framework.
-- Quando `dare.config.json` existe mas os artefatos do framework ainda não foram gerados.
-
-## Como rodar
-
-```bash
-dare bootstrap
-dare bootstrap --force   # roda mesmo se já houver artefatos (pode sobrescrever)
-```
-
-## O que fazer
-
-1. Confirme que existe `dare.config.json` com a stack definida.
-2. Rode `dare bootstrap` (use `--force` apenas se o usuário aceitar sobrescrever arquivos existentes).
-3. Verifique a saída: arquivos gerados e próximos passos sugeridos pelo CLI.
-
-## Comandos relacionados
-
-`/dare-init` · `/dare-design`
+# Comando: /dare-bootstrap
+
+Executa o scaffolder oficial da stack registrada em `dare.config.json` para materializar o esqueleto do framework no projeto atual.
+
+> Este comando expõe o CLI `dare bootstrap` na IDE. O agente pode **rodar o comando no terminal** e interpretar a saída.
+
+## Quando usar
+
+- Logo após `dare init`, para gerar o esqueleto real do framework.
+- Quando `dare.config.json` existe mas os artefatos do framework ainda não foram gerados.
+
+## Como rodar
+
+```bash
+dare bootstrap
+dare bootstrap --force   # roda mesmo se já houver artefatos (pode sobrescrever)
+```
+
+## O que fazer
+
+1. Confirme que existe `dare.config.json` com a stack definida.
+2. Rode `dare bootstrap` (use `--force` apenas se o usuário aceitar sobrescrever arquivos existentes).
+3. Verifique a saída: arquivos gerados e próximos passos sugeridos pelo CLI.
+
+## Comandos relacionados
+
+`/dare-init` · `/dare-design`

package/templates/ide/cursor/.cursor/commands/dare-bugfix-design.md

@@ -1,64 +1,64 @@
----
-description: Analisa o projeto existente e gera um Design DARE focado na resolucao de um bug. Use quando precisar investigar e corrigir um erro complexo no sistema atual.
-globs: *
----
-
-# Generate Bugfix Design
-
-## Objetivo
-Analisar a base de código atual, diagnosticar um problema relatado e gerar um documento de Design (`DARE/DESIGN-Bugfix-[Nome].md`) focado especificamente na **correção do bug**, mapeando a causa raiz e o plano de ação cirúrgico.
-
-## Contexto
-Este comando é para **projetos legados** ou em andamento onde um erro foi encontrado. O foco aqui é **diagnóstico e correção**: encontrar a causa raiz, analisar impacto e planejar a correção mais segura possível.
-
-## Passos que a IA deve seguir:
-
-1. **Análise de Contexto:**
-   - Entender o comportamento atual (o bug) vs o comportamento esperado
-   - Analisar logs, stack traces ou descrições de erro fornecidas
-   - Identificar a área do código responsável pelo problema
-
-2. **Diagnóstico da Causa Raiz:**
-   - Por que o erro está ocorrendo?
-   - É um problema de lógica, banco de dados, concorrência ou segurança?
-
-3. **Geração do Documento:**
-   - Criar o arquivo `DARE/DESIGN-Bugfix-[Nome-do-Bug].md`
-
-## Estrutura do Documento Gerado:
-
-```markdown
-# Bugfix Design: [Nome do Bug]
-
-## Descrição do Problema
-- **Comportamento Atual:** [O que está acontecendo de errado]
-- **Comportamento Esperado:** [O que deveria acontecer]
-- **Passos para Reproduzir:** [Se conhecido]
-
-## Diagnóstico da Causa Raiz
-Explicação técnica detalhada de por que o erro ocorre. (Ex: "A query N+1 está estourando a memória", ou "A validação não verifica campos nulos").
-
-## Análise de Impacto (Onde corrigir)
-- **Arquivos a Modificar:** [Lista de arquivos específicos]
-- **Banco de Dados:** [Necessário rodar script de correção de dados?]
-- **Riscos da Correção:** [O que pode quebrar ao consertar isso?]
-
-## Plano de Ação (Correção Cirúrgica)
-1. [Passo 1: Ajustar a query no Repository]
-2. [Passo 2: Adicionar teste unitário para cobrir o caso]
-3. [Passo 3: Validar comportamento]
-
-## Testes Necessários
-- **Validation Gates:** [O que testar para garantir que o bug sumiu]
-- **Testes de Regressão:** [O que testar para garantir que não quebrou o resto]
-
-## Próximas Etapas
-1. Revisar e aprovar este Bugfix Design
-2. Executar `/generate-blueprint DARE/DESIGN-Bugfix-[Nome].md` (opcional, se a correção for grande)
-3. Ou ir direto para `/generate-tasks DARE/DESIGN-Bugfix-[Nome].md`
-```
-
-## Regras de Ouro:
-- **Seja Cirúrgico:** A correção deve ser o menor código possível para resolver o problema sem efeitos colaterais.
-- **Causa Raiz:** Não trate apenas o sintoma, identifique e corrija a causa raiz.
-- **Evite Regressão:** Sempre mapeie os riscos da correção.
+---
+description: Analisa o projeto existente e gera um Design DARE focado na resolucao de um bug. Use quando precisar investigar e corrigir um erro complexo no sistema atual.
+globs: *
+---
+
+# Generate Bugfix Design
+
+## Objetivo
+Analisar a base de código atual, diagnosticar um problema relatado e gerar um documento de Design (`DARE/DESIGN-Bugfix-[Nome].md`) focado especificamente na **correção do bug**, mapeando a causa raiz e o plano de ação cirúrgico.
+
+## Contexto
+Este comando é para **projetos legados** ou em andamento onde um erro foi encontrado. O foco aqui é **diagnóstico e correção**: encontrar a causa raiz, analisar impacto e planejar a correção mais segura possível.
+
+## Passos que a IA deve seguir:
+
+1. **Análise de Contexto:**
+   - Entender o comportamento atual (o bug) vs o comportamento esperado
+   - Analisar logs, stack traces ou descrições de erro fornecidas
+   - Identificar a área do código responsável pelo problema
+
+2. **Diagnóstico da Causa Raiz:**
+   - Por que o erro está ocorrendo?
+   - É um problema de lógica, banco de dados, concorrência ou segurança?
+
+3. **Geração do Documento:**
+   - Criar o arquivo `DARE/DESIGN-Bugfix-[Nome-do-Bug].md`
+
+## Estrutura do Documento Gerado:
+
+```markdown
+# Bugfix Design: [Nome do Bug]
+
+## Descrição do Problema
+- **Comportamento Atual:** [O que está acontecendo de errado]
+- **Comportamento Esperado:** [O que deveria acontecer]
+- **Passos para Reproduzir:** [Se conhecido]
+
+## Diagnóstico da Causa Raiz
+Explicação técnica detalhada de por que o erro ocorre. (Ex: "A query N+1 está estourando a memória", ou "A validação não verifica campos nulos").
+
+## Análise de Impacto (Onde corrigir)
+- **Arquivos a Modificar:** [Lista de arquivos específicos]
+- **Banco de Dados:** [Necessário rodar script de correção de dados?]
+- **Riscos da Correção:** [O que pode quebrar ao consertar isso?]
+
+## Plano de Ação (Correção Cirúrgica)
+1. [Passo 1: Ajustar a query no Repository]
+2. [Passo 2: Adicionar teste unitário para cobrir o caso]
+3. [Passo 3: Validar comportamento]
+
+## Testes Necessários
+- **Validation Gates:** [O que testar para garantir que o bug sumiu]
+- **Testes de Regressão:** [O que testar para garantir que não quebrou o resto]
+
+## Próximas Etapas
+1. Revisar e aprovar este Bugfix Design
+2. Executar `/generate-blueprint DARE/DESIGN-Bugfix-[Nome].md` (opcional, se a correção for grande)
+3. Ou ir direto para `/generate-tasks DARE/DESIGN-Bugfix-[Nome].md`
+```
+
+## Regras de Ouro:
+- **Seja Cirúrgico:** A correção deve ser o menor código possível para resolver o problema sem efeitos colaterais.
+- **Causa Raiz:** Não trate apenas o sintoma, identifique e corrija a causa raiz.
+- **Evite Regressão:** Sempre mapeie os riscos da correção.

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

@@ -1,110 +1,110 @@
-# Comando: /dare-dag-run
-
-## Descrição
-
-Executa o grafo de tasks definido em `DARE/dare-dag.yaml` usando o **Cursor
-como executor** e o CLI `dare` como orquestrador. O canvas ao vivo fica em
-`DARE/.canvas.md`.
-
-> **Sem API keys.** Você (Cursor) usa o plano da IDE em que o usuário já está
-> logado. O CLI apenas coordena estado, monta prompts e atualiza canvas.
-
-## Pré-requisitos
-
-- `DARE/dare-dag.yaml` existe e foi aprovado pelo usuário
-- Specs em `DARE/EXECUTION/task-<id>.md` geradas
-- `dare` disponível no PATH (`npm i -g @dewtech/dare-cli`)
-
-## 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 lógico)
-  - Cada task tem `id` único, `complexity`, `subtask_prompt`
-
-### 2. Pegar próximas tasks
-
-```bash
-dare execute --next
-```
-
-O CLI imprime as tasks ready do rank atual com o prompt completo (já com
-snippets dos outputs dos pais costurados). Use exatamente esses prompts.
-
-### 3. Sugerir abrir o canvas
-
-Antes de começar, peça ao usuário abrir `DARE/.canvas.md` em uma aba para
-acompanhar o progresso ao vivo.
-
-### 4. Executar cada task
-
-Para cada task ready:
-
-1. Leia `spec_file` se houver
-2. Implemente conforme o prompt
-3. Rode Ralph Loop: build → test → lint
-4. Registre o resultado:
-
-```bash
-# Sucesso
-dare execute --complete task-001 --output "Resumo + arquivos criados/modificados (paths)"
-
-# Falha
-dare execute --fail task-002 --reason "Mensagem clara da falha"
-```
-
-### 5. Avançar de rank
-
-Após registrar todos os `--complete`/`--fail` do rank atual:
-
-```bash
-dare execute --next
-```
-
-Se aparece `✅ All tasks resolved`, todas as tasks terminaram. Caso contrário,
-continue executando o próximo rank.
-
-### 6. Pós-execução
-
-Ao terminar:
-
-- Rode `dare execute --status` para ver o sumário final
-- Se houver FAILED: leia `DARE/EXECUTION/task-<id>.md` da que falhou,
-  corrija a spec ou o prompt, depois:
-
-  ```bash
-  dare execute --reset task-002    # volta para PENDING
-  dare execute --next              # tente novamente
-  ```
-
-## Comandos disponíveis
-
-| Comando | Função |
-|---------|--------|
-| `dare execute --next` | Imprime tasks ready do rank atual com prompts |
-| `dare execute --complete <id> --output "…"` | Marca DONE |
-| `dare execute --fail <id> --reason "…"` | Marca FAILED + cascade-skip |
-| `dare execute --reset <id>` | Volta para PENDING (retry) |
-| `dare execute --status` | Snapshot do canvas + sumário |
-
-## Erros comuns
-
-| Sintoma | Causa | Correção |
-|---------|-------|----------|
-| `dare-dag.yaml not found` | Não foi gerado | Rode `/generate-tasks` |
-| Cascata de SKIPPED | Pai falhou | Corrija pai → `--reset` → `--next` |
-| Output truncado em 4000 chars | Cap normal | Faça a task escrever em arquivo, retorne resumo |
-| Tudo no rank 0 disputa o mesmo arquivo | Ausência de deps reais | Edite `dare-dag.yaml` adicionando `depends_on` |
-
-## Referências
-
-- Skill: `.cursor/rules/skill-dag-runner.mdc`
-- Schema: `DARE/dare-dag.yaml`
-- Canvas: `DARE/.canvas.md`
-- Specs: `DARE/EXECUTION/task-*.md`
-
-$ARGUMENTS
+# Comando: /dare-dag-run
+
+## Descrição
+
+Executa o grafo de tasks definido em `DARE/dare-dag.yaml` usando o **Cursor
+como executor** e o CLI `dare` como orquestrador. O canvas ao vivo fica em
+`DARE/.canvas.md`.
+
+> **Sem API keys.** Você (Cursor) usa o plano da IDE em que o usuário já está
+> logado. O CLI apenas coordena estado, monta prompts e atualiza canvas.
+
+## Pré-requisitos
+
+- `DARE/dare-dag.yaml` existe e foi aprovado pelo usuário
+- Specs em `DARE/EXECUTION/task-<id>.md` geradas
+- `dare` disponível no PATH (`npm i -g @dewtech/dare-cli`)
+
+## 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 lógico)
+  - Cada task tem `id` único, `complexity`, `subtask_prompt`
+
+### 2. Pegar próximas tasks
+
+```bash
+dare execute --next
+```
+
+O CLI imprime as tasks ready do rank atual com o prompt completo (já com
+snippets dos outputs dos pais costurados). Use exatamente esses prompts.
+
+### 3. Sugerir abrir o canvas
+
+Antes de começar, peça ao usuário abrir `DARE/.canvas.md` em uma aba para
+acompanhar o progresso ao vivo.
+
+### 4. Executar cada task
+
+Para cada task ready:
+
+1. Leia `spec_file` se houver
+2. Implemente conforme o prompt
+3. Rode Ralph Loop: build → test → lint
+4. Registre o resultado:
+
+```bash
+# Sucesso
+dare execute --complete task-001 --output "Resumo + arquivos criados/modificados (paths)"
+
+# Falha
+dare execute --fail task-002 --reason "Mensagem clara da falha"
+```
+
+### 5. Avançar de rank
+
+Após registrar todos os `--complete`/`--fail` do rank atual:
+
+```bash
+dare execute --next
+```
+
+Se aparece `✅ All tasks resolved`, todas as tasks terminaram. Caso contrário,
+continue executando o próximo rank.
+
+### 6. Pós-execução
+
+Ao terminar:
+
+- Rode `dare execute --status` para ver o sumário final
+- Se houver FAILED: leia `DARE/EXECUTION/task-<id>.md` da que falhou,
+  corrija a spec ou o prompt, depois:
+
+  ```bash
+  dare execute --reset task-002    # volta para PENDING
+  dare execute --next              # tente novamente
+  ```
+
+## Comandos disponíveis
+
+| Comando | Função |
+|---------|--------|
+| `dare execute --next` | Imprime tasks ready do rank atual com prompts |
+| `dare execute --complete <id> --output "…"` | Marca DONE |
+| `dare execute --fail <id> --reason "…"` | Marca FAILED + cascade-skip |
+| `dare execute --reset <id>` | Volta para PENDING (retry) |
+| `dare execute --status` | Snapshot do canvas + sumário |
+
+## Erros comuns
+
+| Sintoma | Causa | Correção |
+|---------|-------|----------|
+| `dare-dag.yaml not found` | Não foi gerado | Rode `/generate-tasks` |
+| Cascata de SKIPPED | Pai falhou | Corrija pai → `--reset` → `--next` |
+| Output truncado em 4000 chars | Cap normal | Faça a task escrever em arquivo, retorne resumo |
+| Tudo no rank 0 disputa o mesmo arquivo | Ausência de deps reais | Edite `dare-dag.yaml` adicionando `depends_on` |
+
+## Referências
+
+- Skill: `.cursor/rules/skill-dag-runner.mdc`
+- Schema: `DARE/dare-dag.yaml`
+- Canvas: `DARE/.canvas.md`
+- Specs: `DARE/EXECUTION/task-*.md`
+
+$ARGUMENTS