@dewtech/dare-cli 3.2.0 → 3.4.0

package/templates/ide/cursor/.cursor/commands/dare-docker-compose.md

@@ -1,18 +1,18 @@
-# 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).
-
-## Instruções para o Cursor Composer
-
-1. **Leia o Documento Blueprint:** Acesse o `DARE/BLUEPRINT.md` (se existir) para identificar as dependências do sistema (ex: PostgreSQL, Redis, Mailhog).
-2. **Leia o Contexto Global:** Leia o `.cursorrules` para confirmar as versões do banco de dados e outras ferramentas.
-3. **Leia a Skill Docker:** Leia `.cursor/rules/skill-docker.mdc` para aplicar boas práticas (Healthchecks, Redes, Volumes).
-4. **Gere o docker-compose.yml:**
-   - Crie um arquivo `docker-compose.yml` na raiz do projeto.
-   - **Serviço App:** Use o `build: .` (Dockerfile gerado). Exponha a porta correta. Defina variáveis de ambiente ou carregue do `.env`. Configure `depends_on` para DB/Cache.
-   - **Serviço Webserver (Laravel):** Se for Laravel, crie um serviço `nginx` dependente do `app` (PHP-FPM) e configure os volumes para compartilhar a pasta `/var/www/html`.
-   - **Serviço Banco de Dados:** Adicione o banco de dados (ex: `postgres:16-alpine` ou `mysql:8.0`). Defina variáveis de ambiente para usuário, senha e database (`POSTGRES_DB`, `POSTGRES_USER`). Adicione um `healthcheck` para testar a conexão (`pg_isready -U user`). Crie um volume nomeado para os dados (`db_data:/var/lib/postgresql/data`).
-   - **Serviço Cache (Opcional):** Se o projeto usar Redis, adicione o serviço `redis:7-alpine`.
-   - **Redes e Volumes:** Defina as redes customizadas (ex: `app-network`) e volumes (`db_data`, `redis_data`) no final do arquivo.
-5. **Mensagem Final:** Informe ao usuário: "Arquivo docker-compose.yml gerado com sucesso. Todos os serviços (App, [DB], [Cache]) foram configurados com healthchecks, volumes persistentes e redes isoladas. Revise as portas e variáveis de ambiente no .env antes de executar `docker-compose up -d`."
+# 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).
+
+## Instruções para o Cursor Composer
+
+1. **Leia o Documento Blueprint:** Acesse o `DARE/BLUEPRINT.md` (se existir) para identificar as dependências do sistema (ex: PostgreSQL, Redis, Mailhog).
+2. **Leia o Contexto Global:** Leia o `.cursorrules` para confirmar as versões do banco de dados e outras ferramentas.
+3. **Leia a Skill Docker:** Leia `.cursor/rules/skill-docker.mdc` para aplicar boas práticas (Healthchecks, Redes, Volumes).
+4. **Gere o docker-compose.yml:**
+   - Crie um arquivo `docker-compose.yml` na raiz do projeto.
+   - **Serviço App:** Use o `build: .` (Dockerfile gerado). Exponha a porta correta. Defina variáveis de ambiente ou carregue do `.env`. Configure `depends_on` para DB/Cache.
+   - **Serviço Webserver (Laravel):** Se for Laravel, crie um serviço `nginx` dependente do `app` (PHP-FPM) e configure os volumes para compartilhar a pasta `/var/www/html`.
+   - **Serviço Banco de Dados:** Adicione o banco de dados (ex: `postgres:16-alpine` ou `mysql:8.0`). Defina variáveis de ambiente para usuário, senha e database (`POSTGRES_DB`, `POSTGRES_USER`). Adicione um `healthcheck` para testar a conexão (`pg_isready -U user`). Crie um volume nomeado para os dados (`db_data:/var/lib/postgresql/data`).
+   - **Serviço Cache (Opcional):** Se o projeto usar Redis, adicione o serviço `redis:7-alpine`.
+   - **Redes e Volumes:** Defina as redes customizadas (ex: `app-network`) e volumes (`db_data`, `redis_data`) no final do arquivo.
+5. **Mensagem Final:** Informe ao usuário: "Arquivo docker-compose.yml gerado com sucesso. Todos os serviços (App, [DB], [Cache]) foram configurados com healthchecks, volumes persistentes e redes isoladas. Revise as portas e variáveis de ambiente no .env antes de executar `docker-compose up -d`."

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

@@ -1,17 +1,17 @@
-# 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.
-
-## Instruções para o Cursor Composer
-
-1. **Analise o Contexto:** Leia o arquivo `.cursorrules` e o `DARE/DESIGN.md` (se existir) para identificar a stack tecnológica principal (Linguagem, Framework, Versões).
-2. **Leia a Skill Docker:** Leia as regras em `.cursor/rules/skill-docker.mdc` para aplicar as melhores práticas de containerização.
-3. **Gere o Dockerfile:**
-   - Crie um Dockerfile na raiz do projeto (`./Dockerfile`).
-   - **Para PHP/Laravel:** Use multi-stage build. Instale extensões necessárias (pdo_mysql/pgsql, mbstring, exif, pcntl, bcmath, gd). Configure o `www-data` e ajuste permissões de `/var/www/html/storage` e `bootstrap/cache`.
-   - **Para Python:** Use `python:slim`. Crie um usuário não-root. Copie `requirements.txt` primeiro, instale dependências e depois copie o código.
-   - **Para Go:** Use multi-stage. Estágio 1: `golang:alpine` para build (`go build -o app`). Estágio 2: `alpine` ou `scratch` rodando apenas o binário.
-   - **Para Node/Vue:** Estágio 1: `node:alpine` para build (`npm run build`). Estágio 2: `nginx:alpine` para servir a pasta `dist`.
-4. **Gere o .dockerignore:** Crie um arquivo `.dockerignore` na raiz do projeto ignorando pastas desnecessárias (`node_modules`, `vendor`, `.git`, `.env`, `tests`, `DARE`).
-5. **Mensagem Final:** Informe ao usuário: "Dockerfile e .dockerignore gerados com sucesso e otimizados para a stack [NOME_DA_STACK]. Revise os arquivos gerados. Para criar a orquestração de serviços, execute `/generate-docker-compose`."
+# 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.
+
+## Instruções para o Cursor Composer
+
+1. **Analise o Contexto:** Leia o arquivo `.cursorrules` e o `DARE/DESIGN.md` (se existir) para identificar a stack tecnológica principal (Linguagem, Framework, Versões).
+2. **Leia a Skill Docker:** Leia as regras em `.cursor/rules/skill-docker.mdc` para aplicar as melhores práticas de containerização.
+3. **Gere o Dockerfile:**
+   - Crie um Dockerfile na raiz do projeto (`./Dockerfile`).
+   - **Para PHP/Laravel:** Use multi-stage build. Instale extensões necessárias (pdo_mysql/pgsql, mbstring, exif, pcntl, bcmath, gd). Configure o `www-data` e ajuste permissões de `/var/www/html/storage` e `bootstrap/cache`.
+   - **Para Python:** Use `python:slim`. Crie um usuário não-root. Copie `requirements.txt` primeiro, instale dependências e depois copie o código.
+   - **Para Go:** Use multi-stage. Estágio 1: `golang:alpine` para build (`go build -o app`). Estágio 2: `alpine` ou `scratch` rodando apenas o binário.
+   - **Para Node/Vue:** Estágio 1: `node:alpine` para build (`npm run build`). Estágio 2: `nginx:alpine` para servir a pasta `dist`.
+4. **Gere o .dockerignore:** Crie um arquivo `.dockerignore` na raiz do projeto ignorando pastas desnecessárias (`node_modules`, `vendor`, `.git`, `.env`, `tests`, `DARE`).
+5. **Mensagem Final:** Informe ao usuário: "Dockerfile e .dockerignore gerados com sucesso e otimizados para a stack [NOME_DA_STACK]. Revise os arquivos gerados. Para criar a orquestração de serviços, execute `/generate-docker-compose`."

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

@@ -1,19 +1,19 @@
-# 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.
-
-## Instruções para o Cursor Composer
-
-1. **Identifique a Tarefa:** Leia o `$ARGUMENTS` (ID da tarefa ou caminho do arquivo, ex: `task-001` ou `DARE/EXECUTION/task-001.md`).
-2. **Leia a Especificação da Tarefa:** Abra e leia a especificação detalhada da tarefa em `DARE/EXECUTION/[id].md`.
-3. **Analise o Contexto Global:** Leia o arquivo `.cursorrules` (ou equivalente) e a arquitetura geral em `DARE/BLUEPRINT.md` para garantir que o código será gerado dentro dos padrões do projeto.
-4. **Implemente o Código:**
-   - Execute passo a passo as instruções da seção "ESPECIFICAÇÃO DE IMPLEMENTAÇÃO".
-   - Crie ou modifique os arquivos necessários.
-   - Siga rigorosamente os padrões de código, tratamento de erros e convenções definidos nas regras globais e exemplos fornecidos.
-5. **O Loop de Validação (Ralph Loop):**
-   - Após a implementação, execute OBRIGATORIAMENTE os comandos definidos na seção "CRITÉRIOS DE SUCESSO (VALIDATION GATES)".
-   - Exemplo: `php artisan test --filter=NomeDoTeste` ou `./vendor/bin/pint`.
-   - Se algum comando falhar, LEIA O ERRO, CORRIJA O CÓDIGO e RODE O COMANDO NOVAMENTE até que todos passem com sucesso.
-6. **Mensagem Final:** Após o sucesso dos testes, atualize o status da tarefa no arquivo `DARE/TASKS.md` (marque com um `[x]`) e informe ao usuário: "Tarefa [ID] implementada e validada com sucesso. Os testes passaram."
+# 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.
+
+## Instruções para o Cursor Composer
+
+1. **Identifique a Tarefa:** Leia o `$ARGUMENTS` (ID da tarefa ou caminho do arquivo, ex: `task-001` ou `DARE/EXECUTION/task-001.md`).
+2. **Leia a Especificação da Tarefa:** Abra e leia a especificação detalhada da tarefa em `DARE/EXECUTION/[id].md`.
+3. **Analise o Contexto Global:** Leia o arquivo `.cursorrules` (ou equivalente) e a arquitetura geral em `DARE/BLUEPRINT.md` para garantir que o código será gerado dentro dos padrões do projeto.
+4. **Implemente o Código:**
+   - Execute passo a passo as instruções da seção "ESPECIFICAÇÃO DE IMPLEMENTAÇÃO".
+   - Crie ou modifique os arquivos necessários.
+   - Siga rigorosamente os padrões de código, tratamento de erros e convenções definidos nas regras globais e exemplos fornecidos.
+5. **O Loop de Validação (Ralph Loop):**
+   - Após a implementação, execute OBRIGATORIAMENTE os comandos definidos na seção "CRITÉRIOS DE SUCESSO (VALIDATION GATES)".
+   - Exemplo: `php artisan test --filter=NomeDoTeste` ou `./vendor/bin/pint`.
+   - Se algum comando falhar, LEIA O ERRO, CORRIJA O CÓDIGO e RODE O COMANDO NOVAMENTE até que todos passem com sucesso.
+6. **Mensagem Final:** Após o sucesso dos testes, atualize o status da tarefa no arquivo `DARE/TASKS.md` (marque com um `[x]`) e informe ao usuário: "Tarefa [ID] implementada e validada com sucesso. Os testes passaram."

package/templates/ide/cursor/.cursor/commands/dare-feature-design.md

@@ -1,64 +1,64 @@
----
-description: Analisa o projeto existente e gera um Design DARE focado na adicao de uma nova feature. Use quando precisar adicionar uma funcionalidade nova sem reescrever o Design de todo o sistema.
-globs: *
----
-
-# Generate Feature Design
-
-## Objetivo
-Analisar a base de código atual e gerar um documento de Design (`DARE/DESIGN-Feature-[Nome].md`) focado especificamente na **adição de uma nova feature**, respeitando a arquitetura existente do projeto.
-
-## Contexto
-Este comando é para **projetos legados** onde você quer adicionar uma funcionalidade nova. O foco aqui é **expansão**: novos endpoints, novas tabelas, novas integrações.
-
-## Passos que a IA deve seguir:
-
-1. **Análise de Contexto:**
-   - Identificar a stack e arquitetura (MVC, Hexagonal, etc.)
-   - Identificar padrões de projeto existentes para seguir o mesmo estilo
-   - Identificar banco de dados e dependências chave
-
-2. **Entendimento da Feature:**
-   - Qual é o objetivo da nova funcionalidade?
-   - Como ela se conecta com o que já existe?
-
-3. **Geração do Documento:**
-   - Criar o arquivo `DARE/DESIGN-Feature-[Nome-da-Feature].md`
-
-## Estrutura do Documento Gerado:
-
-```markdown
-# Feature Design: [Nome da Feature]
-
-## Contexto no Projeto
-Como esta feature se encaixa no ecossistema atual.
-
-## Objetivos da Feature
-- [Objetivo 1]
-- [Objetivo 2]
-
-## Análise de Impacto (O que muda)
-- **Novos Arquivos:** [Controllers, Models, etc. a serem criados]
-- **Arquivos Modificados:** [Arquivos existentes que sofrerão alteração]
-- **Banco de Dados:** [Novas tabelas ou colunas]
-
-## Requisitos Técnicos
-### Funcionalidades
-- [Funcionalidade 1]
-- [Funcionalidade 2]
-
-### Segurança (OWASP)
-- [Validações e controles de acesso específicos para esta feature]
-
-## Restrições
-- O que NÃO deve ser alterado no sistema legado.
-
-## Próximas Etapas
-1. Revisar e aprovar este Design
-2. Executar `/generate-blueprint DARE/DESIGN-Feature-[Nome].md`
-```
-
-## Regras de Ouro:
-- **Siga o Padrão Local:** Se o projeto usa um padrão específico, a feature deve segui-lo.
-- **Isolamento:** Tente isolar o código novo do legado.
-- **Segurança:** Aplique regras OWASP na nova feature.
+---
+description: Analisa o projeto existente e gera um Design DARE focado na adicao de uma nova feature. Use quando precisar adicionar uma funcionalidade nova sem reescrever o Design de todo o sistema.
+globs: *
+---
+
+# Generate Feature Design
+
+## Objetivo
+Analisar a base de código atual e gerar um documento de Design (`DARE/DESIGN-Feature-[Nome].md`) focado especificamente na **adição de uma nova feature**, respeitando a arquitetura existente do projeto.
+
+## Contexto
+Este comando é para **projetos legados** onde você quer adicionar uma funcionalidade nova. O foco aqui é **expansão**: novos endpoints, novas tabelas, novas integrações.
+
+## Passos que a IA deve seguir:
+
+1. **Análise de Contexto:**
+   - Identificar a stack e arquitetura (MVC, Hexagonal, etc.)
+   - Identificar padrões de projeto existentes para seguir o mesmo estilo
+   - Identificar banco de dados e dependências chave
+
+2. **Entendimento da Feature:**
+   - Qual é o objetivo da nova funcionalidade?
+   - Como ela se conecta com o que já existe?
+
+3. **Geração do Documento:**
+   - Criar o arquivo `DARE/DESIGN-Feature-[Nome-da-Feature].md`
+
+## Estrutura do Documento Gerado:
+
+```markdown
+# Feature Design: [Nome da Feature]
+
+## Contexto no Projeto
+Como esta feature se encaixa no ecossistema atual.
+
+## Objetivos da Feature
+- [Objetivo 1]
+- [Objetivo 2]
+
+## Análise de Impacto (O que muda)
+- **Novos Arquivos:** [Controllers, Models, etc. a serem criados]
+- **Arquivos Modificados:** [Arquivos existentes que sofrerão alteração]
+- **Banco de Dados:** [Novas tabelas ou colunas]
+
+## Requisitos Técnicos
+### Funcionalidades
+- [Funcionalidade 1]
+- [Funcionalidade 2]
+
+### Segurança (OWASP)
+- [Validações e controles de acesso específicos para esta feature]
+
+## Restrições
+- O que NÃO deve ser alterado no sistema legado.
+
+## Próximas Etapas
+1. Revisar e aprovar este Design
+2. Executar `/generate-blueprint DARE/DESIGN-Feature-[Nome].md`
+```
+
+## Regras de Ouro:
+- **Siga o Padrão Local:** Se o projeto usa um padrão específico, a feature deve segui-lo.
+- **Isolamento:** Tente isolar o código novo do legado.
+- **Segurança:** Aplique regras OWASP na nova feature.

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

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

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

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

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