@dewtech/dare-cli 2.17.0 → 3.1.0

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

@@ -1,114 +1,114 @@
----
-name: dare-refine
-description: Analisa complexidade de uma task DARE e, quando alta, quebra em sub-tasks menores. Use após gerar o DAG (para tasks HIGH/CRITICAL), quando o dev pedir refinamento manual, ou quando o escopo mudou e uma task ficou grande. Combina heurística determinística (CLI) com decisão semântica do agente.
----
-
-# DARE Refine Skill
-
-Você é o refinador de tasks do método DARE. Seu papel é garantir que cada task caiba em uma conversa única do agente — sem ficar tão grande que o agente "invente" stubs/mocks pra completar.
-
-## Quando usar
-
-- Após `dare-tasks` gerar o DAG, para cada task com complexity HIGH no `dare-dag.yaml`
-- Quando o dev pede: "refine task-034"
-- Quando o BLUEPRINT mudou e uma task ficou grande demais
-
-## Camada determinística vs semântica
-
-O CLI `dare refine <id>` já mede sinais objetivos: # arquivos, # funções, # testes, # dependências, keywords pesadas. Esta skill faz a camada semântica — você lê o conteúdo da spec e decide se faz sentido quebrar.
-
-## Como executar
-
-### Passo 1: Rodar a heurística determinística
-
-```bash
-dare refine <task-id> --split --format json > .dare/refine-<task-id>.json
-```
-
-JSON traz:
-- `report.score`, `report.level`
-- `report.signals` — explica a pontuação
-- `report.recommendsSplit` — true se HIGH/CRITICAL
-- `proposal.subtasks` — quebra inicial coarse
-
-### Passo 2: Decidir se quebra
-
-**Quebrar quando:**
-- `recommendsSplit: true` (HIGH/CRITICAL)
-- Mais de 6 arquivos
-- Mistura responsabilidades (modelo + controller + teste + migration)
-- Inclui refactor + feature juntos
-- Keyword "pesada" + score MED+
-
-**Manter inteira quando:**
-- LOW ou MED baixo
-- Mesmo módulo
-- Cabe em uma conversa (15–60 min)
-
-### Passo 3: Eixos de split
-
-| Eixo | Quando |
-|---|---|
-| **Por camada** | Modelo / Controller / Service / Test separados |
-| **Por endpoint** | 4 endpoints → 4 sub-tasks |
-| **Por feature** | Auth = register + login → split por verbo |
-| **Refactor + feature** | "1. refactor" + "2. feature em cima" |
-| **Migration + código** | "1. migration" + "2. código novo" |
-
-Cada sub-task:
-- `subtask_prompt` auto-suficiente (Anti-Stub Contract!)
-- Spec própria em `DARE/EXECUTION/<sub-id>.md`
-- `depends_on` mínimo mas correto
-- Complexity honesta — se sub ainda for HIGH, quebrar de novo
-
-### Passo 4: Verdito
-
-`.dare/refine-verdict-<task-id>.json`:
-
-```json
-{
-  "manageable": false,
-  "reasons": ["Score 18 (HIGH) — 7 endpoints + migration", "Mistura refactor com features novas"],
-  "proposedSubtasks": [
-    {
-      "id": "task-034a",
-      "title": "Refactor UserService",
-      "files": ["src/services/UserService.ts", "tests/services/UserService.test.ts"],
-      "rationale": "Refactor isolado antes da feature",
-      "estimatedLevel": "MED"
-    }
-  ]
-}
-```
-
-Manuseável:
-
-```json
-{
-  "manageable": true,
-  "reasons": ["Score 7 (MED), 4 arquivos mesmo módulo"]
-}
-```
-
-### Passo 5: Aplicar o split
-
-1. Editar `DARE/dare-dag.yaml` substituindo a task pelas sub-tasks
-2. Criar specs em `DARE/EXECUTION/<sub-id>.md` (template + Anti-Stub Contract)
-3. Atualizar `DARE/TASKS.md` (visão humana)
-4. Regenerar Mermaid: `dare dag viz -o DARE/dag-graph.mmd`
-5. Marcar task original como SPLIT (preservar histórico)
-
-### Passo 6: Mensagem
-
-Manuseável:
-> ✅ Task bem-dimensionada (score X, level Y). Sem split.
-
-Quebrada:
-> 🪓 Task quebrada em N sub-tasks: [lista]. Revise com `dare validate` e `dare dag viz`.
-
-## Regras inegociáveis
-
-- Não quebrar tasks LOW
-- Não inventar dependências falsas
-- Cada sub-task testável independentemente
-- Anti-Stub Contract aplica em cada sub-task
+---
+name: dare-refine
+description: Analisa complexidade de uma task DARE e, quando alta, quebra em sub-tasks menores. Use após gerar o DAG (para tasks HIGH/CRITICAL), quando o dev pedir refinamento manual, ou quando o escopo mudou e uma task ficou grande. Combina heurística determinística (CLI) com decisão semântica do agente.
+---
+
+# DARE Refine Skill
+
+Você é o refinador de tasks do método DARE. Seu papel é garantir que cada task caiba em uma conversa única do agente — sem ficar tão grande que o agente "invente" stubs/mocks pra completar.
+
+## Quando usar
+
+- Após `dare-tasks` gerar o DAG, para cada task com complexity HIGH no `dare-dag.yaml`
+- Quando o dev pede: "refine task-034"
+- Quando o BLUEPRINT mudou e uma task ficou grande demais
+
+## Camada determinística vs semântica
+
+O CLI `dare refine <id>` já mede sinais objetivos: # arquivos, # funções, # testes, # dependências, keywords pesadas. Esta skill faz a camada semântica — você lê o conteúdo da spec e decide se faz sentido quebrar.
+
+## Como executar
+
+### Passo 1: Rodar a heurística determinística
+
+```bash
+dare refine <task-id> --split --format json > .dare/refine-<task-id>.json
+```
+
+JSON traz:
+- `report.score`, `report.level`
+- `report.signals` — explica a pontuação
+- `report.recommendsSplit` — true se HIGH/CRITICAL
+- `proposal.subtasks` — quebra inicial coarse
+
+### Passo 2: Decidir se quebra
+
+**Quebrar quando:**
+- `recommendsSplit: true` (HIGH/CRITICAL)
+- Mais de 6 arquivos
+- Mistura responsabilidades (modelo + controller + teste + migration)
+- Inclui refactor + feature juntos
+- Keyword "pesada" + score MED+
+
+**Manter inteira quando:**
+- LOW ou MED baixo
+- Mesmo módulo
+- Cabe em uma conversa (15–60 min)
+
+### Passo 3: Eixos de split
+
+| Eixo | Quando |
+|---|---|
+| **Por camada** | Modelo / Controller / Service / Test separados |
+| **Por endpoint** | 4 endpoints → 4 sub-tasks |
+| **Por feature** | Auth = register + login → split por verbo |
+| **Refactor + feature** | "1. refactor" + "2. feature em cima" |
+| **Migration + código** | "1. migration" + "2. código novo" |
+
+Cada sub-task:
+- `subtask_prompt` auto-suficiente (Anti-Stub Contract!)
+- Spec própria em `DARE/EXECUTION/<sub-id>.md`
+- `depends_on` mínimo mas correto
+- Complexity honesta — se sub ainda for HIGH, quebrar de novo
+
+### Passo 4: Verdito
+
+`.dare/refine-verdict-<task-id>.json`:
+
+```json
+{
+  "manageable": false,
+  "reasons": ["Score 18 (HIGH) — 7 endpoints + migration", "Mistura refactor com features novas"],
+  "proposedSubtasks": [
+    {
+      "id": "task-034a",
+      "title": "Refactor UserService",
+      "files": ["src/services/UserService.ts", "tests/services/UserService.test.ts"],
+      "rationale": "Refactor isolado antes da feature",
+      "estimatedLevel": "MED"
+    }
+  ]
+}
+```
+
+Manuseável:
+
+```json
+{
+  "manageable": true,
+  "reasons": ["Score 7 (MED), 4 arquivos mesmo módulo"]
+}
+```
+
+### Passo 5: Aplicar o split
+
+1. Editar `DARE/dare-dag.yaml` substituindo a task pelas sub-tasks
+2. Criar specs em `DARE/EXECUTION/<sub-id>.md` (template + Anti-Stub Contract)
+3. Atualizar `DARE/TASKS.md` (visão humana)
+4. Regenerar Mermaid: `dare dag viz -o DARE/dag-graph.mmd`
+5. Marcar task original como SPLIT (preservar histórico)
+
+### Passo 6: Mensagem
+
+Manuseável:
+> ✅ Task bem-dimensionada (score X, level Y). Sem split.
+
+Quebrada:
+> 🪓 Task quebrada em N sub-tasks: [lista]. Revise com `dare validate` e `dare dag viz`.
+
+## Regras inegociáveis
+
+- Não quebrar tasks LOW
+- Não inventar dependências falsas
+- Cada sub-task testável independentemente
+- Anti-Stub Contract aplica em cada sub-task

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

@@ -0,0 +1,108 @@
+---
+name: dare-reverse
+description: Camada semântica da engenharia reversa (Fase 0 / brownfield). Roda depois do comando `dare reverse` e preenche as inferências — propósito, domínio, responsabilidades e diagramas de fluxo — nos artefatos DARE/IDEIA.md e DARE/REVERSE/module-*.md.
+---
+
+# DARE Reverse Skill — Engenharia Reversa (Fase 0)
+
+Você é o agente da **Fase 0 (brownfield)** do método DARE no Antigravity. Esta skill é a
+**camada semântica** da engenharia reversa: roda **depois** do comando `dare reverse`, que já
+varreu o código e gerou os esqueletos determinísticos. Sua função é **preencher as inferências**
+que o CLI não faz: propósito, domínio, responsabilidades e os **diagramas de fluxo**
+("como a coisa funciona").
+
+> Pré-requisito: o comando `dare reverse` precisa ter rodado antes (gera `DARE/IDEIA.md`,
+> `DARE/REVERSE/module-*.md` e `DARE/REVERSE/reverse-facts.json`). Se não existirem, peça ao
+> usuário para rodar `dare reverse` primeiro.
+
+## Quando usar esta skill
+
+- O usuário quer entender / documentar um projeto **legado** antes de adotar o DARE.
+- Acabou de rodar `dare reverse` e os artefatos têm seções `<!-- AGENT: ... -->` em aberto.
+- O objetivo é gerar uma **pré-arquitetura** (`IDEIA.md`) que depois vira `DESIGN.md`.
+
+## Marcação de confiança (obrigatória)
+
+Ao preencher cada `<!-- AGENT -->`, marque **cada afirmação** com seu nível de confiança + evidência:
+
+- `- 🟢 <claim>. ` + `` `arquivo:linha` `` — **CONFIRMED**: evidência direta no código.
+- `- 🟡 <claim>. ` + `` `arquivo:linha` `` — **INFERRED**: padrão/dedução; pode estar errado.
+- `- 🔴 <claim>. → ver gaps.md` — **GAP**: não determinável pelo código.
+
+Regra: só 🟢 com evidência direta; na dúvida, 🟡; sem base, 🔴 (registre em `gaps.md`). Os fatos
+estruturais (caminho, LOC, deps) já vêm pré-marcados 🟢 pelo CLI — **não os altere**.
+
+## Passo a passo
+
+### 1. Carregar os fatos (não re-varrer tudo)
+
+- Leia `DARE/REVERSE/reverse-facts.json` — fonte de fatos determinística (stack, módulos, LOC,
+  grafo de dependências). **Confie nela** para o inventário; não reconte arquivos.
+- Por módulo, abra **2-5 arquivos representativos** (entrypoints, controllers, services, models)
+  — o suficiente para inferir responsabilidade e fluxo. Não leia o módulo inteiro.
+
+### 2. Preencher `DARE/IDEIA.md`
+
+Substitua cada bloco `<!-- AGENT: ... -->`:
+
+- **Propósito Inferido** — 2-4 frases: o que o software faz e por quê.
+- **Domínio & Conceitos** — entidades de negócio + glossário.
+- **Modelo de Dados (reconstruído)** — entidades, campos-chave, relacionamentos.
+- **Superfície de API** — endpoints inferidos de rotas/controllers.
+- **Fluxo do Sistema** — um `flowchart TD` Mermaid do caminho principal de request/dados
+  atravessando os módulos.
+- **⚠️ Incertezas / Gaps** — o que NÃO deu pra inferir + perguntas objetivas para o humano.
+
+**Não toque** no Mapa de Módulos nem na tabela (determinísticos, gerados pelo CLI).
+
+### 3. Preencher cada `DARE/REVERSE/module-*.md`
+
+- **Responsabilidade** — papel do módulo no sistema (1-3 frases).
+- **Superfície Pública** — o que expõe (funções/classes/endpoints/tipos exportados).
+- **Como Funciona (fluxo)** — um `sequenceDiagram` Mermaid do fluxo típico
+  (entrypoint → service → repository → DB/externo).
+- **Dependências & Acoplamento** — comente o acoplamento e riscos (circular, hotspot HIGH).
+
+### 4. Apresentar ao usuário
+
+Resumo: propósito inferido, nº de módulos, principais incertezas. Reforce que o `IDEIA.md` é um
+**rascunho a validar** antes de promover a DESIGN com `dare design`.
+
+## Passo final — Gaps, Questions e Reviewer
+
+1. **`gaps.md`** — consolide os 🔴 classificados por severidade (crítico/moderado/cosmético/fora-escopo) + tratamento.
+2. **`questions.md`** — perguntas objetivas ao humano.
+3. **Reviewer** — releia os arquivos-chave e rebaixe claims sem evidência (🟢→🟡 ou 🟡→🔴).
+4. **Rode `dare reverse --report`** — gera `confidence-report.md` + `traceability/code-spec-matrix.md` (índice determinístico).
+
+## Modo `--deep` (Fase 3)
+
+Se `dare reverse --deep` foi usado, complete os artefatos extras em `DARE/REVERSE/`:
+- **`erd.md`** — entidades extraídas pelo CLI (🟢); complete relações não-explícitas (🟡).
+- **`domain-rules.md`** — regras de negócio (validações, invariantes, cálculos), 🟢/🟡/🔴.
+- **`state-machines.md`** — `stateDiagram-v2` por entidade/fluxo (estados/transições reais).
+- **`permissions.md`** — papéis, recursos e regras de autorização.
+- **`c4/c4-context.md`** e **`c4/c4-container.md`** — atores/externos e containers (component = mapa de módulos).
+
+## Regras de ouro
+
+1. **Não invente** — fluxo não-claro vira 🔴 (gap), não chute.
+2. **Fidelidade ao código real** — descreva o que o código faz, não o que deveria fazer.
+3. **Diagramas enxutos** — legibilidade acima de exaustividade.
+4. **Não re-varra** — os fatos já estão em `reverse-facts.json`.
+5. **Preserve o determinístico** — nunca edite o Mapa de Módulos/tabela/grafo do CLI.
+
+## Antipatterns
+
+| AP | Antipattern | Por quê |
+|---|---|---|
+| AP-01 | Inventar endpoints/entidades inexistentes | Polui a pré-arquitetura com ficção |
+| AP-02 | Reescrever a tabela de módulos do CLI | Quebra a fonte determinística |
+| AP-03 | `sequenceDiagram` gigante e ilegível | Anula o propósito do diagrama |
+| AP-04 | Pular a seção de Incertezas | Remove o ponto de validação humana |
+| AP-05 | Ler o projeto inteiro arquivo a arquivo | Desperdiça contexto; os fatos já estão no JSON |
+| AP-06 | Marcar tudo 🟢 sem evidência `file:line` | Infla a confiança e engana o humano |
+
+---
+
+Skill MIT — parte do DARE Method. Fase 0 (brownfield). Pareia com o comando `dare reverse`.

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

@@ -1,111 +1,111 @@
----
-name: dare-review
-description: Audita uma task DARE implementada — cruza a spec com o código real para detectar stubs, mocks fora de testes, funções vazias, TODOs e validar critério-a-critério se a implementação satisfaz o que a spec prometeu. Use antes de marcar uma task como DONE, ou quando o dev pedir revisão manual. Combina análise estática (via CLI) com verdito semântico (você).
----
-
-# DARE Review Skill
-
-Você é o auditor de qualidade do método DARE. Seu papel é verificar se uma task implementada **realmente** entrega o que a spec promete — sem stubs, sem mocks em produção, sem funções vazias, sem TODOs pendentes.
-
-## Quando usar esta skill
-
-- Antes de marcar uma task como DONE (gate obrigatório no Definition of Done)
-- Quando `dare review <id>` estático passa mas precisa validação semântica
-- Quando o dev pede revisão manual: "revise a task-034"
-
-## Camada estática vs semântica
-
-O CLI `dare review <id>` já faz a camada **estática**: regex sobre os arquivos detecta TODO/FIXME/stubs/mocks/funções vazias. Esta skill faz a camada **semântica**: critério-a-critério da spec contra a implementação real.
-
-## Como executar
-
-### Passo 1: Rodar a camada estática
-
-```bash
-dare review <task-id> --format json > .dare/review-static-<task-id>.json
-```
-
-Leia o JSON. Se houver erros estáticos, reporte-os primeiro. Geralmente não vale prosseguir com semântica se a estática falhou.
-
-### Passo 2: Carregar contexto
-
-- `DARE/EXECUTION/<task-id>.md` — spec da task
-- Cada arquivo listado na seção 3 ("ARQUIVOS A CRIAR / MODIFICAR")
-- `DARE/BLUEPRINT.md` — contratos de API / modelos
-
-### Passo 3: Auditoria critério-a-critério
-
-Para **cada** item das seções abaixo, marque ✅ / ❌ com evidência (arquivo + linha):
-
-#### 3.1 Objetivo (seção 1 da spec)
-A implementação atinge o estado observável prometido? Encontre evidência concreta.
-
-#### 3.2 Arquivos (seção 3)
-- Todos existem com conteúdo descrito?
-- Arquivos extras suspeitos?
-
-#### 3.3 Implementação (seção 4)
-- Cada passo numerado foi executado?
-- Assinaturas exatas correspondem?
-- Validações têm regras concretas (não "valida email" — a regex específica)?
-
-#### 3.4 Testes (seção 4 — subitem testes)
-- Cada teste listado existe?
-- Tem assertions reais (não `assertTrue(true)`)?
-- Edge cases enumerados cobertos?
-
-#### 3.5 Segurança (seção 5)
-- Input validation conforme spec?
-- Não há secrets/tokens hardcoded?
-- SQL/Command injection mitigado?
-
-#### 3.6 Anti-Stub (seção 7)
-A camada estática já checou. Só anote se encontrar algo que regex não pegaria (ex.: dados hardcoded disfarçados).
-
-### Passo 4: Emitir verdito semântico
-
-Salve em `.dare/review-semantic-<task-id>.json`:
-
-```json
-{
-  "passed": true,
-  "unmetCriteria": [],
-  "notes": "Resumo de 1-3 frases"
-}
-```
-
-Falha:
-
-```json
-{
-  "passed": false,
-  "unmetCriteria": [
-    "Seção 4.3: validação de senha sem regex de força",
-    "Seção 4.4: teste de 'email duplicado' não existe"
-  ],
-  "notes": "2 critérios não atendidos em src/auth/register.ts"
-}
-```
-
-### Passo 5: Rodar o review fundido
-
-```bash
-dare review <task-id> --from-agent .dare/review-semantic-<task-id>.json
-```
-
-Exit code 0 = pode ir para DONE; 1 = não pode.
-
-### Passo 6: Mensagem final
-
-Se passou:
-> ✅ Task aprovada. Marque DONE: `dare execute --complete <task-id>`
-
-Se falhou:
-> ❌ Task não passou. Itens a corrigir: [lista]. Re-rode após corrigir.
-
-## Regras inegociáveis
-
-- **Não invente** que algo está implementado se não viu o código no disco
-- **Não aceite** mocks/stubs em código de produção mesmo que façam testes passar
-- **Mocks são OK** dentro de `*.test.*`, `*.spec.*`, `__tests__/`, `tests/`, `spec/`
-- **Evidência concreta:** sempre cite arquivo + linha para suas conclusões
+---
+name: dare-review
+description: Audita uma task DARE implementada — cruza a spec com o código real para detectar stubs, mocks fora de testes, funções vazias, TODOs e validar critério-a-critério se a implementação satisfaz o que a spec prometeu. Use antes de marcar uma task como DONE, ou quando o dev pedir revisão manual. Combina análise estática (via CLI) com verdito semântico (você).
+---
+
+# DARE Review Skill
+
+Você é o auditor de qualidade do método DARE. Seu papel é verificar se uma task implementada **realmente** entrega o que a spec promete — sem stubs, sem mocks em produção, sem funções vazias, sem TODOs pendentes.
+
+## Quando usar esta skill
+
+- Antes de marcar uma task como DONE (gate obrigatório no Definition of Done)
+- Quando `dare review <id>` estático passa mas precisa validação semântica
+- Quando o dev pede revisão manual: "revise a task-034"
+
+## Camada estática vs semântica
+
+O CLI `dare review <id>` já faz a camada **estática**: regex sobre os arquivos detecta TODO/FIXME/stubs/mocks/funções vazias. Esta skill faz a camada **semântica**: critério-a-critério da spec contra a implementação real.
+
+## Como executar
+
+### Passo 1: Rodar a camada estática
+
+```bash
+dare review <task-id> --format json > .dare/review-static-<task-id>.json
+```
+
+Leia o JSON. Se houver erros estáticos, reporte-os primeiro. Geralmente não vale prosseguir com semântica se a estática falhou.
+
+### Passo 2: Carregar contexto
+
+- `DARE/EXECUTION/<task-id>.md` — spec da task
+- Cada arquivo listado na seção 3 ("ARQUIVOS A CRIAR / MODIFICAR")
+- `DARE/BLUEPRINT.md` — contratos de API / modelos
+
+### Passo 3: Auditoria critério-a-critério
+
+Para **cada** item das seções abaixo, marque ✅ / ❌ com evidência (arquivo + linha):
+
+#### 3.1 Objetivo (seção 1 da spec)
+A implementação atinge o estado observável prometido? Encontre evidência concreta.
+
+#### 3.2 Arquivos (seção 3)
+- Todos existem com conteúdo descrito?
+- Arquivos extras suspeitos?
+
+#### 3.3 Implementação (seção 4)
+- Cada passo numerado foi executado?
+- Assinaturas exatas correspondem?
+- Validações têm regras concretas (não "valida email" — a regex específica)?
+
+#### 3.4 Testes (seção 4 — subitem testes)
+- Cada teste listado existe?
+- Tem assertions reais (não `assertTrue(true)`)?
+- Edge cases enumerados cobertos?
+
+#### 3.5 Segurança (seção 5)
+- Input validation conforme spec?
+- Não há secrets/tokens hardcoded?
+- SQL/Command injection mitigado?
+
+#### 3.6 Anti-Stub (seção 7)
+A camada estática já checou. Só anote se encontrar algo que regex não pegaria (ex.: dados hardcoded disfarçados).
+
+### Passo 4: Emitir verdito semântico
+
+Salve em `.dare/review-semantic-<task-id>.json`:
+
+```json
+{
+  "passed": true,
+  "unmetCriteria": [],
+  "notes": "Resumo de 1-3 frases"
+}
+```
+
+Falha:
+
+```json
+{
+  "passed": false,
+  "unmetCriteria": [
+    "Seção 4.3: validação de senha sem regex de força",
+    "Seção 4.4: teste de 'email duplicado' não existe"
+  ],
+  "notes": "2 critérios não atendidos em src/auth/register.ts"
+}
+```
+
+### Passo 5: Rodar o review fundido
+
+```bash
+dare review <task-id> --from-agent .dare/review-semantic-<task-id>.json
+```
+
+Exit code 0 = pode ir para DONE; 1 = não pode.
+
+### Passo 6: Mensagem final
+
+Se passou:
+> ✅ Task aprovada. Marque DONE: `dare execute --complete <task-id>`
+
+Se falhou:
+> ❌ Task não passou. Itens a corrigir: [lista]. Re-rode após corrigir.
+
+## Regras inegociáveis
+
+- **Não invente** que algo está implementado se não viu o código no disco
+- **Não aceite** mocks/stubs em código de produção mesmo que façam testes passar
+- **Mocks são OK** dentro de `*.test.*`, `*.spec.*`, `__tests__/`, `tests/`, `spec/`
+- **Evidência concreta:** sempre cite arquivo + linha para suas conclusões