@dewtech/dare-cli 3.2.0 → 3.4.0

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

@@ -1,139 +1,139 @@
-# Comando: /dare-dag-viz
-
-## Descrição
-
-Gera diagrama interativo `.excalidraw` a partir do `DARE/dare-dag.yaml` atual. Cada task vira um retângulo com cor baseada em complexidade e status visual, agrupado em colunas verticais (swim lanes) por rank, com setas conectando dependências.
-
-## Instruções para o Cursor Composer
-
-1. **Leia o DAG:** Abra `DARE/dare-dag.yaml`. Valide sintaxe YAML. Extraia tasks, complexidade, dependências e status.
-
-2. **Leia a skill de visualização:** Consulte `.cursor/rules/skill-dag-viz.mdc` (se existir) para convenções visuais e tokens de design.
-
-3. **Calcule ranks:**
-   - Tasks sem `depends_on` → rank 1
-   - Demais: rank = 1 + max(rank das dependências)
-   - Agrupe por rank para formar swim lanes verticais
-
-4. **Gere elementos Excalidraw:**
-   - Para cada task, crie retângulo 120×60px:
-     - Cor de fundo por `complexity`:
-       - LOW → azul `#e3f2fd`, stroke `#1976d2`
-       - MEDIUM → laranja `#fff3e0`, stroke `#f57c00`
-       - HIGH → rosa `#fce4ec`, stroke `#c2185b`
-     - Stroke por `status`:
-       - PENDING → linha sólida cinza padrão
-       - RUNNING → linha pontilhada azul
-       - DONE → linha sólida verde `#388e3c`
-       - FAILED → linha sólida vermelha `#d32f2f`
-     - Texto: `task-id\ntask-name\n[COMPLEXITY]`
-   - Para cada dependência em `depends_on`, crie seta de source → target, stroke cinza `#999`.
-
-5. **Posicione elementos:**
-   - X = 20 + (taskIndex_no_rank × 140)
-   - Y = 20 + (rank − 1) × 160
-
-6. **Salve:** Escreva resultado em `DARE/dag-graph.excalidraw` no formato JSON Excalidraw 2.x.
-
-7. **Mensagem final:**
-   ```
-   DAG gerado: DARE/dag-graph.excalidraw
-   Abra em https://excalidraw.com (File → Open) para visualizar e editar.
-   ```
-
-## Estrutura JSON Excalidraw esperada
-
-```json
-{
-  "type": "excalidraw",
-  "version": 2,
-  "source": "dare-dag-viz",
-  "elements": [
-    {
-      "id": "task-001",
-      "type": "rectangle",
-      "x": 20, "y": 20,
-      "width": 120, "height": 60,
-      "backgroundColor": "#e3f2fd",
-      "strokeColor": "#1976d2",
-      "strokeStyle": "solid",
-      "fillStyle": "solid",
-      "roundness": { "type": 2, "value": 6 }
-    },
-    {
-      "type": "text",
-      "x": 25, "y": 25,
-      "text": "task-001\nSetup Auth\n[LOW]",
-      "fontSize": 12,
-      "containerId": "task-001"
-    },
-    {
-      "type": "arrow",
-      "startBinding": { "elementId": "task-001" },
-      "endBinding": { "elementId": "task-003" },
-      "strokeColor": "#999"
-    }
-  ],
-  "appState": {
-    "gridMode": "grid",
-    "gridSize": 20
-  },
-  "files": {}
-}
-```
-
-## Campos esperados em `dare-dag.yaml`
-
-```yaml
-tasks:
-  task-001:
-    name: "Setup Auth"
-    complexity: "LOW"          # LOW | MEDIUM | HIGH
-    rank: 1                    # opcional (calculado se ausente)
-    depends_on: []             # default []
-    status: "DONE"             # PENDING | RUNNING | DONE | FAILED (default PENDING)
-    subtask_prompt: "..."      # opcional
-```
-
-**Obrigatórios:** `name`, `complexity`.
-**Opcionais:** `rank`, `depends_on`, `status`.
-
-## Como abrir o resultado
-
-1. Acesse https://excalidraw.com
-2. File → Open → selecione `DARE/dag-graph.excalidraw`
-3. Edite livremente (mover, colorir, anotar)
-4. Salve no mesmo arquivo
-
-## Atualizar após mudanças
-
-Sempre que `dare-dag.yaml` for modificado, rode `/dag-viz` para regenerar.
-
-> Dica: faça backup se editou manualmente — a regeneração sobrescreve.
-
-## Troubleshooting
-
-- **"File not found: DARE/dare-dag.yaml"** — projeto não tem DAG. Rode `/generate-tasks` primeiro para gerá-lo.
-- **"JSON inválido"** — valide com `dare dag validate` (se CLI disponível) ou inspecione manualmente.
-- **Diagrama muito grande** — abra em Excalidraw e ajuste com Ctrl+Mouse / pinch zoom.
-
-## Convenções visuais
-
-- **Azul** (`#e3f2fd`) = LOW complexity
-- **Laranja** (`#fff3e0`) = MEDIUM
-- **Rosa** (`#fce4ec`) = HIGH
-- **Verde** (`#388e3c`) = DONE
-- **Vermelho** (`#d32f2f`) = FAILED
-- **Pontilhado azul** = RUNNING
-- **Cinza padrão** = PENDING
-
-## Próximos passos
-
-- Exporte para PNG no Excalidraw para incluir em README ou PR
-- Compartilhe o link colaborativo do Excalidraw com stakeholders
-- Atualize após cada `/generate-tasks` ou `/run-dag`
-
----
-
-Skill MIT — parte do DARE Method.
-Inspiração: [Excalidraw Diagram Skill](https://github.com/coleam00/excalidraw-diagram-skill) por Cole Medin.
+# Comando: /dare-dag-viz
+
+## Descrição
+
+Gera diagrama interativo `.excalidraw` a partir do `DARE/dare-dag.yaml` atual. Cada task vira um retângulo com cor baseada em complexidade e status visual, agrupado em colunas verticais (swim lanes) por rank, com setas conectando dependências.
+
+## Instruções para o Cursor Composer
+
+1. **Leia o DAG:** Abra `DARE/dare-dag.yaml`. Valide sintaxe YAML. Extraia tasks, complexidade, dependências e status.
+
+2. **Leia a skill de visualização:** Consulte `.cursor/rules/skill-dag-viz.mdc` (se existir) para convenções visuais e tokens de design.
+
+3. **Calcule ranks:**
+   - Tasks sem `depends_on` → rank 1
+   - Demais: rank = 1 + max(rank das dependências)
+   - Agrupe por rank para formar swim lanes verticais
+
+4. **Gere elementos Excalidraw:**
+   - Para cada task, crie retângulo 120×60px:
+     - Cor de fundo por `complexity`:
+       - LOW → azul `#e3f2fd`, stroke `#1976d2`
+       - MEDIUM → laranja `#fff3e0`, stroke `#f57c00`
+       - HIGH → rosa `#fce4ec`, stroke `#c2185b`
+     - Stroke por `status`:
+       - PENDING → linha sólida cinza padrão
+       - RUNNING → linha pontilhada azul
+       - DONE → linha sólida verde `#388e3c`
+       - FAILED → linha sólida vermelha `#d32f2f`
+     - Texto: `task-id\ntask-name\n[COMPLEXITY]`
+   - Para cada dependência em `depends_on`, crie seta de source → target, stroke cinza `#999`.
+
+5. **Posicione elementos:**
+   - X = 20 + (taskIndex_no_rank × 140)
+   - Y = 20 + (rank − 1) × 160
+
+6. **Salve:** Escreva resultado em `DARE/dag-graph.excalidraw` no formato JSON Excalidraw 2.x.
+
+7. **Mensagem final:**
+   ```
+   DAG gerado: DARE/dag-graph.excalidraw
+   Abra em https://excalidraw.com (File → Open) para visualizar e editar.
+   ```
+
+## Estrutura JSON Excalidraw esperada
+
+```json
+{
+  "type": "excalidraw",
+  "version": 2,
+  "source": "dare-dag-viz",
+  "elements": [
+    {
+      "id": "task-001",
+      "type": "rectangle",
+      "x": 20, "y": 20,
+      "width": 120, "height": 60,
+      "backgroundColor": "#e3f2fd",
+      "strokeColor": "#1976d2",
+      "strokeStyle": "solid",
+      "fillStyle": "solid",
+      "roundness": { "type": 2, "value": 6 }
+    },
+    {
+      "type": "text",
+      "x": 25, "y": 25,
+      "text": "task-001\nSetup Auth\n[LOW]",
+      "fontSize": 12,
+      "containerId": "task-001"
+    },
+    {
+      "type": "arrow",
+      "startBinding": { "elementId": "task-001" },
+      "endBinding": { "elementId": "task-003" },
+      "strokeColor": "#999"
+    }
+  ],
+  "appState": {
+    "gridMode": "grid",
+    "gridSize": 20
+  },
+  "files": {}
+}
+```
+
+## Campos esperados em `dare-dag.yaml`
+
+```yaml
+tasks:
+  task-001:
+    name: "Setup Auth"
+    complexity: "LOW"          # LOW | MEDIUM | HIGH
+    rank: 1                    # opcional (calculado se ausente)
+    depends_on: []             # default []
+    status: "DONE"             # PENDING | RUNNING | DONE | FAILED (default PENDING)
+    subtask_prompt: "..."      # opcional
+```
+
+**Obrigatórios:** `name`, `complexity`.
+**Opcionais:** `rank`, `depends_on`, `status`.
+
+## Como abrir o resultado
+
+1. Acesse https://excalidraw.com
+2. File → Open → selecione `DARE/dag-graph.excalidraw`
+3. Edite livremente (mover, colorir, anotar)
+4. Salve no mesmo arquivo
+
+## Atualizar após mudanças
+
+Sempre que `dare-dag.yaml` for modificado, rode `/dag-viz` para regenerar.
+
+> Dica: faça backup se editou manualmente — a regeneração sobrescreve.
+
+## Troubleshooting
+
+- **"File not found: DARE/dare-dag.yaml"** — projeto não tem DAG. Rode `/generate-tasks` primeiro para gerá-lo.
+- **"JSON inválido"** — valide com `dare dag validate` (se CLI disponível) ou inspecione manualmente.
+- **Diagrama muito grande** — abra em Excalidraw e ajuste com Ctrl+Mouse / pinch zoom.
+
+## Convenções visuais
+
+- **Azul** (`#e3f2fd`) = LOW complexity
+- **Laranja** (`#fff3e0`) = MEDIUM
+- **Rosa** (`#fce4ec`) = HIGH
+- **Verde** (`#388e3c`) = DONE
+- **Vermelho** (`#d32f2f`) = FAILED
+- **Pontilhado azul** = RUNNING
+- **Cinza padrão** = PENDING
+
+## Próximos passos
+
+- Exporte para PNG no Excalidraw para incluir em README ou PR
+- Compartilhe o link colaborativo do Excalidraw com stakeholders
+- Atualize após cada `/generate-tasks` ou `/run-dag`
+
+---
+
+Skill MIT — parte do DARE Method.
+Inspiração: [Excalidraw Diagram Skill](https://github.com/coleam00/excalidraw-diagram-skill) por Cole Medin.

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

@@ -1,27 +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`
+# 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/dare-design.md

@@ -1,35 +1,35 @@
-# Comando: /dare-design
-
-## Descrição
-Inicia o Método DARE (fase Design) gerando `DARE/DESIGN.md` a partir de uma ideia inicial.
-
-## Instruções para o Cursor Composer
-
-1. **Leia o contexto:** `package.json` / `Cargo.toml` / `composer.json` / `go.mod` / `requirements.txt` para identificar a stack atual. Leia `.cursorrules` para entender padrões do projeto. Se `DARE/DESIGN.md` já existir, não sobrescreva sem aprovação explícita.
-
-2. **Leia o template:** `templates/DESIGN-template.md` — siga a estrutura fielmente.
-
-3. **Gere `DARE/DESIGN.md` com as seções obrigatórias:**
-
-   - **Descrição** — 3 a 5 frases: o que é, qual problema resolve, quem usa
-   - **Objetivos e Métricas de Sucesso** — tabela numerada (O-01, O-02…) com métrica verificável e meta numérica
-   - **Stakeholders** — tabela: papel, time, interesse principal
-   - **Requisitos Funcionais** — tabela numerada (RF-01, RF-02…) com prioridade MUST/SHOULD/COULD e critério de aceite
-   - **Requisitos Não-Funcionais** — tabela numerada (RNF-01…): performance, disponibilidade, segurança, observabilidade, manutenibilidade
-   - **Requisitos de Segurança** — tabela numerada (RS-01…). **Sempre inclua:**
-     - RS-01: validação de entrada no servidor (OWASP A03)
-     - RS-02: hash de senhas / proteção de dados sensíveis (OWASP A02)
-     - RS-03: controle de acesso por recurso (OWASP A01)
-     - RS-04: auditoria de dependências sem CVE HIGH/CRITICAL (OWASP A06)
-     - RS-05: secrets via variáveis de ambiente — nunca em código
-     - Requisitos específicos do domínio do projeto
-   - **Stack Técnica** — tabela por camada com versões fixas
-   - **Integrações Externas** — tabela: sistema, tipo, protocolo, direção, dados, responsável
-   - **Restrições** — prazo, orçamento, técnicas, compliance
-   - **Fora do Escopo (v1)** — lista explícita
-   - **Riscos e Mitigações** — tabela com probabilidade, impacto e mitigação concreta
-   - **Checklist de Aprovação** — checkboxes para revisão humana
-
-4. **Qualidade:** O DESIGN.md deve responder claramente: O QUÊ, POR QUÊ, PARA QUEM, O QUE NÃO e QUAIS RISCOS. Use "[A definir]" para informações não disponíveis, mas nunca omita seções.
-
-5. **Salve** `DARE/DESIGN.md` e informe: _"DESIGN.md gerado. Revise as seções, especialmente os Requisitos de Segurança (RS-*) e Riscos. Quando aprovado, execute `/generate-blueprint`."_
+# Comando: /dare-design
+
+## Descrição
+Inicia o Método DARE (fase Design) gerando `DARE/DESIGN.md` a partir de uma ideia inicial.
+
+## Instruções para o Cursor Composer
+
+1. **Leia o contexto:** `package.json` / `Cargo.toml` / `composer.json` / `go.mod` / `requirements.txt` para identificar a stack atual. Leia `.cursorrules` para entender padrões do projeto. Se `DARE/DESIGN.md` já existir, não sobrescreva sem aprovação explícita.
+
+2. **Leia o template:** `templates/DESIGN-template.md` — siga a estrutura fielmente.
+
+3. **Gere `DARE/DESIGN.md` com as seções obrigatórias:**
+
+   - **Descrição** — 3 a 5 frases: o que é, qual problema resolve, quem usa
+   - **Objetivos e Métricas de Sucesso** — tabela numerada (O-01, O-02…) com métrica verificável e meta numérica
+   - **Stakeholders** — tabela: papel, time, interesse principal
+   - **Requisitos Funcionais** — tabela numerada (RF-01, RF-02…) com prioridade MUST/SHOULD/COULD e critério de aceite
+   - **Requisitos Não-Funcionais** — tabela numerada (RNF-01…): performance, disponibilidade, segurança, observabilidade, manutenibilidade
+   - **Requisitos de Segurança** — tabela numerada (RS-01…). **Sempre inclua:**
+     - RS-01: validação de entrada no servidor (OWASP A03)
+     - RS-02: hash de senhas / proteção de dados sensíveis (OWASP A02)
+     - RS-03: controle de acesso por recurso (OWASP A01)
+     - RS-04: auditoria de dependências sem CVE HIGH/CRITICAL (OWASP A06)
+     - RS-05: secrets via variáveis de ambiente — nunca em código
+     - Requisitos específicos do domínio do projeto
+   - **Stack Técnica** — tabela por camada com versões fixas
+   - **Integrações Externas** — tabela: sistema, tipo, protocolo, direção, dados, responsável
+   - **Restrições** — prazo, orçamento, técnicas, compliance
+   - **Fora do Escopo (v1)** — lista explícita
+   - **Riscos e Mitigações** — tabela com probabilidade, impacto e mitigação concreta
+   - **Checklist de Aprovação** — checkboxes para revisão humana
+
+4. **Qualidade:** O DESIGN.md deve responder claramente: O QUÊ, POR QUÊ, PARA QUEM, O QUE NÃO e QUAIS RISCOS. Use "[A definir]" para informações não disponíveis, mas nunca omita seções.
+
+5. **Salve** `DARE/DESIGN.md` e informe: _"DESIGN.md gerado. Revise as seções, especialmente os Requisitos de Segurança (RS-*) e Riscos. Quando aprovado, execute `/generate-blueprint`."_

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

@@ -1,28 +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`
+# 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

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