@dewtech/dare-cli 3.1.0 → 3.2.0

package/templates/ide/claude/.claude/commands/dare-init.md

@@ -0,0 +1,30 @@
+# /dare-init
+
+Cria um projeto DARE do zero (greenfield) com setup interativo: escolhe stack backend/frontend, knowledge graph, IDE e gera o scaffolder completo + DNA DARE.
+
+> Este comando expõe o CLI `dare init` na IDE. O agente pode **rodar o comando no terminal** e interpretar a saída.
+
+## Quando usar
+
+- O usuário quer começar um projeto **novo** do zero.
+- Não existe código ainda — é greenfield. Para projeto legado, use `/dare-discover`.
+
+## Como rodar
+
+```bash
+dare init                       # fluxo interativo completo
+dare init minha-api --stack node-nestjs
+dare init meu-mcp --mcp node-ts --transport http
+dare init api --stack go-gin --toolchain docker --non-interactive
+```
+
+## O que fazer
+
+1. Rode `dare init` (ou com `--stack`/`--mcp` se o usuário já decidiu a stack).
+2. Responda aos prompts: nome, stack backend, frontend opcional, knowledge graph (json/sqlite/neo4j), IDE(s).
+3. Ao final, o projeto tem scaffolder + os 7 artefatos de DNA + comandos/skills de IDE instalados.
+4. Próximo passo: descreva a ideia com `/dare-design`.
+
+## Comandos relacionados
+
+`/dare-design` · `/dare-discover` · `/dare-bootstrap`

package/templates/ide/claude/.claude/commands/dare-skill.md

@@ -0,0 +1,30 @@
+# /dare-skill
+
+Adiciona, remove, lista, inspeciona, atualiza ou publica skills DARE neste projeto.
+
+> Este comando expõe o CLI `dare skill` na IDE. O agente pode **rodar o comando no terminal** e interpretar a saída.
+
+## Quando usar
+
+- Você quer instalar uma skill extra (ex.: uma skill de stack) no projeto.
+- Quer listar/inspecionar as skills disponíveis ou publicar uma própria.
+
+## Como rodar
+
+```bash
+dare skill list
+dare skill info <nome>
+dare skill add <nome>
+dare skill remove <nome>
+dare skill update
+```
+
+## O que fazer
+
+1. Use `dare skill list` para ver o que está instalado/disponível.
+2. Rode o subcomando desejado (`add`/`remove`/`info`/`update`/`publish`).
+3. Confirme o resultado e, se mudou comandos de IDE, recarregue a IDE.
+
+## Comandos relacionados
+
+`/dare-update` · `/dare-info`

package/templates/ide/claude/.claude/commands/dare-update.md

@@ -0,0 +1,28 @@
+# /dare-update
+
+Sincroniza os artefatos do projeto (comandos de IDE, skills, templates) com a versão instalada do DARE CLI, preservando customizações.
+
+> Este comando expõe o CLI `dare update` na IDE. O agente pode **rodar o comando no terminal** e interpretar a saída.
+
+## Quando usar
+
+- Depois de atualizar o `@dewtech/dare-cli` para uma versão nova.
+- Quando `dare info` apontar artefatos desatualizados.
+
+## Como rodar
+
+```bash
+dare update --dry-run     # mostra o que mudaria, sem escrever
+dare update -y            # aplica tudo, mantém customizações
+dare update --target 3.2.0
+```
+
+## O que fazer
+
+1. Rode `dare update --dry-run` e revise o diff proposto.
+2. Se estiver ok, rode `dare update -y`.
+3. Evite `--force` salvo se o usuário aceitar sobrescrever arquivos customizados.
+
+## Comandos relacionados
+
+`/dare-info` · `/dare-welcome`

package/templates/ide/claude/.claude/commands/dare-validate.md

@@ -0,0 +1,28 @@
+# /dare-validate
+
+Valida `DARE/dare-dag.yaml` (ciclos, referências quebradas, campos obrigatórios). Adequado para pre-commit hooks e CI.
+
+> Este comando expõe o CLI `dare validate` na IDE. O agente pode **rodar o comando no terminal** e interpretar a saída.
+
+## Quando usar
+
+- Antes de commitar mudanças no DAG.
+- Em CI, como gate de integridade do plano de execução.
+
+## Como rodar
+
+```bash
+dare validate
+dare validate --strict          # trata warnings como erros (CI-friendly)
+dare validate --dag DARE/dare-dag.yaml
+```
+
+## O que fazer
+
+1. Rode `dare validate` (use `--strict` em CI).
+2. Se houver erros, corrija o `dare-dag.yaml` apontado e rode de novo até passar.
+3. Saída limpa = DAG íntegro e pronto para `/dare-execute`.
+
+## Comandos relacionados
+
+`/dare-dag` · `/dare-execute`

package/templates/ide/claude/.claude/commands/dare-welcome.md

@@ -0,0 +1,25 @@
+# /dare-welcome
+
+Mostra o banner do DARE e um guia de início rápido com o fluxo Design → Architecture → Review → Execute.
+
+> Este comando expõe o CLI `dare welcome` na IDE. O agente pode **rodar o comando no terminal** e interpretar a saída.
+
+## Quando usar
+
+- Primeiro contato com o DARE neste projeto.
+- O usuário quer relembrar o fluxo canônico de comandos.
+
+## Como rodar
+
+```bash
+dare welcome
+```
+
+## O que fazer
+
+1. Rode `dare welcome`.
+2. Apresente o fluxo: `/dare-design` → `/dare-blueprint` → `/dare-tasks` → `/dare-execute`.
+
+## Comandos relacionados
+
+`/dare-design` · `/dare-info`

package/templates/ide/cursor/.cursor/commands/{generate-blueprint.md → dare-blueprint.md}

@@ -1,4 +1,4 @@
-# Comando: /generate-blueprint
+# Comando: /dare-blueprint
 
 ## Descrição
 Avança o DARE para a fase Architect: lê `DARE/DESIGN.md` aprovado e gera **somente** `DARE/BLUEPRINT.md`.

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

@@ -0,0 +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`

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

@@ -1,4 +1,4 @@
-# Comando: /run-dag
+# Comando: /dare-dag-run
 
 ## Descrição
 

package/templates/ide/cursor/.cursor/commands/{dag-viz.md → dare-dag-viz.md}

@@ -1,4 +1,4 @@
-# Comando: /dag-viz
+# Comando: /dare-dag-viz
 
 ## Descrição
 

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

@@ -0,0 +1,27 @@
+# Comando: /dare-dag
+
+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/cursor/.cursor/commands/{generate-design.md → dare-design.md}

@@ -1,4 +1,4 @@
-# Comando: /generate-design
+# Comando: /dare-design
 
 ## Descrição
 Inicia o Método DARE (fase Design) gerando `DARE/DESIGN.md` a partir de uma ideia inicial.

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

@@ -0,0 +1,28 @@
+# Comando: /dare-discover
+
+Detecta a stack de um projeto já existente (brownfield) e instala os arquivos da metodologia DARE — incluindo os comandos/skills de IDE — sem tocar no código.
+
+> Este comando expõe o CLI `dare discover` na IDE. O agente pode **rodar o comando no terminal** e interpretar a saída.
+
+## Quando usar
+
+- O usuário quer adotar o DARE em um repositório que **já existe**.
+- Para entender/documentar o legado em profundidade depois, encadeie com `/dare-reverse` e `/dare-dna`.
+
+## Como rodar
+
+```bash
+dare discover
+dare discover --dir ./caminho/do/projeto
+dare discover --check    # só mostra a detecção, sem instalar nada
+```
+
+## O que fazer
+
+1. Rode `dare discover --check` primeiro para revisar a stack detectada.
+2. Se a detecção estiver correta, rode `dare discover` para instalar os artefatos DARE + comandos de IDE.
+3. Próximo passo: `/dare-reverse` (Fase 0 — coleta) e `/dare-dna` (convenções).
+
+## Comandos relacionados
+
+`/dare-reverse` · `/dare-dna` · `/dare-migrate`

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

@@ -0,0 +1,75 @@
+# Comando: /dare-dna
+
+Camada semântica da extração de DNA do projeto. Roda **depois** do comando `dare dna`, que já varreu
+o código e extraiu os fatos de convenção. Sua função é **transformar fatos em regras acionáveis** —
+o "como esse codebase faz as coisas" que uma nova feature deve respeitar.
+
+## Como usar
+
+```
+/dare-dna                 # preenche o PROJECT-DNA.md gerado por `dare dna`
+```
+
+> Pré-requisito: rodar `dare dna` antes (gera `DARE/PROJECT-DNA.md` e `DARE/dna-facts.json`).
+> Se não existirem, instrua o usuário a rodar `dare dna` primeiro.
+
+## Quando usar
+
+- Projeto **legado** que vai adotar o DARE para novas features, sem reescrever o existente.
+- Acabou de rodar `dare dna` e o `PROJECT-DNA.md` tem seções `<!-- AGENT -->` em aberto.
+- O objetivo é um **ruleset** que faça o agente seguir o padrão da casa, não o default genérico.
+
+## O que fazer
+
+### 1. Carregar os fatos (não re-varrer tudo)
+
+- Leia `DARE/dna-facts.json` — fonte determinística (tooling, naming, camadas, testes, libs, commits).
+- Abra **2-5 arquivos representativos por camada** (um controller, um service, um model, um teste) para
+  inferir os padrões que o CLI não detecta (tratamento de erro, validação, estilo de teste).
+
+### 2. Preencher `DARE/PROJECT-DNA.md`
+
+Substitua cada bloco `<!-- AGENT: ... -->`:
+
+- **Convenções de Nomenclatura** — confirme o estilo detectado e documente exceções (ex.: componentes
+  em PascalCase, utilitários em kebab).
+- **Arquitetura & Camadas** — nomeie o padrão com confiança (MVC / Layered / Hexagonal) e escreva as
+  **regras de onde cada coisa mora** (ex.: "controllers só orquestram; regra de negócio vai em services;
+  acesso a dados só em repositories").
+- **Padrões de Teste** — onde os testes ficam, naming, assertions reais (não `expect(true)`), uso de
+  mocks/fixtures.
+- **Tratamento de Erros & Validação** — como o projeto trata erros (exceptions, Result/Either, try/catch)
+  e valida inputs. Dê **exemplos concretos** do código real.
+- **Regras de Ouro do Projeto** — liste o que **SEMPRE** e o que **NUNCA** fazer neste codebase.
+- **⚠️ Incertezas / Inconsistências** — convenções ambíguas/misturadas que o humano precisa decidir.
+
+**Não toque** nos fatos determinísticos já preenchidos pelo CLI (tooling, tabela de naming, libs).
+
+### 3. Apresentar ao usuário
+
+Resumo: arquitetura nomeada, principais regras de ouro, inconsistências encontradas. Reforce que o
+`PROJECT-DNA.md` vira referência para `/dare-feature-design` e `/dare-execute` respeitarem o legado.
+
+## Regras de ouro
+
+1. **Descritivo, não aspiracional** — documente como o código É, não como deveria ser.
+2. **Exemplos reais** — cite arquivos/trechos do próprio projeto nas regras.
+3. **Sinalize inconsistência** — se o legado mistura padrões, diga isso em "⚠️ Incertezas", não invente um padrão único.
+4. **Não re-varra** — os fatos já estão em `dna-facts.json`.
+5. **Preserve o determinístico** — não reescreva tooling/naming/libs gerados pelo CLI.
+
+## Antipatterns
+
+| AP | Antipattern | Por quê |
+|---|---|---|
+| AP-01 | Documentar o padrão "ideal" em vez do real | O agente vai gerar código fora do estilo do legado |
+| AP-02 | Forçar um padrão único onde o legado é inconsistente | Esconde a realidade; melhor sinalizar a incerteza |
+| AP-03 | Reescrever os fatos determinísticos do CLI | Quebra a fonte de verdade |
+| AP-04 | Regras vagas ("siga boas práticas") | Inúteis — o valor está na regra específica do projeto |
+| AP-05 | Ignorar os testes existentes ao descrever o estilo de teste | Nova feature nasce inconsistente |
+
+$ARGUMENTS
+
+---
+
+Skill MIT — parte do DARE Method. DNA do projeto (brownfield). Pareia com o comando `dare dna`.

package/templates/ide/cursor/.cursor/commands/{generate-docker-compose.md → dare-docker-compose.md}

@@ -1,4 +1,4 @@
-# Comando: /generate-docker-compose
+# Comando: /dare-docker-compose
 
 ## Descrição
 Este comando analisa a arquitetura definida no BLUEPRINT.md e gera um `docker-compose.yml` completo com todos os serviços necessários (App, DB, Cache, etc).

package/templates/ide/cursor/.cursor/commands/{generate-dockerfile.md → dare-dockerfile.md}

@@ -1,4 +1,4 @@
-# Comando: /generate-dockerfile
+# Comando: /dare-dockerfile
 
 ## Descrição
 Este comando analisa a stack do projeto (definida no DESIGN.md ou .cursorrules) e gera um `Dockerfile` otimizado para produção e desenvolvimento.

package/templates/ide/cursor/.cursor/commands/{execute-task.md → dare-execute.md}

@@ -1,4 +1,4 @@
-# Comando: /execute-task
+# Comando: /dare-execute
 
 ## Descrição
 Este comando finaliza o Método DARE (Execute) implementando o código e validando os testes de uma tarefa específica isolada.

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

@@ -0,0 +1,30 @@
+# Comando: /dare-graph
+
+Consulta e visualiza o grafo de conhecimento do projeto (tasks, arquivos, schemas, endpoints, componentes, entidades e suas relações).
+
+> Este comando expõe o CLI `dare graph` na IDE. O agente pode **rodar o comando no terminal** e interpretar a saída.
+
+## Quando usar
+
+- Você quer entender dependências entre tasks/arquivos/entidades.
+- Precisa achar nós relacionados a um termo, ou exportar um diagrama do grafo.
+
+## Como rodar
+
+```bash
+dare graph stats                       # contagem de nós/arestas por tipo
+dare graph query <termo> --limit 10    # busca nós por label/descrição
+dare graph query auth --type endpoint
+dare graph viz --format mermaid -o graph.mmd
+dare graph ingest                      # re-sincroniza o grafo do dare-dag.yaml
+```
+
+## O que fazer
+
+1. Escolha o subcomando conforme a intenção: `stats`, `query <termo>`, `viz`, `ingest`.
+2. Rode o comando e interprete a saída (para `viz`, abra/renderize o diagrama gerado).
+3. Se o grafo parecer desatualizado, rode `dare graph ingest` para re-sincronizar.
+
+## Comandos relacionados
+
+`/dare-dag` · `/dare-execute`

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

@@ -0,0 +1,26 @@
+# Comando: /dare-info
+
+Mostra versão do CLI, caminhos relevantes e a integridade da instalação DARE no projeto atual.
+
+> Este comando expõe o CLI `dare info` na IDE. O agente pode **rodar o comando no terminal** e interpretar a saída.
+
+## Quando usar
+
+- Algo parece errado no setup e você quer um diagnóstico rápido.
+- Para confirmar a versão do CLI e os artefatos DARE presentes.
+
+## Como rodar
+
+```bash
+dare info
+```
+
+## O que fazer
+
+1. Rode `dare info`.
+2. Revise versão, caminhos e a checagem de integridade.
+3. Se houver artefatos faltando/desatualizados, rode `/dare-update`.
+
+## Comandos relacionados
+
+`/dare-update` · `/dare-welcome`

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

@@ -0,0 +1,30 @@
+# Comando: /dare-init
+
+Cria um projeto DARE do zero (greenfield) com setup interativo: escolhe stack backend/frontend, knowledge graph, IDE e gera o scaffolder completo + DNA DARE.
+
+> Este comando expõe o CLI `dare init` na IDE. O agente pode **rodar o comando no terminal** e interpretar a saída.
+
+## Quando usar
+
+- O usuário quer começar um projeto **novo** do zero.
+- Não existe código ainda — é greenfield. Para projeto legado, use `/dare-discover`.
+
+## Como rodar
+
+```bash
+dare init                       # fluxo interativo completo
+dare init minha-api --stack node-nestjs
+dare init meu-mcp --mcp node-ts --transport http
+dare init api --stack go-gin --toolchain docker --non-interactive
+```
+
+## O que fazer
+
+1. Rode `dare init` (ou com `--stack`/`--mcp` se o usuário já decidiu a stack).
+2. Responda aos prompts: nome, stack backend, frontend opcional, knowledge graph (json/sqlite/neo4j), IDE(s).
+3. Ao final, o projeto tem scaffolder + os 7 artefatos de DNA + comandos/skills de IDE instalados.
+4. Próximo passo: descreva a ideia com `/dare-design`.
+
+## Comandos relacionados
+
+`/dare-design` · `/dare-discover` · `/dare-bootstrap`

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

@@ -0,0 +1,72 @@
+# Comando: /dare-migrate
+
+Camada semântica da migração (Fase 2 brownfield). Roda **depois** de `dare migrate`, que já leu os
+artefatos do `reverse`/`dna` e gerou os esqueletos. Sua função é **escrever a estratégia de migração
+e os cenários Gherkin de paridade reais** — o contrato comportamental que garante uma reimplementação
+fiel ao legado.
+
+## Como usar
+
+```
+/dare-migrate
+```
+
+> Pré-requisito: rodar `dare migrate --to <stack>` antes (gera `DARE/MIGRATION/MIGRATION.md`,
+> `migration-facts.json` e `parity/*.feature`). Isso por sua vez exige `dare reverse` já executado.
+
+## Quando usar
+
+- Projeto legado entendido (`reverse` + `dna` feitos) que será **reimplementado** em outra stack.
+- Acabou de rodar `dare migrate` e o `MIGRATION.md`/`.feature` têm seções `<!-- AGENT -->`/`# AGENT`.
+
+## O que fazer
+
+### 1. Carregar contexto (não re-varrer)
+- Leia `DARE/MIGRATION/migration-facts.json` (origem, alvo, módulos, blocking gaps).
+- Leia `DARE/IDEIA.md` + `DARE/REVERSE/module-*.md` (o que cada módulo faz) e `DARE/PROJECT-DNA.md`
+  (convenções). Abra arquivos-chave do legado só o necessário para inferir comportamento.
+
+### 2. Preencher `DARE/MIGRATION/MIGRATION.md`
+- **Decisão de Paradigma** — origem e alvo mudam de paradigma (procedural→OO, monólito→serviços)?
+  Registre decisão + justificativa; se preservado, diga.
+- **Estratégia de Migração** — big-bang vs. **strangler/parallel-run**; ordem dos módulos; feature flags.
+- **Registro de Risco** — para cada **blocking gap** (🔴) pré-listado, escreva o tratamento; some os
+  riscos de regressão/dados/performance + mitigações.
+- **Arquitetura-alvo** — desenhe na stack-alvo, **alinhada ao DNA** (camadas/convenções) quando o
+  paradigma for preservado; senão justifique a nova organização.
+- **Plano de Cutover & Rollback** — passos de corte, validação de paridade (rodar os `.feature`),
+  critério de go/no-go e rollback.
+
+### 3. Escrever os Gherkin de paridade (`parity/<módulo>.feature`)
+- Um `Scenario` por **fluxo observável** do módulo, derivado do **comportamento legado real**
+  (não invente). `Given` estado inicial → `When` ação → `Then` resultado **idêntico ao legado**.
+- Inclua casos de borda e formatação que o legado garante (ex.: arredondamento monetário, máscaras).
+- Esses `.feature` são o **contrato de aceite** da reimplementação na stack-alvo.
+
+### 4. Apresentar ao usuário
+Resumo: decisão de paradigma, estratégia, nº de cenários de paridade, blocking gaps a resolver.
+Reforce que cenários de paridade só valem se vierem do comportamento legado observado.
+
+## Regras de ouro
+
+1. **Paridade primeiro** — o objetivo é não quebrar comportamento; todo fluxo crítico vira `Scenario`.
+2. **Blocking gaps são bloqueantes** — um 🔴 não resolvido é risco de reimplementação; trate ou registre.
+3. **Respeite o DNA** — a arquitetura-alvo segue as convenções da casa quando faz sentido.
+4. **Não invente comportamento** — cenário sem base no legado é fonte de regressão silenciosa.
+5. **Strangler quando possível** — migração incremental com parallel-run reduz risco vs. big-bang.
+
+## Antipatterns
+
+| AP | Antipattern | Por quê |
+|---|---|---|
+| AP-01 | Gherkin genérico sem base no legado | Não garante paridade — vira regressão |
+| AP-02 | Ignorar blocking gaps (🔴) | Reimplementa em cima de incerteza |
+| AP-03 | Big-bang sem necessidade | Maximiza risco e dificulta rollback |
+| AP-04 | Arquitetura-alvo desalinhada do DNA | Código novo vira ilha inconsistente |
+| AP-05 | Reescrever os fatos determinísticos do CLI | Quebra a fonte de verdade |
+
+$ARGUMENTS
+
+---
+
+Skill MIT — parte do DARE Method. Fase 2 (brownfield). Pareia com o comando `dare migrate`.

package/templates/ide/cursor/.cursor/commands/{refine-task.md → dare-refine.md}

@@ -1,4 +1,4 @@
-# Comando: /refine-task
+# Comando: /dare-refine
 
 ## Descrição
 

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

@@ -0,0 +1,139 @@
+# Comando: /dare-reverse
+
+Camada semântica da engenharia reversa (Fase 0 / brownfield). Roda **depois** do comando
+`dare reverse`, que já varreu o código e gerou os esqueletos. Sua função é **preencher as
+inferências** que o CLI determinístico não faz: propósito, domínio, responsabilidades e os
+**diagramas de fluxo** ("como a coisa funciona").
+
+## Como usar
+
+```
+/dare-reverse                 # preenche os artefatos gerados por `dare reverse`
+```
+
+> Pré-requisito: rodar `dare reverse` antes (gera `DARE/IDEIA.md`, `DARE/REVERSE/module-*.md`
+> e `DARE/REVERSE/reverse-facts.json`). Se não existirem, instrua o usuário a rodar `dare reverse` primeiro.
+
+## Quando usar
+
+- 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, 🔴 (e registre em `gaps.md`). Os fatos
+estruturais (caminho, LOC, deps) já vêm pré-marcados 🟢 pelo CLI — **não os altere**.
+
+## O que fazer
+
+### 1. Carregar os fatos (não re-varrer tudo)
+
+- Leia `DARE/REVERSE/reverse-facts.json` — é a fonte de fatos determinística (stack, módulos,
+  LOC, grafo de dependências). **Confie nela** para o inventário; não reconte arquivos.
+- Para cada 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: ... -->` por conteúdo real:
+
+- **Propósito Inferido** — 2-4 frases: o que o software faz e por quê.
+- **Domínio & Conceitos** — entidades de negócio + glossário (inferidos de models/migrations/nomes).
+- **Modelo de Dados (reconstruído)** — entidades, campos-chave, relacionamentos (de migrations/ORM).
+- **Superfície de API** — endpoints inferidos de rotas/controllers (método, rota, propósito).
+- **Fluxo do Sistema** — um `flowchart TD` Mermaid do caminho principal de request/dados
+  atravessando os módulos. Ex.:
+  ```mermaid
+  flowchart TD
+    Client[Cliente] --> API[API/Rotas]
+    API --> Auth[auth: valida token]
+    Auth --> Domain[users: regra de negócio]
+    Domain --> DB[(Persistência)]
+  ```
+- **⚠️ Incertezas / Gaps** — seja honesto: o que NÃO deu pra inferir com segurança, e perguntas
+  objetivas para o humano confirmar. Esta seção é o que protege o checkpoint human-in-the-loop.
+
+**Não toque** no Mapa de Módulos nem na tabela (são determinísticos, gerados pelo CLI).
+
+### 3. Preencher cada `DARE/REVERSE/module-*.md`
+
+Para cada módulo, substitua os `<!-- AGENT -->`:
+
+- **Responsabilidade** — 1-3 frases sobre o papel do módulo no sistema.
+- **Superfície Pública** — o que ele expõe (funções/classes/endpoints/tipos exportados).
+- **Como Funciona (fluxo)** — um `sequenceDiagram` Mermaid do fluxo de execução típico. Ex.:
+  ```mermaid
+  sequenceDiagram
+    participant C as Caller
+    participant S as Service
+    participant R as Repository
+    participant DB as Database
+    C->>S: chamada(args)
+    S->>R: busca/persiste
+    R->>DB: query
+    DB-->>R: linhas
+    R-->>S: entidade
+    S-->>C: resultado
+  ```
+- **Dependências & Acoplamento** — comente as dependências listadas em "Depende de" e riscos
+  de acoplamento (ex.: dependência circular, módulo-hotspot HIGH com muitos dependentes).
+
+### 4. Apresentar ao usuário
+
+Mostre um resumo: propósito inferido, nº de módulos, principais incertezas. Reforce que o
+`IDEIA.md` é um **rascunho a ser validado** — peça para o humano revisar antes de promover a DESIGN.
+
+## Passo final — Gaps, Questions e Reviewer
+
+1. **`gaps.md`** — consolide todos os 🔴 em `DARE/REVERSE/gaps.md`, classificados por severidade
+   (crítico / moderado / cosmético / fora-escopo) e com o tratamento sugerido.
+2. **`questions.md`** — perguntas objetivas ao humano em `DARE/REVERSE/questions.md`.
+3. **Reviewer (releia e reclassifique)** — reabra os arquivos-chave e revise os claims; rebaixe os
+   que não têm evidência suficiente (🟢→🟡 ou 🟡→🔴). Um spec honesto sobre suas incertezas vale mais
+   que um spec fluente que apresenta suposição como fato.
+4. **Rode `dare reverse --report`** — o CLI conta os marcadores e gera `confidence-report.md` +
+   `traceability/code-spec-matrix.md` com o índice determinístico. Mostre o índice ao usuário.
+
+## Modo `--deep` (Fase 3)
+
+Se `dare reverse --deep` foi usado, há artefatos extras em `DARE/REVERSE/` a completar:
+
+- **`erd.md`** — o CLI extraiu entidades de migrations/Prisma/ORM (🟢, com evidência). Complete
+  relações/entidades **não-explícitas** no schema (🟡) e corrija o que estiver errado.
+- **`domain-rules.md`** — regras de negócio (validações, invariantes, cálculos, políticas), 🟢/🟡/🔴.
+- **`state-machines.md`** — um `stateDiagram-v2` por entidade/fluxo com estados e transições reais.
+- **`permissions.md`** — papéis, recursos e regras de autorização (quem pode o quê).
+- **`c4/c4-context.md`** e **`c4/c4-container.md`** — atores/sistemas externos e containers de deploy.
+  (O nível *component* já é o mapa de módulos em `c4/c4-component.md`, gerado pelo CLI.)
+
+## Regras de ouro
+
+1. **Não invente.** Se um fluxo não está claro no código, marque 🔴 (gap) em vez de chutar.
+2. **Fidelidade ao código real** — descreva o que o código faz, não o que deveria fazer.
+3. **Diagramas enxutos** — um fluxo legível vale mais que um diagrama exaustivo e ilegível.
+4. **Não re-varra** — os fatos já estão em `reverse-facts.json`; foque na inferência semântica.
+5. **Preserve o determinístico** — nunca edite o Mapa de Módulos/tabela/grafo gerados pelo CLI.
+
+## Antipatterns
+
+| AP | Antipattern | Por quê |
+|---|---|---|
+| AP-01 | Inventar endpoints/entidades não presentes no código | 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 — o valor está em separar 🟢/🟡/🔴 |
+
+$ARGUMENTS
+
+---
+
+Skill MIT — parte do DARE Method. Fase 0 (brownfield). Pareia com o comando `dare reverse`.