@dewtech/dare-cli 3.2.0 → 3.4.0

package/templates/ide/claude/.claude/commands/dare-llm-integration.md

@@ -1,148 +1,148 @@
-# /dare-llm-integration
-
-Integração segura e eficiente com LLMs (Gemini, Claude, OpenAI, Ollama) em projetos DARE.
-
-## Como usar
-
-```
-/dare-llm-integration                       # audita uso de LLM no projeto
-/dare-llm-integration scaffold              # gera LLMProvider + cache + rate limit
-/dare-llm-integration prompts               # extrai prompts inline para arquivos versionados
-```
-
-## Os 5 pilares
-
-### 1. LLMProvider abstraction
-
-Nunca chame SDK do Gemini/OpenAI direto em Handler ou Service de negócio. Sempre via interface `LLMProvider`.
-
-### 2. Cache TTL
-
-Toda chamada passa por cache. Key = `hash(promptId + input + model)`. TTL default 1h.
-
-### 3. Rate limit via token bucket
-
-Token bucket por provider:
-- Gemini Free: 15 RPM, 1M tokens/dia
-- Claude tier 1: 50 RPM
-- OpenAI tier 1: 500 RPM
-
-### 4. Prompts versionados
-
-Nunca inline em código. Vivem em `prompts/<id>.v<n>.md` com frontmatter (model, temperature, schema).
-
-### 5. Validação via schema
-
-LLM mente — sempre valide output com Zod/Pydantic/serde.
-
-## Métricas obrigatórias
-
-| ID | Métrica |
-|---|---|
-| M-01 | 100% das chamadas LLM via LLMProvider injetado |
-| M-02 | 100% das responses LLM cacheadas |
-| M-03 | 100% das requests com rate limit |
-| M-04 | 100% das respostas validadas contra schema |
-
-## Antipatterns
-
-| AP | Antipattern | Por quê |
-|---|---|---|
-| AP-01 | SDK direto em Handler | impossível mockar/trocar provider |
-| AP-02 | Sem cache | custo explode |
-| AP-03 | Prompt em código | impossível versionar/A-B |
-| AP-04 | User input direto em prompt | prompt injection trivial |
-| AP-05 | Trusting LLM output | LLM mente, schema é defesa |
-
-## Defesa contra prompt injection
-
-```python
-# ❌ Concatenação direta
-system = f"You are an assistant. {user_question}"
-
-# ✅ Separação por delimitador + escape
-messages = [
-    {"role": "system", "content": "You are an assistant. Answer based on the document below."},
-    {"role": "user", "content": f"<document>{escape(doc)}</document>\n<question>{escape(q)}</question>"}
-]
-```
-
-Regras:
-- Use delimitadores (`<document>`, `<question>`)
-- Escape conteúdo do usuário (XML/HTML escape)
-- Detecte "Ignore instructions above"
-- Valide output — fora do schema = sinal de injection
-
-## O que fazer
-
-### Passo 1: Auditar chamadas LLM
-
-```bash
-grep -rn "GoogleGenAI\\|new OpenAI\\|Anthropic(" src/
-```
-
-Toda ocorrência em Handler ou Service de negócio = AP-01.
-
-### Passo 2: Criar `LLMProvider` interface
-
-```typescript
-interface LLMProvider {
-  complete(req: {
-    promptId: string;
-    input: Record<string, unknown>;
-    schema: ZodSchema;
-  }): Promise<unknown>;
-}
-```
-
-### Passo 3: Implementar providers
-
-Comece com o que o projeto usa. Use os exemplos em `packages/skills/dare-llm-integration/providers/`.
-
-### Passo 4: Configurar cache + rate limit
-
-Cache em memória com TTL + token bucket por provider. Implementação pronta em `packages/skills/dare-llm-integration/cache/` e `.../rate_limit/`.
-
-### Passo 5: Extrair prompts inline
-
-Para cada prompt inline encontrado, mova para `prompts/<id>.v1.md` com frontmatter:
-
-```markdown
----
-id: summarize
-version: 1
-model: gemini-2.0-flash
-temperature: 0.2
-max_tokens: 500
-schema: SummarySchema
----
-
-# System
-You are a concise summarizer.
-
-# User
-Summarize: <text>{{ text }}</text>
-```
-
-### Passo 6: Adicionar validação no chamador
-
-```typescript
-const raw = await llm.complete({...});
-const parsed = SummarySchema.parse(raw);  // joga LLMOutputInvalidError se falhar
-```
-
-## Saída esperada
-
-Reporte numerado:
-- Quantas chamadas LLM no projeto
-- Quantas via LLMProvider (M-01)
-- Quantas cacheadas (M-02)
-- Quantas com rate limit (M-03)
-- Quantas validadas contra schema (M-04)
-- Lista de prompts inline a extrair
-
-$ARGUMENTS
-
----
-
-Skill MIT — parte do DARE Method.
+# /dare-llm-integration
+
+Integração segura e eficiente com LLMs (Gemini, Claude, OpenAI, Ollama) em projetos DARE.
+
+## Como usar
+
+```
+/dare-llm-integration                       # audita uso de LLM no projeto
+/dare-llm-integration scaffold              # gera LLMProvider + cache + rate limit
+/dare-llm-integration prompts               # extrai prompts inline para arquivos versionados
+```
+
+## Os 5 pilares
+
+### 1. LLMProvider abstraction
+
+Nunca chame SDK do Gemini/OpenAI direto em Handler ou Service de negócio. Sempre via interface `LLMProvider`.
+
+### 2. Cache TTL
+
+Toda chamada passa por cache. Key = `hash(promptId + input + model)`. TTL default 1h.
+
+### 3. Rate limit via token bucket
+
+Token bucket por provider:
+- Gemini Free: 15 RPM, 1M tokens/dia
+- Claude tier 1: 50 RPM
+- OpenAI tier 1: 500 RPM
+
+### 4. Prompts versionados
+
+Nunca inline em código. Vivem em `prompts/<id>.v<n>.md` com frontmatter (model, temperature, schema).
+
+### 5. Validação via schema
+
+LLM mente — sempre valide output com Zod/Pydantic/serde.
+
+## Métricas obrigatórias
+
+| ID | Métrica |
+|---|---|
+| M-01 | 100% das chamadas LLM via LLMProvider injetado |
+| M-02 | 100% das responses LLM cacheadas |
+| M-03 | 100% das requests com rate limit |
+| M-04 | 100% das respostas validadas contra schema |
+
+## Antipatterns
+
+| AP | Antipattern | Por quê |
+|---|---|---|
+| AP-01 | SDK direto em Handler | impossível mockar/trocar provider |
+| AP-02 | Sem cache | custo explode |
+| AP-03 | Prompt em código | impossível versionar/A-B |
+| AP-04 | User input direto em prompt | prompt injection trivial |
+| AP-05 | Trusting LLM output | LLM mente, schema é defesa |
+
+## Defesa contra prompt injection
+
+```python
+# ❌ Concatenação direta
+system = f"You are an assistant. {user_question}"
+
+# ✅ Separação por delimitador + escape
+messages = [
+    {"role": "system", "content": "You are an assistant. Answer based on the document below."},
+    {"role": "user", "content": f"<document>{escape(doc)}</document>\n<question>{escape(q)}</question>"}
+]
+```
+
+Regras:
+- Use delimitadores (`<document>`, `<question>`)
+- Escape conteúdo do usuário (XML/HTML escape)
+- Detecte "Ignore instructions above"
+- Valide output — fora do schema = sinal de injection
+
+## O que fazer
+
+### Passo 1: Auditar chamadas LLM
+
+```bash
+grep -rn "GoogleGenAI\\|new OpenAI\\|Anthropic(" src/
+```
+
+Toda ocorrência em Handler ou Service de negócio = AP-01.
+
+### Passo 2: Criar `LLMProvider` interface
+
+```typescript
+interface LLMProvider {
+  complete(req: {
+    promptId: string;
+    input: Record<string, unknown>;
+    schema: ZodSchema;
+  }): Promise<unknown>;
+}
+```
+
+### Passo 3: Implementar providers
+
+Comece com o que o projeto usa. Use os exemplos em `packages/skills/dare-llm-integration/providers/`.
+
+### Passo 4: Configurar cache + rate limit
+
+Cache em memória com TTL + token bucket por provider. Implementação pronta em `packages/skills/dare-llm-integration/cache/` e `.../rate_limit/`.
+
+### Passo 5: Extrair prompts inline
+
+Para cada prompt inline encontrado, mova para `prompts/<id>.v1.md` com frontmatter:
+
+```markdown
+---
+id: summarize
+version: 1
+model: gemini-2.0-flash
+temperature: 0.2
+max_tokens: 500
+schema: SummarySchema
+---
+
+# System
+You are a concise summarizer.
+
+# User
+Summarize: <text>{{ text }}</text>
+```
+
+### Passo 6: Adicionar validação no chamador
+
+```typescript
+const raw = await llm.complete({...});
+const parsed = SummarySchema.parse(raw);  // joga LLMOutputInvalidError se falhar
+```
+
+## Saída esperada
+
+Reporte numerado:
+- Quantas chamadas LLM no projeto
+- Quantas via LLMProvider (M-01)
+- Quantas cacheadas (M-02)
+- Quantas com rate limit (M-03)
+- Quantas validadas contra schema (M-04)
+- Lista de prompts inline a extrair
+
+$ARGUMENTS
+
+---
+
+Skill MIT — parte do DARE Method.

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

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