@dewtech/dare-cli 2.17.0 → 3.1.0

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

@@ -1,197 +1,197 @@
-# /dare-dag-viz — Visualizar DAG com Excalidraw
-
-Gera diagrama interativo `.excalidraw` a partir do `dare-dag.yaml` atual, com cores semânticas por complexidade e status visual das tasks.
-
-## O que faz
-
-1. **Lê** `DARE/dare-dag.yaml` (grafo de tasks + dependências)
-2. **Mapeia** cada task para um retângulo Excalidraw com:
-   - Cor baseada em `complexity` (LOW=azul, MED=laranja, HIGH=rosa)
-   - Status visual (PENDING/RUNNING/DONE/FAILED)
-   - ID + nome da task
-3. **Agrupa** tasks por `rank` em colunas verticais (swim lanes)
-4. **Cria** setas para cada dependência (`depends_on`)
-5. **Salva** em `DARE/dag-graph.excalidraw`
-
-Output é um arquivo **editável e interativo** — abre direto em https://excalidraw.com.
-
-## Convenções visuais
-
-Referência: `/docs/DESIGN-TOKENS-EXCALIDRAW.md`
-
-**Cores por complexidade:**
-- 🔵 **Azul** (#e3f2fd) = LOW
-- 🟠 **Laranja** (#fff3e0) = MEDIUM
-- 🔴 **Rosa** (#fce4ec) = HIGH
-
-**Status:**
-- ⏳ PENDING = cinza, stroke normal
-- ⚙️ RUNNING = azul, stroke pontilhado
-- ✅ DONE = verde
-- ❌ FAILED = vermelho
-
-**Posicionamento:**
-- Cada task ocupa 120×60px
-- Tasks no mesmo rank ficam lado a lado (swim lane)
-- Setas conectam dependências
-
-## Exemplo de output
-
-Arquivo `DARE/dag-graph.excalidraw` com estrutura:
-
-```
-Rank 1
-├── task-001 (LOW, DONE)
-├── task-002 (HIGH, PENDING)
-
-Rank 2
-├── task-003 (MEDIUM, RUNNING) ← depende de task-001
-├── task-004 (LOW, PENDING) ← depende de task-001
-
-Rank 3
-└── task-005 (HIGH, PENDING) ← depende de task-003 e task-004
-```
-
-## Como usar
-
-### Primeira vez
-
-```bash
-/dare-dag-viz
-```
-
-Claude Code vai:
-1. Ler `DARE/dare-dag.yaml`
-2. Gerar JSON `.excalidraw`
-3. Salvar em `DARE/dag-graph.excalidraw`
-4. Output: "✅ DAG gerado — abra em https://excalidraw.com"
-
-### Atualizar após mudanças
-
-Sempre que você atualiza `dare-dag.yaml`:
-
-```bash
-/dare-dag-viz
-```
-
-Isso regenera o diagrama com as novas tasks/dependências.
-
-### Abrir e editar
-
-1. Acesse https://excalidraw.com
-2. File → Open → selecione `DARE/dag-graph.excalidraw`
-3. Edite livremente:
-   - Mova elementos
-   - Customize cores/textos
-   - Adicione anotações
-4. Salve no mesmo arquivo
-
-Dica: Se editou manualmente e quer regenerar com `dare-dag-viz` de novo, faça backup antes.
-
-## Detalhes técnicos
-
-### Estrutura do JSON gerado
-
-```json
-{
-  "elements": [
-    {
-      "id": "task-001",
-      "type": "rectangle",
-      "x": 20, "y": 20,
-      "width": 120, "height": 60,
-      "backgroundColor": "#e3f2fd",
-      "stroke": "#1976d2",
-      "text": "task-001\nSetup Auth\n[LOW]",
-      "fontSize": 12,
-      "roundness": { "type": 2, "value": 6 }
-    },
-    {
-      "type": "arrow",
-      "startBinding": { "elementId": "task-001" },
-      "endBinding": { "elementId": "task-003" },
-      "stroke": "#999"
-    }
-  ],
-  "appState": {
-    "gridMode": "grid",
-    "gridSize": 20
-  }
-}
-```
-
-### Algoritmo de posicionamento
-
-1. **Calcular ranks** — depth-first do DAG
-   ```
-   rank = 1 + max(rank of dependencies)
-   ```
-
-2. **Agrupar por rank**
-   ```
-   Rank 1: [task-001, task-002]
-   Rank 2: [task-003, task-004]
-   ```
-
-3. **Posicionar**
-   ```
-   x = 20 + (taskIndex * 140)
-   y = 20 + (rank - 1) * 160
-   ```
-
-4. **Desenhar setas**
-   ```
-   Para cada depends_on: arrow(source → target)
-   ```
-
-## Campos esperados em dare-dag.yaml
-
-```yaml
-tasks:
-  task-001:
-    name: "Setup Auth"
-    complexity: "LOW"           # ← determina cor
-    rank: 1                     # ← se não existir, é calculado
-    depends_on: []              # ← usada para setas
-    status: "DONE"              # ← determina stroke/fill
-    subtask_prompt: "..."       # ← (opcional)
-```
-
-**Campos obrigatórios:** `name`, `complexity`  
-**Campos opcionais:** `rank` (calculado), `status` (default PENDING), `depends_on` (default [])
-
-## Troubleshooting
-
-### "File not found: DARE/dare-dag.yaml"
-Certifique-se de que está em um projeto DARE. Se não, rode:
-```bash
-dare discover
-```
-
-### "JSON inválido"
-Valide seu `dare-dag.yaml`:
-```bash
-dare dag validate
-```
-
-### Diagrama muito grande/pequeno
-Abra em Excalidraw e ajuste com Ctrl+Mouse ou pinch zoom.
-
-## Próximos passos
-
-- 🎨 Customize as cores em `docs/DESIGN-TOKENS-EXCALIDRAW.md`
-- 📤 Exporte para PNG com botão "Export to Image" no Excalidraw
-- 🔄 Atualize após cada `dare design` ou `dare execute`
-- 📊 Compartilhe com stakeholders (Excalidraw é colaborativo)
-
-## Referência de design
-
-Ver `/docs/DESIGN-TOKENS-EXCALIDRAW.md` para detalhes de cores, fonts, tamanhos, e créditos.
-
-## Licença
-
-Esta skill é parte do DARE CLI e está sob AGPL v3.
-
-Você pode usar, modificar e compartilhar — mas contribuições voltam ao DARE.
-
-Créditos: Inspiração na [Excalidraw Diagram Skill](https://github.com/coleam00/excalidraw-diagram-skill) por Cole Medin.
+# /dare-dag-viz — Visualizar DAG com Excalidraw
+
+Gera diagrama interativo `.excalidraw` a partir do `dare-dag.yaml` atual, com cores semânticas por complexidade e status visual das tasks.
+
+## O que faz
+
+1. **Lê** `DARE/dare-dag.yaml` (grafo de tasks + dependências)
+2. **Mapeia** cada task para um retângulo Excalidraw com:
+   - Cor baseada em `complexity` (LOW=azul, MED=laranja, HIGH=rosa)
+   - Status visual (PENDING/RUNNING/DONE/FAILED)
+   - ID + nome da task
+3. **Agrupa** tasks por `rank` em colunas verticais (swim lanes)
+4. **Cria** setas para cada dependência (`depends_on`)
+5. **Salva** em `DARE/dag-graph.excalidraw`
+
+Output é um arquivo **editável e interativo** — abre direto em https://excalidraw.com.
+
+## Convenções visuais
+
+Referência: `/docs/DESIGN-TOKENS-EXCALIDRAW.md`
+
+**Cores por complexidade:**
+- 🔵 **Azul** (#e3f2fd) = LOW
+- 🟠 **Laranja** (#fff3e0) = MEDIUM
+- 🔴 **Rosa** (#fce4ec) = HIGH
+
+**Status:**
+- ⏳ PENDING = cinza, stroke normal
+- ⚙️ RUNNING = azul, stroke pontilhado
+- ✅ DONE = verde
+- ❌ FAILED = vermelho
+
+**Posicionamento:**
+- Cada task ocupa 120×60px
+- Tasks no mesmo rank ficam lado a lado (swim lane)
+- Setas conectam dependências
+
+## Exemplo de output
+
+Arquivo `DARE/dag-graph.excalidraw` com estrutura:
+
+```
+Rank 1
+├── task-001 (LOW, DONE)
+├── task-002 (HIGH, PENDING)
+
+Rank 2
+├── task-003 (MEDIUM, RUNNING) ← depende de task-001
+├── task-004 (LOW, PENDING) ← depende de task-001
+
+Rank 3
+└── task-005 (HIGH, PENDING) ← depende de task-003 e task-004
+```
+
+## Como usar
+
+### Primeira vez
+
+```bash
+/dare-dag-viz
+```
+
+Claude Code vai:
+1. Ler `DARE/dare-dag.yaml`
+2. Gerar JSON `.excalidraw`
+3. Salvar em `DARE/dag-graph.excalidraw`
+4. Output: "✅ DAG gerado — abra em https://excalidraw.com"
+
+### Atualizar após mudanças
+
+Sempre que você atualiza `dare-dag.yaml`:
+
+```bash
+/dare-dag-viz
+```
+
+Isso regenera o diagrama com as novas tasks/dependências.
+
+### Abrir e editar
+
+1. Acesse https://excalidraw.com
+2. File → Open → selecione `DARE/dag-graph.excalidraw`
+3. Edite livremente:
+   - Mova elementos
+   - Customize cores/textos
+   - Adicione anotações
+4. Salve no mesmo arquivo
+
+Dica: Se editou manualmente e quer regenerar com `dare-dag-viz` de novo, faça backup antes.
+
+## Detalhes técnicos
+
+### Estrutura do JSON gerado
+
+```json
+{
+  "elements": [
+    {
+      "id": "task-001",
+      "type": "rectangle",
+      "x": 20, "y": 20,
+      "width": 120, "height": 60,
+      "backgroundColor": "#e3f2fd",
+      "stroke": "#1976d2",
+      "text": "task-001\nSetup Auth\n[LOW]",
+      "fontSize": 12,
+      "roundness": { "type": 2, "value": 6 }
+    },
+    {
+      "type": "arrow",
+      "startBinding": { "elementId": "task-001" },
+      "endBinding": { "elementId": "task-003" },
+      "stroke": "#999"
+    }
+  ],
+  "appState": {
+    "gridMode": "grid",
+    "gridSize": 20
+  }
+}
+```
+
+### Algoritmo de posicionamento
+
+1. **Calcular ranks** — depth-first do DAG
+   ```
+   rank = 1 + max(rank of dependencies)
+   ```
+
+2. **Agrupar por rank**
+   ```
+   Rank 1: [task-001, task-002]
+   Rank 2: [task-003, task-004]
+   ```
+
+3. **Posicionar**
+   ```
+   x = 20 + (taskIndex * 140)
+   y = 20 + (rank - 1) * 160
+   ```
+
+4. **Desenhar setas**
+   ```
+   Para cada depends_on: arrow(source → target)
+   ```
+
+## Campos esperados em dare-dag.yaml
+
+```yaml
+tasks:
+  task-001:
+    name: "Setup Auth"
+    complexity: "LOW"           # ← determina cor
+    rank: 1                     # ← se não existir, é calculado
+    depends_on: []              # ← usada para setas
+    status: "DONE"              # ← determina stroke/fill
+    subtask_prompt: "..."       # ← (opcional)
+```
+
+**Campos obrigatórios:** `name`, `complexity`  
+**Campos opcionais:** `rank` (calculado), `status` (default PENDING), `depends_on` (default [])
+
+## Troubleshooting
+
+### "File not found: DARE/dare-dag.yaml"
+Certifique-se de que está em um projeto DARE. Se não, rode:
+```bash
+dare discover
+```
+
+### "JSON inválido"
+Valide seu `dare-dag.yaml`:
+```bash
+dare dag validate
+```
+
+### Diagrama muito grande/pequeno
+Abra em Excalidraw e ajuste com Ctrl+Mouse ou pinch zoom.
+
+## Próximos passos
+
+- 🎨 Customize as cores em `docs/DESIGN-TOKENS-EXCALIDRAW.md`
+- 📤 Exporte para PNG com botão "Export to Image" no Excalidraw
+- 🔄 Atualize após cada `dare design` ou `dare execute`
+- 📊 Compartilhe com stakeholders (Excalidraw é colaborativo)
+
+## Referência de design
+
+Ver `/docs/DESIGN-TOKENS-EXCALIDRAW.md` para detalhes de cores, fonts, tamanhos, e créditos.
+
+## Licença
+
+Esta skill é parte do DARE CLI e está sob licença MIT (D-001).
+
+Você pode usar, modificar, compartilhar e distribuir livremente.
+
+Créditos: Inspiração na [Excalidraw Diagram Skill](https://github.com/coleam00/excalidraw-diagram-skill) por Cole Medin.

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

@@ -1,69 +1,69 @@
-# /dare-design
-
-Gera ou atualiza o `DARE/DESIGN.md` a partir de uma descrição do projeto ou feature.
-
-## Como usar
-
-```
-/dare-design Quero uma API REST de autenticação com JWT e refresh token
-/dare-design Adicionar módulo de pagamentos com Stripe e webhook
-```
-
-## O que fazer
-
-### 1. Leia o contexto atual do projeto
-
-- `package.json` / `composer.json` / `Cargo.toml` / `go.mod` / `requirements.txt` — stack atual
-- Estrutura de pastas existente
-- `DARE/DESIGN.md` se já existir — não sobrescreva sem aprovação explícita do usuário
-
-### 2. Gere `DARE/DESIGN.md` com as seguintes seções obrigatórias
-
-**2.1 Descrição** — 3 a 5 frases claras: o que é, qual problema resolve, quem usa.
-
-**2.2 Objetivos e Métricas de Sucesso** — tabela numerada (O-01, O-02…) com métrica verificável e meta numérica para cada objetivo. Evite objetivos vagos como "melhorar performance" — use "p99 < 200 ms".
-
-**2.3 Stakeholders** — tabela: papel, nome/time, interesse principal.
-
-**2.4 Requisitos Funcionais** — tabela numerada (RF-01, RF-02…) com prioridade MUST/SHOULD/COULD e critério de aceite verificável para cada um.
-
-**2.5 Requisitos Não-Funcionais** — tabela numerada (RNF-01…) cobrindo: performance, disponibilidade, segurança (autenticação, rate limiting, segredos), observabilidade, manutenibilidade.
-
-**2.6 Requisitos de Segurança** — tabela numerada (RS-01…). Inclua **sempre**:
-- RS-01: validação de entrada (OWASP A03)
-- RS-02: proteção de dados sensíveis / hash de senhas (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
-- Adicione requisitos específicos do domínio do projeto
-
-**2.7 Stack Técnica** — tabela por camada com tecnologia e versão.
-
-**2.8 Integrações Externas** — tabela: sistema, tipo, protocolo, direção, dados trocados, responsável. Inclua apenas integrações confirmadas; marque incertas como "A confirmar".
-
-**2.9 Restrições** — prazo, orçamento de infra, limitações técnicas, compliance regulatório.
-
-**2.10 Fora do Escopo (v1)** — lista explícita do que NÃO será feito e o motivo.
-
-**2.11 Riscos e Mitigações** — tabela: risco, probabilidade (Alta/Média/Baixa), impacto (Alto/Médio/Baixo), mitigação concreta.
-
-**2.12 Checklist de Aprovação** — checkboxes para o usuário revisar antes de avançar ao `/dare-blueprint`.
-
-### 3. Use o template em `templates/DESIGN-template.md`
-
-Siga o template fielmente. Não omita seções — use "[A definir]" se a informação não estiver disponível ainda, mas deixe a seção explícita para o usuário preencher.
-
-### 4. Qualidade esperada
-
-O DESIGN.md gerado deve permitir que qualquer engenheiro novo no projeto entenda:
-- **O QUÊ** vai ser construído (requisitos funcionais)
-- **POR QUÊ** (objetivos e métricas)
-- **PARA QUEM** (stakeholders e personas)
-- **O QUE NÃO** vai ser feito (escopo)
-- **QUAIS RISCOS** existem (com mitigação)
-
-### 5. Confirme com o usuário antes de prosseguir
-
-Após gerar o DESIGN.md, apresente um resumo das seções geradas e pergunte se o usuário quer ajustar algo antes de rodar `/dare-blueprint`.
-
-$ARGUMENTS
+# /dare-design
+
+Gera ou atualiza o `DARE/DESIGN.md` a partir de uma descrição do projeto ou feature.
+
+## Como usar
+
+```
+/dare-design Quero uma API REST de autenticação com JWT e refresh token
+/dare-design Adicionar módulo de pagamentos com Stripe e webhook
+```
+
+## O que fazer
+
+### 1. Leia o contexto atual do projeto
+
+- `package.json` / `composer.json` / `Cargo.toml` / `go.mod` / `requirements.txt` — stack atual
+- Estrutura de pastas existente
+- `DARE/DESIGN.md` se já existir — não sobrescreva sem aprovação explícita do usuário
+
+### 2. Gere `DARE/DESIGN.md` com as seguintes seções obrigatórias
+
+**2.1 Descrição** — 3 a 5 frases claras: o que é, qual problema resolve, quem usa.
+
+**2.2 Objetivos e Métricas de Sucesso** — tabela numerada (O-01, O-02…) com métrica verificável e meta numérica para cada objetivo. Evite objetivos vagos como "melhorar performance" — use "p99 < 200 ms".
+
+**2.3 Stakeholders** — tabela: papel, nome/time, interesse principal.
+
+**2.4 Requisitos Funcionais** — tabela numerada (RF-01, RF-02…) com prioridade MUST/SHOULD/COULD e critério de aceite verificável para cada um.
+
+**2.5 Requisitos Não-Funcionais** — tabela numerada (RNF-01…) cobrindo: performance, disponibilidade, segurança (autenticação, rate limiting, segredos), observabilidade, manutenibilidade.
+
+**2.6 Requisitos de Segurança** — tabela numerada (RS-01…). Inclua **sempre**:
+- RS-01: validação de entrada (OWASP A03)
+- RS-02: proteção de dados sensíveis / hash de senhas (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
+- Adicione requisitos específicos do domínio do projeto
+
+**2.7 Stack Técnica** — tabela por camada com tecnologia e versão.
+
+**2.8 Integrações Externas** — tabela: sistema, tipo, protocolo, direção, dados trocados, responsável. Inclua apenas integrações confirmadas; marque incertas como "A confirmar".
+
+**2.9 Restrições** — prazo, orçamento de infra, limitações técnicas, compliance regulatório.
+
+**2.10 Fora do Escopo (v1)** — lista explícita do que NÃO será feito e o motivo.
+
+**2.11 Riscos e Mitigações** — tabela: risco, probabilidade (Alta/Média/Baixa), impacto (Alto/Médio/Baixo), mitigação concreta.
+
+**2.12 Checklist de Aprovação** — checkboxes para o usuário revisar antes de avançar ao `/dare-blueprint`.
+
+### 3. Use o template em `templates/DESIGN-template.md`
+
+Siga o template fielmente. Não omita seções — use "[A definir]" se a informação não estiver disponível ainda, mas deixe a seção explícita para o usuário preencher.
+
+### 4. Qualidade esperada
+
+O DESIGN.md gerado deve permitir que qualquer engenheiro novo no projeto entenda:
+- **O QUÊ** vai ser construído (requisitos funcionais)
+- **POR QUÊ** (objetivos e métricas)
+- **PARA QUEM** (stakeholders e personas)
+- **O QUE NÃO** vai ser feito (escopo)
+- **QUAIS RISCOS** existem (com mitigação)
+
+### 5. Confirme com o usuário antes de prosseguir
+
+Após gerar o DESIGN.md, apresente um resumo das seções geradas e pergunte se o usuário quer ajustar algo antes de rodar `/dare-blueprint`.
+
+$ARGUMENTS

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

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