@dewtech/dare-cli 3.2.0 → 3.4.0

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

@@ -1,32 +1,32 @@
----
-name: dare-bootstrap
-description: Executa o scaffolder oficial da stack registrada em `dare.config.json` para materializar o esqueleto do framework no projeto atual. Mapeia o CLI `dare bootstrap`.
----
-
-# Rodar o scaffold oficial da stack do projeto
-
-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`
+---
+name: dare-bootstrap
+description: Executa o scaffolder oficial da stack registrada em `dare.config.json` para materializar o esqueleto do framework no projeto atual. Mapeia o CLI `dare bootstrap`.
+---
+
+# Rodar o scaffold oficial da stack do projeto
+
+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/antigravity/.agents/skills/dare-bugfix-design/SKILL.md

@@ -1,76 +1,76 @@
----
-name: dare-bugfix-design
-description: Analisa um projeto existente e gera um Implementation Plan focado apenas na correcao de um bug complexo. Use quando precisar diagnosticar e corrigir um erro no sistema atual. Cria um documento DESIGN-Bugfix-[Nome].md.
----
-
-# DARE Bugfix Design Skill
-
-Você é um especialista em diagnóstico de software e correção cirúrgica de bugs. Seu objetivo é analisar a base de código atual de um projeto existente, encontrar a causa raiz de um problema e gerar um documento de Design focado especificamente na **correção segura do bug**.
-
-## Quando usar esta skill
-
-- O usuário relata um bug ou comportamento inesperado no sistema.
-- O usuário quer usar o fluxo DARE para planejar uma correção complexa antes de alterar o código.
-
-## Como usar
-
-### Passo 1: Análise de Contexto (Diagnóstico)
-Antes de propor uma solução, você DEVE diagnosticar o problema:
-1. **Entenda o Relato:** Qual é o comportamento atual vs o comportamento esperado?
-2. **Analise Logs/Erros:** Peça ao usuário stack traces ou logs, se aplicável.
-3. **Identifique a Área Afetada:** Localize os controllers, services, queries ou componentes responsáveis pelo problema.
-
-### Passo 2: Encontrar a Causa Raiz
-Não trate apenas o sintoma. Descubra *por que* o erro acontece:
-- É um problema de lógica de negócio?
-- É um erro de banco de dados (ex: N+1, deadlock, timeout)?
-- É uma falha de validação ou segurança?
-- É um problema de concorrência?
-
-### Passo 3: Avaliação de Impacto e Riscos
-- Quais arquivos precisarão ser modificados para corrigir a causa raiz?
-- **Risco de Regressão:** O que mais essa correção pode quebrar no sistema?
-
-### Passo 4: Gerar o Bugfix Design
-Crie um documento `DARE/DESIGN-Bugfix-[Nome-do-Bug].md` com a seguinte estrutura:
-
-```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].
-
-## 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/lógica no arquivo X]
-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 o Agent com a skill `dare-blueprint` apontando para este arquivo (se a correção for grande)
-3. Ou ir direto para a skill `dare-tasks` se for simples
-```
-
-### Passo 5: Pedir Aprovação
-Após gerar o Design, crie um Artifact do tipo Implementation Plan e peça ao usuário para revisar o diagnóstico e a abordagem da correção.
-
-## Regras de Ouro para Bugfixes
-
-1. **Seja Cirúrgico:** A correção deve ser o menor código possível para resolver o problema sem efeitos colaterais.
-2. **Causa Raiz:** Foque na origem do problema, não no sintoma.
-3. **Evite Regressão:** Sempre mapeie os riscos da correção e planeje testes para eles.
-4. **Adicione Testes:** Se o bug ocorreu, é porque faltava um teste. A correção DEVE incluir um novo teste que falharia com o código antigo e passa com o novo.
+---
+name: dare-bugfix-design
+description: Analisa um projeto existente e gera um Implementation Plan focado apenas na correcao de um bug complexo. Use quando precisar diagnosticar e corrigir um erro no sistema atual. Cria um documento DESIGN-Bugfix-[Nome].md.
+---
+
+# DARE Bugfix Design Skill
+
+Você é um especialista em diagnóstico de software e correção cirúrgica de bugs. Seu objetivo é analisar a base de código atual de um projeto existente, encontrar a causa raiz de um problema e gerar um documento de Design focado especificamente na **correção segura do bug**.
+
+## Quando usar esta skill
+
+- O usuário relata um bug ou comportamento inesperado no sistema.
+- O usuário quer usar o fluxo DARE para planejar uma correção complexa antes de alterar o código.
+
+## Como usar
+
+### Passo 1: Análise de Contexto (Diagnóstico)
+Antes de propor uma solução, você DEVE diagnosticar o problema:
+1. **Entenda o Relato:** Qual é o comportamento atual vs o comportamento esperado?
+2. **Analise Logs/Erros:** Peça ao usuário stack traces ou logs, se aplicável.
+3. **Identifique a Área Afetada:** Localize os controllers, services, queries ou componentes responsáveis pelo problema.
+
+### Passo 2: Encontrar a Causa Raiz
+Não trate apenas o sintoma. Descubra *por que* o erro acontece:
+- É um problema de lógica de negócio?
+- É um erro de banco de dados (ex: N+1, deadlock, timeout)?
+- É uma falha de validação ou segurança?
+- É um problema de concorrência?
+
+### Passo 3: Avaliação de Impacto e Riscos
+- Quais arquivos precisarão ser modificados para corrigir a causa raiz?
+- **Risco de Regressão:** O que mais essa correção pode quebrar no sistema?
+
+### Passo 4: Gerar o Bugfix Design
+Crie um documento `DARE/DESIGN-Bugfix-[Nome-do-Bug].md` com a seguinte estrutura:
+
+```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].
+
+## 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/lógica no arquivo X]
+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 o Agent com a skill `dare-blueprint` apontando para este arquivo (se a correção for grande)
+3. Ou ir direto para a skill `dare-tasks` se for simples
+```
+
+### Passo 5: Pedir Aprovação
+Após gerar o Design, crie um Artifact do tipo Implementation Plan e peça ao usuário para revisar o diagnóstico e a abordagem da correção.
+
+## Regras de Ouro para Bugfixes
+
+1. **Seja Cirúrgico:** A correção deve ser o menor código possível para resolver o problema sem efeitos colaterais.
+2. **Causa Raiz:** Foque na origem do problema, não no sintoma.
+3. **Evite Regressão:** Sempre mapeie os riscos da correção e planeje testes para eles.
+4. **Adicione Testes:** Se o bug ocorreu, é porque faltava um teste. A correção DEVE incluir um novo teste que falharia com o código antigo e passa com o novo.

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

@@ -1,32 +1,32 @@
----
-name: dare-dag
-description: Mostra o DAG estático de tasks (`DARE/dare-dag.yaml`): ranks, dependências e caminho crítico. Use `dare dag viz` para exportar o diagrama. Mapeia o CLI `dare dag`.
----
-
-# Inspecionar e visualizar o DAG de tasks
-
-Mostra o DAG estático de tasks (`DARE/dare-dag.yaml`): ranks, dependências e caminho crítico. Use `dare dag viz` para exportar o diagrama.
-
-> Este comando expõe o CLI `dare dag` na IDE. O agente pode **rodar o comando no terminal** e interpretar a saída.
-
-## Quando usar
-
-- Você quer ver a ordem de execução, os ranks e o caminho crítico das tasks.
-- Antes de começar a execução, para conferir a topologia do plano.
-
-## Como rodar
-
-```bash
-dare dag viz
-dare dag viz --dag DARE/dare-dag.yaml
-```
-
-## O que fazer
-
-1. Rode `dare dag viz` para renderizar o grafo de tasks.
-2. Confira ranks e dependências; tasks de mesmo rank podem rodar em paralelo.
-3. Para validar a integridade do arquivo, use `/dare-validate`. Para executar, `/dare-execute`.
-
-## Comandos relacionados
-
-`/dare-validate` · `/dare-execute` · `/dare-graph`
+---
+name: dare-dag
+description: Mostra o DAG estático de tasks (`DARE/dare-dag.yaml`): ranks, dependências e caminho crítico. Use `dare dag viz` para exportar o diagrama. Mapeia o CLI `dare dag`.
+---
+
+# Inspecionar e visualizar o DAG de tasks
+
+Mostra o DAG estático de tasks (`DARE/dare-dag.yaml`): ranks, dependências e caminho crítico. Use `dare dag viz` para exportar o diagrama.
+
+> Este comando expõe o CLI `dare dag` na IDE. O agente pode **rodar o comando no terminal** e interpretar a saída.
+
+## Quando usar
+
+- Você quer ver a ordem de execução, os ranks e o caminho crítico das tasks.
+- Antes de começar a execução, para conferir a topologia do plano.
+
+## Como rodar
+
+```bash
+dare dag viz
+dare dag viz --dag DARE/dare-dag.yaml
+```
+
+## O que fazer
+
+1. Rode `dare dag viz` para renderizar o grafo de tasks.
+2. Confira ranks e dependências; tasks de mesmo rank podem rodar em paralelo.
+3. Para validar a integridade do arquivo, use `/dare-validate`. Para executar, `/dare-execute`.
+
+## Comandos relacionados
+
+`/dare-validate` · `/dare-execute` · `/dare-graph`

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

@@ -1,154 +1,154 @@
----
-name: dare-dag-build
-description: Regenera APENAS o DARE/dare-dag.yaml a partir do DARE/BLUEPRINT.md existente, sem refazer o blueprint nem as specs. Use quando o BLUEPRINT mudou pouco mas o grafo precisa refletir o novo estado, ou quando você quer experimentar uma decomposição diferente.
----
-
-# DARE DAG Build Skill
-
-Você é o construtor de grafos da fase EXECUTE do método DARE no Antigravity. Esta skill **regenera APENAS** o `DARE/dare-dag.yaml` — não refaz o BLUEPRINT, não refaz as specs, não roda nada. Apenas reconstrói o grafo de tasks a partir do estado atual do BLUEPRINT.
-
-> Se você precisa **executar** o grafo, use `dare-dag-run`.
-> Se você precisa **visualizar** o grafo, use `dare-dag-viz`.
-> Se você precisa **fazer tudo de uma vez** (build + run), use `dare-dag-runner`.
-
-## Quando usar esta skill
-
-- O BLUEPRINT foi ajustado e o grafo precisa refletir as mudanças
-- 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
-- A complexidade ou as dependências de tasks mudaram
-
-## Pré-requisitos
-
-- `DARE/BLUEPRINT.md` existe e está aprovado
-- (Opcional) `DARE/EXECUTION/task-*.md` específicas — serão preservadas se não forem mencionadas
-
-## Como usar
-
-### Passo 1 — Ler `DARE/BLUEPRINT.md`
-
-Obrigatório. Se faltar, peça `dare-blueprint` antes.
-
-### Passo 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.
-
-### Passo 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 do pai
-- `subtask_prompt` self-contained (o subagente recebe apenas isso + 2000 chars dos pais)
-- Pelo menos **2 tasks no rank 0** (paralelismo desde o início)
-- Cadeia linear é antipattern — quebre dependências sempre que possível
-- `complexity` honesta — não inflar nem deflar
-
-### Passo 4 — ANTI-STUB CONTRACT (inegociável)
-
-Tasks geradas com `subtask_prompt` ou spec genéricos forçam o agente a inventar — e ele vai produzir mock, stub ou esqueleto. **O comando `dare-review` detecta isso e marca a task como FAILED.**
-
-Cada `subtask_prompt` e `EXECUTION/task-<id>.md` deve atender:
-
-**O `subtask_prompt` precisa ser auto-suficiente.** Inclua:
-- Caminho exato dos arquivos a criar/modificar
-- Assinaturas exatas das funções/endpoints (`fn name(params: T) -> R`)
-- Schema de request/response com tipos
-- Validações específicas (não "validar input" — `email: regex /^.../`, `senha: ≥ 8 chars + 1 maiúscula + 1 dígito`)
-- Edge cases enumerados (input vazio, duplicado, expirado, sem permissão)
-- Lista de testes esperados com nome + comportamento
-
-**A `spec_file` (`EXECUTION/task-<id>.md`) precisa ter Definition of Done anti-stub:**
-
-```markdown
-## Definition of Done (ANTI-STUB)
-
-- [ ] Nenhum TODO, FIXME, XXX ou HACK em arquivos modificados
-- [ ] Nenhuma função vazia (fn x() {}, def x(): pass, function x() {})
-- [ ] Nenhum throw new Error('not implemented'), unimplemented!(), todo!(), NotImplementedError
-- [ ] Nenhum return null/undefined/{} como única statement de função pública
-- [ ] Mocks SOMENTE em *.test.*, *.spec.*, __tests__/, tests/, spec/ — NUNCA em código de produção
-- [ ] Todos os endpoints retornam dados reais (não hardcoded)
-- [ ] Cada validação produz erro real com status code correto (testado)
-- [ ] Cada edge case tem teste demonstrando comportamento
-```
-
-**Sinais de spec rasa (auto-validar antes de salvar):**
-
-- ❌ "Implementar X" — sem assinatura, sem retorno, sem validações
-- ❌ "Tratar erros adequadamente" — quais erros? como? que código?
-- ❌ "Adicionar validações" — quais regras?
-- ✅ "Implementar `POST /auth/login` retornando `{ token: string, refresh: string }` com 200 se credenciais válidas, 401 se inválidas, 429 se rate limit"
-
-### Passo 5 — Validar consistência com `EXECUTION/task-*.md`
-
-Se uma spec já 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?
-
-### Passo 6 — Validar grafo
-
-- Sem ciclos (DAG = Directed Acyclic Graph)
-- Todos os `depends_on` apontam para `id`s existentes
-- `id`s únicos
-- Pelo menos 2 tasks no rank 0
-
-### Passo 7 — Atualizar `DARE/TASKS.md`
-
-Reflita o novo grafo na tabela master.
-
-### Passo 8 — Mensagem ao usuário
-
-> `dare-dag.yaml` regenerado:
-> - Total de tasks: N
-> - Ranks paralelos: N
-> - Adicionadas: [...]
-> - Removidas: [...]
-> - Modificadas: [...]
->
-> Revise e aprove. Para executar: invoque a skill `dare-dag-run`.
-
-## Quando NÃO usar esta skill
-
-- Se você nunca rodou `dare-blueprint` antes — use `dare-blueprint` primeiro
-- Se o BLUEPRINT está desatualizado — atualize o BLUEPRINT primeiro
-- Se você só quer executar o grafo já aprovado — use `dare-dag-run`
-- 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-build
+description: Regenera APENAS o DARE/dare-dag.yaml a partir do DARE/BLUEPRINT.md existente, sem refazer o blueprint nem as specs. Use quando o BLUEPRINT mudou pouco mas o grafo precisa refletir o novo estado, ou quando você quer experimentar uma decomposição diferente.
+---
+
+# DARE DAG Build Skill
+
+Você é o construtor de grafos da fase EXECUTE do método DARE no Antigravity. Esta skill **regenera APENAS** o `DARE/dare-dag.yaml` — não refaz o BLUEPRINT, não refaz as specs, não roda nada. Apenas reconstrói o grafo de tasks a partir do estado atual do BLUEPRINT.
+
+> Se você precisa **executar** o grafo, use `dare-dag-run`.
+> Se você precisa **visualizar** o grafo, use `dare-dag-viz`.
+> Se você precisa **fazer tudo de uma vez** (build + run), use `dare-dag-runner`.
+
+## Quando usar esta skill
+
+- O BLUEPRINT foi ajustado e o grafo precisa refletir as mudanças
+- 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
+- A complexidade ou as dependências de tasks mudaram
+
+## Pré-requisitos
+
+- `DARE/BLUEPRINT.md` existe e está aprovado
+- (Opcional) `DARE/EXECUTION/task-*.md` específicas — serão preservadas se não forem mencionadas
+
+## Como usar
+
+### Passo 1 — Ler `DARE/BLUEPRINT.md`
+
+Obrigatório. Se faltar, peça `dare-blueprint` antes.
+
+### Passo 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.
+
+### Passo 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 do pai
+- `subtask_prompt` self-contained (o subagente recebe apenas isso + 2000 chars dos pais)
+- Pelo menos **2 tasks no rank 0** (paralelismo desde o início)
+- Cadeia linear é antipattern — quebre dependências sempre que possível
+- `complexity` honesta — não inflar nem deflar
+
+### Passo 4 — ANTI-STUB CONTRACT (inegociável)
+
+Tasks geradas com `subtask_prompt` ou spec genéricos forçam o agente a inventar — e ele vai produzir mock, stub ou esqueleto. **O comando `dare-review` detecta isso e marca a task como FAILED.**
+
+Cada `subtask_prompt` e `EXECUTION/task-<id>.md` deve atender:
+
+**O `subtask_prompt` precisa ser auto-suficiente.** Inclua:
+- Caminho exato dos arquivos a criar/modificar
+- Assinaturas exatas das funções/endpoints (`fn name(params: T) -> R`)
+- Schema de request/response com tipos
+- Validações específicas (não "validar input" — `email: regex /^.../`, `senha: ≥ 8 chars + 1 maiúscula + 1 dígito`)
+- Edge cases enumerados (input vazio, duplicado, expirado, sem permissão)
+- Lista de testes esperados com nome + comportamento
+
+**A `spec_file` (`EXECUTION/task-<id>.md`) precisa ter Definition of Done anti-stub:**
+
+```markdown
+## Definition of Done (ANTI-STUB)
+
+- [ ] Nenhum TODO, FIXME, XXX ou HACK em arquivos modificados
+- [ ] Nenhuma função vazia (fn x() {}, def x(): pass, function x() {})
+- [ ] Nenhum throw new Error('not implemented'), unimplemented!(), todo!(), NotImplementedError
+- [ ] Nenhum return null/undefined/{} como única statement de função pública
+- [ ] Mocks SOMENTE em *.test.*, *.spec.*, __tests__/, tests/, spec/ — NUNCA em código de produção
+- [ ] Todos os endpoints retornam dados reais (não hardcoded)
+- [ ] Cada validação produz erro real com status code correto (testado)
+- [ ] Cada edge case tem teste demonstrando comportamento
+```
+
+**Sinais de spec rasa (auto-validar antes de salvar):**
+
+- ❌ "Implementar X" — sem assinatura, sem retorno, sem validações
+- ❌ "Tratar erros adequadamente" — quais erros? como? que código?
+- ❌ "Adicionar validações" — quais regras?
+- ✅ "Implementar `POST /auth/login` retornando `{ token: string, refresh: string }` com 200 se credenciais válidas, 401 se inválidas, 429 se rate limit"
+
+### Passo 5 — Validar consistência com `EXECUTION/task-*.md`
+
+Se uma spec já 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?
+
+### Passo 6 — Validar grafo
+
+- Sem ciclos (DAG = Directed Acyclic Graph)
+- Todos os `depends_on` apontam para `id`s existentes
+- `id`s únicos
+- Pelo menos 2 tasks no rank 0
+
+### Passo 7 — Atualizar `DARE/TASKS.md`
+
+Reflita o novo grafo na tabela master.
+
+### Passo 8 — Mensagem ao usuário
+
+> `dare-dag.yaml` regenerado:
+> - Total de tasks: N
+> - Ranks paralelos: N
+> - Adicionadas: [...]
+> - Removidas: [...]
+> - Modificadas: [...]
+>
+> Revise e aprove. Para executar: invoque a skill `dare-dag-run`.
+
+## Quando NÃO usar esta skill
+
+- Se você nunca rodou `dare-blueprint` antes — use `dare-blueprint` primeiro
+- Se o BLUEPRINT está desatualizado — atualize o BLUEPRINT primeiro
+- Se você só quer executar o grafo já aprovado — use `dare-dag-run`
+- 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).