@dewtech/dare-cli 3.2.0 → 3.4.0

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

@@ -1,119 +1,119 @@
-# /dare-bugfix-design
-
-Diagnostica bug em projeto existente e planeja correção cirúrgica via Método DARE. Gera `DARE/DESIGN-Bugfix-[Nome].md` com causa raiz, riscos de regressão e plano de ação mínimo.
-
-## Como usar
-
-```
-/dare-bugfix-design                                  # interativo: pede o relato
-/dare-bugfix-design "Login falha quando email tem +" # com descrição direta
-```
-
-## Quando usar
-
-- Usuário relata bug ou comportamento inesperado
-- Bug complexo precisa de planejamento antes de codar
-- Risco de regressão é não-trivial
-
-## O que fazer
-
-### 1. Entender o relato completo
-
-Antes de tocar em código, esclareça:
-- **Comportamento atual** — o que acontece de errado?
-- **Comportamento esperado** — o que deveria acontecer?
-- **Passos para reproduzir** — como você fez aparecer o bug?
-- **Logs/stack traces** — se houver, peça ao usuário
-
-### 2. Localizar a área afetada
-
-Identifique controllers, services, queries ou componentes envolvidos no fluxo. Use grep / IDE navigation para chegar nos arquivos mais prováveis.
-
-### 3. Encontrar a causa raiz (crítico)
-
-Não trate sintoma. Investigue o **porquê**:
-
-| Tipo de causa | Exemplos |
-|---|---|
-| Lógica de negócio | Condição incorreta, cálculo errado, off-by-one |
-| Banco de dados | N+1, deadlock, dados inconsistentes, índice ausente |
-| Validação | Input não validado, tipo incorreto, edge case (string vazia, NaN, negativo) |
-| Concorrência | Race condition, falta de lock, transação isolada errada |
-| Segurança | SQL injection, XSS, IDOR, broken auth |
-| Integração | Timeout, retry sem idempotência, API externa mudou contrato |
-
-### 4. Avaliar impacto e riscos
-
-- Quais arquivos precisam mudar?
-- Tem migração/script de DB?
-- O que mais essa correção pode quebrar?
-- Qual o blast radius?
-
-### 5. Gerar `DARE/DESIGN-Bugfix-[Nome].md`
-
-Estrutura obrigatória:
-
-```markdown
-# Bugfix Design: [Nome curto e descritivo]
-
-## Descrição do Problema
-- **Comportamento Atual:** [o que está acontecendo]
-- **Comportamento Esperado:** [o que deveria]
-- **Passos para Reproduzir:** [se conhecido]
-- **Severidade:** [Crítica / Alta / Média / Baixa]
-- **Reportado por:** [usuário / Sentry / monitoramento]
-
-## Diagnóstico da Causa Raiz
-[Explicação técnica detalhada do porquê o bug ocorre — referencie linhas de código específicas se possível]
-
-## Análise de Impacto
-- **Arquivos a Modificar:** [lista exata]
-- **Banco de Dados:** [migração necessária? script de fix de dados?]
-- **APIs externas:** [muda contrato com algum cliente/integrador?]
-- **Riscos de Regressão:** [o que pode quebrar ao consertar]
-
-## Plano de Ação (Correção Cirúrgica)
-1. [Passo 1: ajustar X em arquivo Y]
-2. [Passo 2: adicionar teste unitário que falha com o bug e passa com a correção]
-3. [Passo 3: validar comportamento em staging]
-
-## Testes Necessários
-- **Validation Gates:** [teste novo que reproduz o bug]
-- **Testes de Regressão:** [testes existentes a re-rodar]
-- **E2E:** [smoke test do fluxo afetado]
-
-## Rollback Plan
-[Se a correção quebrar produção, como reverter rapidamente?]
-
-## Próximas Etapas
-1. Revisar e aprovar este Bugfix Design
-2. Rodar `/dare-blueprint` se a correção for grande, ou ir direto para `/dare-tasks`
-3. Se for trivial (< 10 linhas), pular direto para `/dare-execute`
-```
-
-### 6. Pedir aprovação
-
-Apresente o documento ao usuário e peça aprovação antes de prosseguir. Bugfix sem diagnóstico aprovado vira chumbadeira.
-
-## Regras de ouro
-
-1. **Cirúrgico** — menor código possível, sem efeitos colaterais
-2. **Causa raiz, não sintoma** — se a raiz não for corrigida, o bug volta
-3. **Teste novo obrigatório** — se o bug ocorreu, faltava teste. Adicione um que falharia com o código antigo
-4. **Mapeie regressão** — sempre planeje o que pode quebrar e como detectar
-
-## Antipatterns
-
-| AP | Antipattern | Por quê |
-|---|---|---|
-| AP-01 | Tratar só o sintoma | Bug volta em variação diferente |
-| AP-02 | Corrigir sem reproduzir | Não tem como validar que sumiu |
-| AP-03 | Mudar arquivos não relacionados | Aumenta blast radius desnecessariamente |
-| AP-04 | Não adicionar teste | Bug pode reaparecer em regressão futura |
-| AP-05 | Pular aprovação humana | Bugfix mal planejado vira bug pior |
-
-$ARGUMENTS
-
----
-
-Skill MIT — parte do DARE Method.
+# /dare-bugfix-design
+
+Diagnostica bug em projeto existente e planeja correção cirúrgica via Método DARE. Gera `DARE/DESIGN-Bugfix-[Nome].md` com causa raiz, riscos de regressão e plano de ação mínimo.
+
+## Como usar
+
+```
+/dare-bugfix-design                                  # interativo: pede o relato
+/dare-bugfix-design "Login falha quando email tem +" # com descrição direta
+```
+
+## Quando usar
+
+- Usuário relata bug ou comportamento inesperado
+- Bug complexo precisa de planejamento antes de codar
+- Risco de regressão é não-trivial
+
+## O que fazer
+
+### 1. Entender o relato completo
+
+Antes de tocar em código, esclareça:
+- **Comportamento atual** — o que acontece de errado?
+- **Comportamento esperado** — o que deveria acontecer?
+- **Passos para reproduzir** — como você fez aparecer o bug?
+- **Logs/stack traces** — se houver, peça ao usuário
+
+### 2. Localizar a área afetada
+
+Identifique controllers, services, queries ou componentes envolvidos no fluxo. Use grep / IDE navigation para chegar nos arquivos mais prováveis.
+
+### 3. Encontrar a causa raiz (crítico)
+
+Não trate sintoma. Investigue o **porquê**:
+
+| Tipo de causa | Exemplos |
+|---|---|
+| Lógica de negócio | Condição incorreta, cálculo errado, off-by-one |
+| Banco de dados | N+1, deadlock, dados inconsistentes, índice ausente |
+| Validação | Input não validado, tipo incorreto, edge case (string vazia, NaN, negativo) |
+| Concorrência | Race condition, falta de lock, transação isolada errada |
+| Segurança | SQL injection, XSS, IDOR, broken auth |
+| Integração | Timeout, retry sem idempotência, API externa mudou contrato |
+
+### 4. Avaliar impacto e riscos
+
+- Quais arquivos precisam mudar?
+- Tem migração/script de DB?
+- O que mais essa correção pode quebrar?
+- Qual o blast radius?
+
+### 5. Gerar `DARE/DESIGN-Bugfix-[Nome].md`
+
+Estrutura obrigatória:
+
+```markdown
+# Bugfix Design: [Nome curto e descritivo]
+
+## Descrição do Problema
+- **Comportamento Atual:** [o que está acontecendo]
+- **Comportamento Esperado:** [o que deveria]
+- **Passos para Reproduzir:** [se conhecido]
+- **Severidade:** [Crítica / Alta / Média / Baixa]
+- **Reportado por:** [usuário / Sentry / monitoramento]
+
+## Diagnóstico da Causa Raiz
+[Explicação técnica detalhada do porquê o bug ocorre — referencie linhas de código específicas se possível]
+
+## Análise de Impacto
+- **Arquivos a Modificar:** [lista exata]
+- **Banco de Dados:** [migração necessária? script de fix de dados?]
+- **APIs externas:** [muda contrato com algum cliente/integrador?]
+- **Riscos de Regressão:** [o que pode quebrar ao consertar]
+
+## Plano de Ação (Correção Cirúrgica)
+1. [Passo 1: ajustar X em arquivo Y]
+2. [Passo 2: adicionar teste unitário que falha com o bug e passa com a correção]
+3. [Passo 3: validar comportamento em staging]
+
+## Testes Necessários
+- **Validation Gates:** [teste novo que reproduz o bug]
+- **Testes de Regressão:** [testes existentes a re-rodar]
+- **E2E:** [smoke test do fluxo afetado]
+
+## Rollback Plan
+[Se a correção quebrar produção, como reverter rapidamente?]
+
+## Próximas Etapas
+1. Revisar e aprovar este Bugfix Design
+2. Rodar `/dare-blueprint` se a correção for grande, ou ir direto para `/dare-tasks`
+3. Se for trivial (< 10 linhas), pular direto para `/dare-execute`
+```
+
+### 6. Pedir aprovação
+
+Apresente o documento ao usuário e peça aprovação antes de prosseguir. Bugfix sem diagnóstico aprovado vira chumbadeira.
+
+## Regras de ouro
+
+1. **Cirúrgico** — menor código possível, sem efeitos colaterais
+2. **Causa raiz, não sintoma** — se a raiz não for corrigida, o bug volta
+3. **Teste novo obrigatório** — se o bug ocorreu, faltava teste. Adicione um que falharia com o código antigo
+4. **Mapeie regressão** — sempre planeje o que pode quebrar e como detectar
+
+## Antipatterns
+
+| AP | Antipattern | Por quê |
+|---|---|---|
+| AP-01 | Tratar só o sintoma | Bug volta em variação diferente |
+| AP-02 | Corrigir sem reproduzir | Não tem como validar que sumiu |
+| AP-03 | Mudar arquivos não relacionados | Aumenta blast radius desnecessariamente |
+| AP-04 | Não adicionar teste | Bug pode reaparecer em regressão futura |
+| AP-05 | Pular aprovação humana | Bugfix mal planejado vira bug pior |
+
+$ARGUMENTS
+
+---
+
+Skill MIT — parte do DARE Method.

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

@@ -1,151 +1,151 @@
-# /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
-
-### 3.1 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. **Não é negociável**. O comando `dare review <task-id>` (v2.17+) detecta isso e marca a task como FAILED.
-
-Cada `subtask_prompt` e `EXECUTION/task-<id>.md` deve atender este contrato:
-
-**O `subtask_prompt` deve ser auto-suficiente**
-
-O subagente recebe **apenas** o `subtask_prompt` + snippets de 2000 chars dos pais. Tudo que ele precisa para implementar **sem inventar** deve estar ali ou na `spec_file`. 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`) deve 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` / `return undefined` / `return {}` como única statement de função pública
-- [ ] Mocks **somente** dentro de `*.test.*`, `*.spec.*`, `__tests__/`, `tests/`, `spec/` — NUNCA em código de produção
-- [ ] Todos os endpoints declarados na seção 3 retornam dados reais (não fixos / hardcoded)
-- [ ] Cada validação da spec produz erro real com status code correto (testado)
-- [ ] Cada edge case da spec tem teste unitário ou integração demonstrando comportamento
-```
-
-**Verificação automatizável:** o agente vai rodar `dare review <id>` antes de marcar DONE. Se a review falhar, a task volta para revisão.
-
-**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"
-
-### 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
+# /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
+
+### 3.1 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. **Não é negociável**. O comando `dare review <task-id>` (v2.17+) detecta isso e marca a task como FAILED.
+
+Cada `subtask_prompt` e `EXECUTION/task-<id>.md` deve atender este contrato:
+
+**O `subtask_prompt` deve ser auto-suficiente**
+
+O subagente recebe **apenas** o `subtask_prompt` + snippets de 2000 chars dos pais. Tudo que ele precisa para implementar **sem inventar** deve estar ali ou na `spec_file`. 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`) deve 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` / `return undefined` / `return {}` como única statement de função pública
+- [ ] Mocks **somente** dentro de `*.test.*`, `*.spec.*`, `__tests__/`, `tests/`, `spec/` — NUNCA em código de produção
+- [ ] Todos os endpoints declarados na seção 3 retornam dados reais (não fixos / hardcoded)
+- [ ] Cada validação da spec produz erro real com status code correto (testado)
+- [ ] Cada edge case da spec tem teste unitário ou integração demonstrando comportamento
+```
+
+**Verificação automatizável:** o agente vai rodar `dare review <id>` antes de marcar DONE. Se a review falhar, a task volta para revisão.
+
+**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"
+
+### 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