@dewtech/dare-cli 3.2.0 → 3.4.0

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

@@ -1,180 +1,180 @@
----
-name: dare-design
-description: Gera um Implementation Plan estruturado a partir de requisitos de usuário. Use quando o usuário descrever uma ideia ou feature que precisa ser desenvolvida. Cria um documento DESIGN.md com requisitos, funcionalidades e restrições.
----
-
-# DARE Design Skill
-
-Você é um especialista em planejamento e análise de requisitos. Seu objetivo é transformar a ideia inicial do usuário em um documento de Design estruturado que servirá como base para as próximas fases do Método DARE.
-
-## Quando usar esta skill
-
-- Usuário descreve uma nova feature ou projeto
-- Precisa-se clarificar requisitos antes de arquitetar
-- Necessário documentar escopo e restrições
-- Primeira fase do Método DARE
-
-## Como usar
-
-### Passo 1: Entender a Ideia
-Leia cuidadosamente o que o usuário solicitou. Identifique:
-- O objetivo principal
-- Funcionalidades esperadas
-- Contexto do projeto
-- Restrições implícitas
-
-### Passo 2: Fazer Perguntas (se necessário)
-Se algo não estiver claro, pergunte ao usuário:
-- Qual é o escopo exato?
-- Quem são os usuários?
-- Quais são as prioridades?
-- Há restrições técnicas?
-
-### Passo 3: Integrar Segurança (OWASP)
-Sempre adicione requisitos de segurança:
-- Autenticação/Autorização
-- Proteção contra força bruta
-- Validação de entrada
-- Criptografia de dados sensíveis
-- Rate limiting
-
-### Passo 4: Gerar o Design
-Crie um documento `DARE/DESIGN.md` com a seguinte estrutura:
-
-```markdown
-# Design: [Nome do Projeto]
-
-## Visão Geral
-[Descrição clara do projeto]
-
-## Objetivos
-- [Objetivo 1]
-- [Objetivo 2]
-- [Objetivo 3]
-
-## Funcionalidades Principais
-### Feature 1: [Nome]
-- Descrição
-- Casos de uso
-
-### Feature 2: [Nome]
-- Descrição
-- Casos de uso
-
-## Stack Técnica
-- **Backend:** [Linguagem/Framework]
-- **Frontend:** [Framework]
-- **Banco de Dados:** [BD]
-- **Containerização:** Docker
-
-## Requisitos Não-Funcionais
-### Segurança
-- Autenticação: [Tipo]
-- Criptografia: [Tipo]
-- Rate Limiting: Sim/Não
-- Validação: Estrita
-
-### Performance
-- Tempo de resposta: [ms]
-- Escalabilidade: [Tipo]
-
-### Confiabilidade
-- Uptime: [%]
-- Backup: [Frequência]
-
-## Restrições
-- [Restrição 1]
-- [Restrição 2]
-
-## Fora do Escopo (v1.0)
-- [Feature não incluída]
-- [Feature não incluída]
-
-## Próximas Etapas
-1. Revisar e aprovar este Design
-2. Executar `/generate-blueprint DARE/DESIGN.md`
-3. Continuar com o Método DARE
-```
-
-### Passo 5: Pedir Aprovação
-Após gerar o Design, peça ao usuário:
-- Revisar o documento
-- Aprovar ou solicitar mudanças
-- Confirmar antes de continuar
-
-## Boas Práticas
-
-1. **Seja Específico:** Evite ambiguidades
-2. **Inclua Segurança:** Sempre pense em OWASP Top 10
-3. **Documente Restrições:** Deixe claro o que NÃO será feito
-4. **Organize Bem:** Use seções claras e hierarquia
-5. **Revise com Humano:** Nunca pule a aprovação
-
-## Exemplo: API de Autenticação
-
-```markdown
-# Design: API de Autenticação com JWT
-
-## Visão Geral
-Sistema de autenticação robusto com JWT, refresh tokens e proteção contra força bruta.
-
-## Objetivos
-- Permitir login seguro de usuários
-- Emitir JWT com expiração
-- Suportar refresh tokens
-- Proteger contra ataques de força bruta
-
-## Funcionalidades Principais
-### Feature 1: Login
-- Usuário envia email e senha
-- Sistema valida credenciais
-- Retorna JWT e refresh token
-
-### Feature 2: Refresh Token
-- Usuário envia refresh token expirado
-- Sistema valida e emite novo JWT
-- Refresh token é rotacionado
-
-### Feature 3: Proteção contra Força Bruta
-- Máximo 5 tentativas por IP
-- Bloqueio de 15 minutos após limite
-- Log de tentativas
-
-## Stack Técnica
-- **Backend:** Laravel 11 + PHP 8.3
-- **Frontend:** Vue.js 3
-- **Banco de Dados:** PostgreSQL
-- **Containerização:** Docker
-
-## Requisitos Não-Funcionais
-### Segurança
-- Autenticação: JWT com RS256
-- Criptografia: Bcrypt para senhas
-- Rate Limiting: 5 tentativas/15min
-- Validação: Estrita em todos os endpoints
-
-### Performance
-- Tempo de resposta: < 200ms
-- Escalabilidade: Horizontal com Redis
-
-## Restrições
-- Apenas email/senha (sem OAuth nesta versão)
-- Sem 2FA nesta versão
-- Sem integração com LDAP
-
-## Fora do Escopo (v1.0)
-- Autenticação social (Google, GitHub)
-- Two-Factor Authentication
-- Biometria
-
-## Próximas Etapas
-1. Revisar e aprovar este Design
-2. Executar `/generate-blueprint DARE/DESIGN.md`
-```
-
-## Dicas para Melhor Resultado
-
-- **Contexto:** Leia o `.cursorrules` ou `.agents/rules/` para entender a stack do projeto
-- **Exemplos:** Procure por exemplos em `examples/` para manter consistência
-- **Templates:** Use `templates/DESIGN-template.md` como referência
-- **Segurança:** Sempre consulte `skill-security` para requisitos de segurança
+---
+name: dare-design
+description: Gera um Implementation Plan estruturado a partir de requisitos de usuário. Use quando o usuário descrever uma ideia ou feature que precisa ser desenvolvida. Cria um documento DESIGN.md com requisitos, funcionalidades e restrições.
+---
+
+# DARE Design Skill
+
+Você é um especialista em planejamento e análise de requisitos. Seu objetivo é transformar a ideia inicial do usuário em um documento de Design estruturado que servirá como base para as próximas fases do Método DARE.
+
+## Quando usar esta skill
+
+- Usuário descreve uma nova feature ou projeto
+- Precisa-se clarificar requisitos antes de arquitetar
+- Necessário documentar escopo e restrições
+- Primeira fase do Método DARE
+
+## Como usar
+
+### Passo 1: Entender a Ideia
+Leia cuidadosamente o que o usuário solicitou. Identifique:
+- O objetivo principal
+- Funcionalidades esperadas
+- Contexto do projeto
+- Restrições implícitas
+
+### Passo 2: Fazer Perguntas (se necessário)
+Se algo não estiver claro, pergunte ao usuário:
+- Qual é o escopo exato?
+- Quem são os usuários?
+- Quais são as prioridades?
+- Há restrições técnicas?
+
+### Passo 3: Integrar Segurança (OWASP)
+Sempre adicione requisitos de segurança:
+- Autenticação/Autorização
+- Proteção contra força bruta
+- Validação de entrada
+- Criptografia de dados sensíveis
+- Rate limiting
+
+### Passo 4: Gerar o Design
+Crie um documento `DARE/DESIGN.md` com a seguinte estrutura:
+
+```markdown
+# Design: [Nome do Projeto]
+
+## Visão Geral
+[Descrição clara do projeto]
+
+## Objetivos
+- [Objetivo 1]
+- [Objetivo 2]
+- [Objetivo 3]
+
+## Funcionalidades Principais
+### Feature 1: [Nome]
+- Descrição
+- Casos de uso
+
+### Feature 2: [Nome]
+- Descrição
+- Casos de uso
+
+## Stack Técnica
+- **Backend:** [Linguagem/Framework]
+- **Frontend:** [Framework]
+- **Banco de Dados:** [BD]
+- **Containerização:** Docker
+
+## Requisitos Não-Funcionais
+### Segurança
+- Autenticação: [Tipo]
+- Criptografia: [Tipo]
+- Rate Limiting: Sim/Não
+- Validação: Estrita
+
+### Performance
+- Tempo de resposta: [ms]
+- Escalabilidade: [Tipo]
+
+### Confiabilidade
+- Uptime: [%]
+- Backup: [Frequência]
+
+## Restrições
+- [Restrição 1]
+- [Restrição 2]
+
+## Fora do Escopo (v1.0)
+- [Feature não incluída]
+- [Feature não incluída]
+
+## Próximas Etapas
+1. Revisar e aprovar este Design
+2. Executar `/generate-blueprint DARE/DESIGN.md`
+3. Continuar com o Método DARE
+```
+
+### Passo 5: Pedir Aprovação
+Após gerar o Design, peça ao usuário:
+- Revisar o documento
+- Aprovar ou solicitar mudanças
+- Confirmar antes de continuar
+
+## Boas Práticas
+
+1. **Seja Específico:** Evite ambiguidades
+2. **Inclua Segurança:** Sempre pense em OWASP Top 10
+3. **Documente Restrições:** Deixe claro o que NÃO será feito
+4. **Organize Bem:** Use seções claras e hierarquia
+5. **Revise com Humano:** Nunca pule a aprovação
+
+## Exemplo: API de Autenticação
+
+```markdown
+# Design: API de Autenticação com JWT
+
+## Visão Geral
+Sistema de autenticação robusto com JWT, refresh tokens e proteção contra força bruta.
+
+## Objetivos
+- Permitir login seguro de usuários
+- Emitir JWT com expiração
+- Suportar refresh tokens
+- Proteger contra ataques de força bruta
+
+## Funcionalidades Principais
+### Feature 1: Login
+- Usuário envia email e senha
+- Sistema valida credenciais
+- Retorna JWT e refresh token
+
+### Feature 2: Refresh Token
+- Usuário envia refresh token expirado
+- Sistema valida e emite novo JWT
+- Refresh token é rotacionado
+
+### Feature 3: Proteção contra Força Bruta
+- Máximo 5 tentativas por IP
+- Bloqueio de 15 minutos após limite
+- Log de tentativas
+
+## Stack Técnica
+- **Backend:** Laravel 11 + PHP 8.3
+- **Frontend:** Vue.js 3
+- **Banco de Dados:** PostgreSQL
+- **Containerização:** Docker
+
+## Requisitos Não-Funcionais
+### Segurança
+- Autenticação: JWT com RS256
+- Criptografia: Bcrypt para senhas
+- Rate Limiting: 5 tentativas/15min
+- Validação: Estrita em todos os endpoints
+
+### Performance
+- Tempo de resposta: < 200ms
+- Escalabilidade: Horizontal com Redis
+
+## Restrições
+- Apenas email/senha (sem OAuth nesta versão)
+- Sem 2FA nesta versão
+- Sem integração com LDAP
+
+## Fora do Escopo (v1.0)
+- Autenticação social (Google, GitHub)
+- Two-Factor Authentication
+- Biometria
+
+## Próximas Etapas
+1. Revisar e aprovar este Design
+2. Executar `/generate-blueprint DARE/DESIGN.md`
+```
+
+## Dicas para Melhor Resultado
+
+- **Contexto:** Leia o `.cursorrules` ou `.agents/rules/` para entender a stack do projeto
+- **Exemplos:** Procure por exemplos em `examples/` para manter consistência
+- **Templates:** Use `templates/DESIGN-template.md` como referência
+- **Segurança:** Sempre consulte `skill-security` para requisitos de segurança

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

@@ -1,33 +1,33 @@
----
-name: dare-discover
-description: 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. Mapeia o CLI `dare discover`.
----
-
-# Adotar o DARE em um projeto existente
-
-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`
+---
+name: dare-discover
+description: 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. Mapeia o CLI `dare discover`.
+---
+
+# Adotar o DARE em um projeto existente
+
+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/antigravity/.agents/skills/dare-dna/SKILL.md

@@ -1,63 +1,63 @@
----
-name: dare-dna
-description: Camada semântica da extração de DNA do projeto. Roda depois do comando `dare dna` e transforma os fatos de convenção em regras acionáveis no DARE/PROJECT-DNA.md, para o agente seguir o padrão da casa em projetos legados.
----
-
-# DARE DNA Skill — Convenções do Projeto (brownfield)
-
-Você é o agente que transforma os **fatos de convenção** de um codebase legado em **regras acionáveis**.
-Esta skill é a camada **semântica**: roda **depois** do comando `dare dna`, que já varreu o código e
-extraiu os fatos. Sua função é redigir o "como esse codebase faz as coisas" que uma nova feature deve
-respeitar — para o agente seguir o padrão da casa, não o default genérico do DARE.
-
-> Pré-requisito: o comando `dare dna` precisa ter rodado antes (gera `DARE/PROJECT-DNA.md` e
-> `DARE/dna-facts.json`). Se não existirem, peça ao usuário para rodar `dare dna` primeiro.
-
-## Quando usar esta skill
-
-- 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.
-
-## Passo a passo
-
-### 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** (controller, service, model, teste) para inferir o
-  que o CLI não detecta (tratamento de erro, validação, estilo de teste).
-
-### 2. Preencher `DARE/PROJECT-DNA.md`
-Substitua cada `<!-- AGENT: ... -->`:
-- **Convenções de Nomenclatura** — confirme o estilo + exceções.
-- **Arquitetura & Camadas** — nomeie o padrão (MVC/Layered/Hexagonal) + regras de onde cada coisa mora.
-- **Padrões de Teste** — onde ficam, naming, assertions reais, mocks/fixtures.
-- **Tratamento de Erros & Validação** — como erros são tratados e inputs validados (exemplos reais).
-- **Regras de Ouro** — o que SEMPRE e NUNCA fazer neste codebase.
-- **⚠️ Incertezas** — convenções ambíguas que o humano precisa decidir.
-
-**Não toque** nos fatos determinísticos do CLI (tooling, tabela de naming, libs).
-
-### 3. Apresentar ao usuário
-Resumo: arquitetura nomeada, regras de ouro, inconsistências. 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** — como o código É, não como deveria ser.
-2. **Exemplos reais** — cite arquivos/trechos do projeto.
-3. **Sinalize inconsistência** — não invente um padrão único onde o legado mistura.
-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 do CLI.
-
-## Antipatterns
-
-| AP | Antipattern | Por quê |
-|---|---|---|
-| AP-01 | Documentar o padrão "ideal" em vez do real | Código gerado sai fora do estilo do legado |
-| AP-02 | Forçar padrão único onde o legado é inconsistente | Esconde a realidade |
-| 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á no específico |
-| AP-05 | Ignorar os testes existentes | Nova feature nasce inconsistente |
-
----
-
-Skill MIT — parte do DARE Method. DNA do projeto (brownfield). Pareia com o comando `dare dna`.
+---
+name: dare-dna
+description: Camada semântica da extração de DNA do projeto. Roda depois do comando `dare dna` e transforma os fatos de convenção em regras acionáveis no DARE/PROJECT-DNA.md, para o agente seguir o padrão da casa em projetos legados.
+---
+
+# DARE DNA Skill — Convenções do Projeto (brownfield)
+
+Você é o agente que transforma os **fatos de convenção** de um codebase legado em **regras acionáveis**.
+Esta skill é a camada **semântica**: roda **depois** do comando `dare dna`, que já varreu o código e
+extraiu os fatos. Sua função é redigir o "como esse codebase faz as coisas" que uma nova feature deve
+respeitar — para o agente seguir o padrão da casa, não o default genérico do DARE.
+
+> Pré-requisito: o comando `dare dna` precisa ter rodado antes (gera `DARE/PROJECT-DNA.md` e
+> `DARE/dna-facts.json`). Se não existirem, peça ao usuário para rodar `dare dna` primeiro.
+
+## Quando usar esta skill
+
+- 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.
+
+## Passo a passo
+
+### 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** (controller, service, model, teste) para inferir o
+  que o CLI não detecta (tratamento de erro, validação, estilo de teste).
+
+### 2. Preencher `DARE/PROJECT-DNA.md`
+Substitua cada `<!-- AGENT: ... -->`:
+- **Convenções de Nomenclatura** — confirme o estilo + exceções.
+- **Arquitetura & Camadas** — nomeie o padrão (MVC/Layered/Hexagonal) + regras de onde cada coisa mora.
+- **Padrões de Teste** — onde ficam, naming, assertions reais, mocks/fixtures.
+- **Tratamento de Erros & Validação** — como erros são tratados e inputs validados (exemplos reais).
+- **Regras de Ouro** — o que SEMPRE e NUNCA fazer neste codebase.
+- **⚠️ Incertezas** — convenções ambíguas que o humano precisa decidir.
+
+**Não toque** nos fatos determinísticos do CLI (tooling, tabela de naming, libs).
+
+### 3. Apresentar ao usuário
+Resumo: arquitetura nomeada, regras de ouro, inconsistências. 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** — como o código É, não como deveria ser.
+2. **Exemplos reais** — cite arquivos/trechos do projeto.
+3. **Sinalize inconsistência** — não invente um padrão único onde o legado mistura.
+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 do CLI.
+
+## Antipatterns
+
+| AP | Antipattern | Por quê |
+|---|---|---|
+| AP-01 | Documentar o padrão "ideal" em vez do real | Código gerado sai fora do estilo do legado |
+| AP-02 | Forçar padrão único onde o legado é inconsistente | Esconde a realidade |
+| 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á no específico |
+| AP-05 | Ignorar os testes existentes | Nova feature nasce inconsistente |
+
+---
+
+Skill MIT — parte do DARE Method. DNA do projeto (brownfield). Pareia com o comando `dare dna`.