@dewtech/dare-cli 3.2.0 → 3.4.0

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

@@ -1,108 +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`.
+---
+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