@dewtech/dare-cli 0.3.5 → 0.3.7

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

@@ -0,0 +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.

package/templates/ide/cursor/.cursor/commands/generate-tasks.md

@@ -0,0 +1,20 @@
+# Comando: /generate-tasks
+
+## Descrição
+Este comando avança o Método DARE lendo o Blueprint aprovado e gerando as tarefas atômicas isoladas para execução.
+
+## Instruções para o Cursor Composer
+
+1. **Leia o Documento Blueprint:** Acesse e leia o arquivo `$ARGUMENTS` (geralmente `DARE/BLUEPRINT.md`) que contém a arquitetura completa.
+2. **Leia os Templates:** Utilize a estrutura definida em `templates/TASKS-template.md` e `templates/TASK-SPEC-template.md`.
+3. **Analise o Contexto Global:** Leia o arquivo `.cursorrules` (ou equivalente) para garantir que as instruções de código sigam as convenções do projeto.
+4. **Desdobre as Fases em Tarefas Atômicas:**
+   - Para cada Fase definida no Blueprint, crie tarefas granulares e executáveis.
+   - Uma tarefa deve ser pequena o suficiente para ser concluída em um único prompt do Composer.
+   - **Tarefas de Segurança:** Garanta que requisitos de segurança (ex: Middlewares, Validação de FormRequests, Criptografia) tenham tarefas específicas ou estejam explicitamente incluídos nas tarefas relevantes.
+   - Exemplo: "Fase 2: Autenticação" vira "Task 003: Migration de Users", "Task 004: AuthController (com Rate Limit e Bcrypt)", etc.
+5. **Gere os Arquivos de Tarefas:**
+   - **TASKS.md:** Crie o arquivo `DARE/TASKS.md` com a visão geral de todas as tarefas e suas dependências.
+   - **Especificações Isoladas:** Para CADA tarefa criada, crie um arquivo em `DARE/EXECUTION/task-[id].md` seguindo o template `TASK-SPEC-template.md`.
+   - Preencha as instruções de implementação detalhadas para cada arquivo de task isolada, incluindo os Validation Gates apropriados para a stack (ex: PHPUnit para Laravel, Pytest para Python).
+6. **Mensagem Final:** Informe ao usuário: "Documento TASKS.md e especificações isoladas geradas em DARE/EXECUTION/ com sucesso. Revise as tarefas. Para iniciar a implementação, execute `/execute-task task-001`."

package/templates/ide/cursor/.cursor/commands/telemetry-report.md

@@ -0,0 +1,42 @@
+# Comando: /telemetry-report
+
+## Descrição
+Este comando gera um relatório detalhado de consumo de tokens e modelos utilizados em todas as etapas do projeto DARE, incluindo análise de custos e recomendações de otimização.
+
+## Instruções para o Cursor Composer
+
+1. **Verifique o Arquivo de Telemetria:** Procure pelo arquivo `DARE/TELEMETRY.md`. Se não existir, crie um novo.
+
+2. **Leia a Skill de Telemetria:** Consulte `.cursor/rules/skill-telemetry.mdc` para entender a estrutura esperada.
+
+3. **Analise os Dados Disponíveis:**
+   - Se o arquivo `DARE/TELEMETRY.md` já existe, leia-o e procure por lacunas de dados.
+   - Se não existe, crie o arquivo com a estrutura base.
+
+4. **Gere o Relatório Completo:**
+   - **Resumo Executivo:** Total de tokens gastos, custo estimado, período de execução.
+   - **Detalhamento por Etapa:** Tabela mostrando Design, Blueprint, Tasks e Execute com tokens e custos.
+   - **Análise de Modelos:** Qual modelo foi mais utilizado e por quê.
+   - **Análise de Custos:** Gráfico/tabela mostrando a distribuição de custos por etapa.
+   - **Recomendações:** Sugestões de otimização (ex: usar modelos mais rápidos para tarefas simples).
+
+5. **Salve o Relatório:**
+   - Atualize o arquivo `DARE/TELEMETRY.md` com o relatório completo.
+   - Se houver dados faltantes, indique com `[PENDENTE]` e peça ao usuário para preencher.
+
+6. **Mensagem Final:** Informe ao usuário:
+   ```
+   Relatório de Telemetria gerado com sucesso!
+   
+   📊 Resumo:
+   - Tokens Totais: [X]
+   - Custo Estimado: $[Y]
+   - Modelos Utilizados: [Lista]
+   - Etapa Mais Cara: [Etapa]
+   
+   💡 Recomendações:
+   - [Recomendação 1]
+   - [Recomendação 2]
+   
+   📁 Relatório salvo em: DARE/TELEMETRY.md
+   ```

package/templates/ide/cursor/.cursor/rules/skill-bugfix-design.mdc

@@ -0,0 +1,51 @@
+---
+description: Diagnostica bugs em projetos existentes e planeja correcoes cirurgicas usando o Metodo DARE. Ensina a IA a encontrar a causa raiz, avaliar riscos de regressao e planejar a correcao minima necessaria.
+globs: *
+---
+
+# Skill: Bugfix Design para Projetos Existentes
+
+## Objetivo
+Esta skill ensina você (a IA) a diagnosticar um bug relatado em um projeto existente, encontrar a **causa raiz** e planejar uma correção cirúrgica que resolva o problema sem introduzir novos erros.
+
+## Quando Usar
+- Quando o usuário relata um bug ou comportamento inesperado no sistema.
+- Quando o comando `/generate-bugfix-design` for invocado.
+
+## Como Diagnosticar o Bug
+
+O diagnóstico é a etapa mais crítica. Uma correção sem diagnóstico adequado apenas esconde o sintoma.
+
+**Entenda o Relato Completo:** Antes de analisar o código, entenda claramente qual é o comportamento atual vs o esperado. Se o usuário não forneceu um stack trace ou log, pergunte por ele.
+
+**Localize a Área Afetada:** Identifique os controllers, services, queries ou componentes que estão envolvidos no fluxo que apresenta o erro.
+
+**Encontre a Causa Raiz:** Não trate o sintoma. Descubra *por que* o erro acontece. As causas mais comuns são:
+
+| Tipo de Causa | Exemplos |
+|---------------|---------|
+| **Lógica de Negócio** | Condição incorreta, cálculo errado |
+| **Banco de Dados** | Query N+1, deadlock, dados inconsistentes |
+| **Validação** | Input não validado, tipo incorreto |
+| **Concorrência** | Race condition, falta de lock |
+| **Segurança** | Injeção de SQL, XSS, IDOR |
+
+## Como Gerar o Design do Bugfix
+
+O documento `DARE/DESIGN-Bugfix-[Nome].md` deve ser **cirúrgico e preciso**. Ele descreve o problema, a causa raiz e o plano de correção mínimo necessário.
+
+| Seção | Conteúdo |
+|-------|----------|
+| **Descrição** | Comportamento atual vs esperado |
+| **Causa Raiz** | Explicação técnica do porquê ocorre |
+| **Arquivos a Modificar** | Lista exata de arquivos que serão alterados |
+| **Riscos** | O que mais pode quebrar com a correção |
+| **Plano de Ação** | Passos cirúrgicos da correção |
+| **Testes** | Validation Gates + Testes de Regressão |
+
+## Regras de Ouro
+
+1. **Seja Cirúrgico:** A correção deve ser o menor código possível para resolver o problema sem efeitos colaterais.
+2. **Causa Raiz:** Nunca trate apenas o sintoma. Se a causa raiz não for corrigida, o bug voltará.
+3. **Evite Regressão:** Sempre mapeie os riscos da correção e planeje testes de regressão para eles.
+4. **Adicione Testes:** Se o bug ocorreu, é porque faltava um teste. A correção DEVE incluir um novo teste que falharia com o código antigo e passa com o novo código.

package/templates/ide/cursor/.cursor/rules/skill-docker.mdc

@@ -0,0 +1,33 @@
+---
+description: Padrões Globais para Containerização com Docker e Docker Compose
+globs: Dockerfile*, docker-compose*.yml, .dockerignore
+---
+# Regras Globais do Projeto (Docker e Containerização)
+
+Você é um engenheiro DevOps Especialista focado em segurança, performance e melhores práticas para criação de containers Docker e orquestração com Docker Compose.
+
+## Padrões para Dockerfile
+- **Multi-stage Builds:** Sempre utilize multi-stage builds para separar o ambiente de build (onde compiladores e dependências de dev residem) do ambiente de runtime (produção). Isso reduz drasticamente o tamanho final da imagem.
+- **Imagens Base:** Utilize imagens base oficiais e preferencialmente as versões Alpine ou distroless para reduzir a superfície de ataque e o tamanho. Especifique tags exatas (ex: `php:8.3-fpm-alpine` em vez de `php:latest`).
+- **Usuário Não-Root:** Nunca execute a aplicação como usuário `root` no container final. Crie um usuário dedicado (ex: `appuser` ou use o `www-data` no caso do PHP) e ajuste as permissões de pastas.
+- **Cache de Camadas:** Ordene os comandos no Dockerfile do menos mutável para o mais mutável. Copie arquivos de dependência (como `composer.json`, `package.json`, `requirements.txt`, `go.mod`) e instale dependências ANTES de copiar o código fonte da aplicação.
+- **Limpeza:** Limpe os caches de gerenciadores de pacotes (`apt-get clean`, `apk cache clean`, `rm -rf /var/lib/apt/lists/*`) na mesma camada `RUN` em que foram instalados.
+- **ENTRYPOINT vs CMD:** Use `ENTRYPOINT` para comandos fixos do container e `CMD` para argumentos padrão que podem ser sobrescritos.
+
+## Padrões para Docker Compose
+- **Versão:** Utilize a especificação Compose atual (não use `version: '3'` pois está depreciado).
+- **Serviços Isolados:** Separe a aplicação do banco de dados, cache, e webserver (ex: Nginx e PHP-FPM em containers separados).
+- **Volumes Nomeados:** Use volumes nomeados para persistência de dados (banco de dados, uploads, logs).
+- **Redes Customizadas:** Defina redes customizadas (`networks`) para isolar a comunicação entre os serviços.
+- **Variáveis de Ambiente:** Utilize arquivos `.env` para passar variáveis de ambiente, não hardcode senhas ou chaves no `docker-compose.yml`.
+- **Healthchecks:** Adicione `healthcheck` nos serviços de banco de dados e cache para garantir que a aplicação só inicie quando as dependências estiverem prontas (`depends_on` com `condition: service_healthy`).
+
+## Especificidades por Stack
+- **Laravel/PHP:** Requer um container para PHP-FPM (com extensões necessárias instaladas via `install-php-extensions` ou `docker-php-ext-install`) e outro para o Webserver (Nginx/Apache). O diretório de trabalho padrão deve ser `/var/www/html`. Ajuste permissões para as pastas `storage` e `bootstrap/cache`.
+- **Python (FastAPI/Flask):** Use `python:3.11-slim`. Não execute como root. Instale dependências sem cache (`pip install --no-cache-dir`). Exponha a porta correta (geralmente 8000 ou 5000).
+- **Go:** O estágio de build deve usar `golang:1.22-alpine` para compilar um binário estático. O estágio final pode ser `scratch` (imagem vazia) ou `alpine` contendo apenas o binário compilado.
+- **Vue.js/Frontend:** O estágio de build usa Node.js para gerar os arquivos estáticos (`npm run build`). O estágio final usa Nginx (`nginx:alpine`) para servir a pasta `dist`.
+
+## Segurança
+- Não copie arquivos desnecessários. Crie sempre um `.dockerignore` bem configurado (ignorando `.git`, `node_modules`, `vendor`, `.env`).
+- Não exponha portas de banco de dados (ex: 3306, 5432) para o host (máquina local) em ambiente de produção, apenas na rede interna do Docker.

package/templates/ide/cursor/.cursor/rules/skill-feature-design.mdc

@@ -0,0 +1,43 @@
+---
+description: Analisa projetos existentes para planejar a adicao de novas features usando o Metodo DARE. Ensina a IA a respeitar a arquitetura legada, analisar impacto e focar apenas no escopo da nova funcionalidade.
+globs: *
+---
+
+# Skill: Feature Design para Projetos Existentes
+
+## Objetivo
+Esta skill ensina você (a IA) a analisar o contexto de um projeto que já existe e planejar a inserção de uma **nova feature** de forma segura, isolada e respeitando os padrões já estabelecidos.
+
+## Quando Usar
+- Quando o usuário pede para adicionar uma funcionalidade nova em um projeto existente.
+- Quando o comando `/generate-feature-design` for invocado.
+
+## Como Analisar o Projeto Existente
+
+O primeiro passo é sempre entender o que já existe antes de propor qualquer coisa nova.
+
+**Identifique a Stack e Arquitetura:** Leia os arquivos de configuração do projeto (`composer.json`, `package.json`, etc.) para entender o framework, versão e padrão arquitetural (MVC, Hexagonal, CQRS). Se o projeto usa um padrão específico, a nova feature **deve seguir esse padrão**.
+
+**Analise o Banco de Dados:** Leia as migrations ou esquemas existentes para entender as tabelas relacionadas à feature solicitada. Identifique se serão necessárias novas tabelas ou apenas novas colunas.
+
+**Verifique Dependências Chave:** Entenda quais bibliotecas de terceiros já estão em uso (ex: Sanctum para auth, Spatie para permissões) e que podem ser aproveitadas pela nova feature.
+
+## Como Gerar o Design da Feature
+
+O documento `DARE/DESIGN-Feature-[Nome].md` deve ser **focado e conciso**. Ele não descreve o sistema inteiro, apenas o impacto da nova feature.
+
+| Seção | Conteúdo |
+|-------|----------|
+| **Contexto** | Como a feature se conecta ao que já existe |
+| **Novos Arquivos** | Controllers, Models, Services a serem criados |
+| **Arquivos Modificados** | O que muda no código legado |
+| **Banco de Dados** | Novas tabelas ou colunas |
+| **Segurança** | Proteções OWASP específicas para a feature |
+| **Restrições** | O que não pode ser tocado |
+
+## Regras de Ouro
+
+1. **Siga o Padrão Local:** Se o projeto usa um padrão antigo ou específico, adapte a feature a ele, a menos que o usuário solicite refatoração explícita.
+2. **Isolamento:** Mantenha o impacto da feature o mais isolado possível para minimizar o risco de quebrar o sistema legado.
+3. **Testes Nascem com a Feature:** Se o projeto não tem testes, a nova feature DEVE nascer com testes isolados (Validation Gates do Ralph Loop).
+4. **Segurança Inegociável:** Mesmo que o código legado seja inseguro, a nova feature DEVE aplicar regras OWASP.

package/templates/ide/cursor/.cursor/rules/skill-laravel-api.mdc

@@ -0,0 +1,44 @@
+---
+description: Padrões Globais para Projetos Laravel API (Context Engineering)
+globs: *.php, *.json, *.yml, *.yaml
+---
+# Regras Globais do Projeto (Laravel API)
+
+Você é um desenvolvedor Sênior especializado em PHP 8.x e Laravel 11.x focado em APIs RESTful.
+Seu objetivo é escrever código limpo, legível, performático e fortemente tipado.
+
+## Stack Tecnológico Principal
+- **Linguagem:** PHP 8.3 (Strict Types habilitado em todos os arquivos `declare(strict_types=1);`)
+- **Framework:** Laravel 11.x (Modo API)
+- **Banco de Dados:** PostgreSQL ou MySQL
+- **Testes:** PHPUnit / Pest
+- **Análise Estática:** PHPStan / Larastan
+- **Formatação:** Laravel Pint
+
+## Convenções de Nomenclatura e Padrões de Arquitetura
+- **Controllers:** Devem focar apenas em receber a request e retornar a response. Nomenclatura: `UserApiController`, `ProductController`.
+- **FormRequests:** Toda validação de entrada deve ser feita em FormRequests (ex: `StoreUserRequest`, `UpdateProductRequest`). NUNCA valide diretamente no Controller.
+- **Services:** Lógica de negócios complexa deve ser extraída para classes Service (ex: `UserRegistrationService`).
+- **Resources/Transformers:** Sempre use `JsonResource` para formatar a saída da API (ex: `UserResource`, `ProductCollection`). Não retorne Models diretamente.
+- **Models:** Defina `$fillable` ou `$guarded`, os `casts` corretos e os relacionamentos de forma explícita.
+- **Traits:** Use traits para comportamentos reutilizáveis (ex: `ApiResponseTrait` para padronizar respostas JSON).
+
+## Padrões de Código e Tratamento de Erros
+- Use tipagem estrita (Type Hinting) em parâmetros e retornos de todas as funções/métodos.
+- Evite `null` quando possível; prefira exceções bem definidas ou retornos tipados.
+- **Tratamento de Erros:** 
+  - Use exceções customizadas para erros de negócio (ex: `InsufficientBalanceException`).
+  - Capture exceções no `bootstrap/app.php` (Laravel 11) ou use um Handler global para retornar respostas JSON consistentes (`{ "error": "Message", "code": 400 }`).
+- **Transações de Banco:** Sempre use `DB::transaction()` ao inserir/atualizar dados em múltiplas tabelas.
+
+## Documentação
+- Adicione PHPDoc blocks apenas quando a tipagem nativa do PHP não for suficiente (ex: arrays de objetos `/** @var User[] $users */`).
+- Mantenha comentários claros explicando o *porquê* de uma lógica complexa, não o *o quê*.
+
+## Testes
+- Escreva testes de Feature para todos os endpoints da API verificando:
+  - Respostas de sucesso (200/201)
+  - Erros de validação (422)
+  - Falhas de autenticação/autorização (401/403)
+  - Not Found (404)
+- Use Factories e Seeders para popular o banco de dados nos testes.

package/templates/ide/cursor/.cursor/rules/skill-security.mdc

@@ -0,0 +1,57 @@
+---
+description: Diretrizes de Segurança baseadas no OWASP Top 10 para todas as fases do DARE
+globs: *.md, *.php, *.py, *.go, *.vue, *.js, *.ts
+---
+# Diretrizes de Segurança (OWASP Top 10)
+
+Você é um Especialista em Segurança da Informação (AppSec). Seu objetivo é garantir que todas as fases do projeto (Design, Blueprint, Tasks e Execução de Código) sigam rigorosamente as práticas do OWASP Top 10.
+
+## Aplicação nas Fases do DARE
+
+### Fase 1: Design (`/generate-design`)
+- **Requisitos Não-Funcionais:** Sempre inclua requisitos de segurança explícitos (ex: Rate Limiting, HTTPS obrigatório, senhas fortes).
+- **Restrições:** Identifique possíveis vetores de ataque na ideia inicial e adicione restrições para mitigá-los.
+
+### Fase 2: Architect (`/generate-blueprint`)
+- **Autenticação/Autorização:** Defina claramente como os tokens (JWT/Sanctum) serão armazenados e validados. Nunca permita endpoints sensíveis sem proteção.
+- **Modelo de Dados:** Garanta que dados sensíveis (senhas, tokens, PII) sejam hashados ou encriptados no banco de dados.
+- **Endpoints:** Adicione middlewares de segurança (ex: CORS, Rate Limit, XSS Protection) na tabela de endpoints.
+
+### Fase 3: Tasks (`/generate-tasks`)
+- **Validation Gates:** Inclua testes de segurança nas tarefas (ex: testar se um usuário sem permissão recebe 403, testar injeção de SQL nas buscas).
+- **Tarefas de Segurança:** Crie tarefas específicas para configurar segurança (ex: Configurar Headers de Segurança, Implementar Rate Limiting).
+
+### Fase 4: Execute (`/execute-task`) - Implementação de Código
+Sempre aplique as seguintes proteções ao escrever código:
+
+1. **A01: Quebra de Controle de Acesso (Broken Access Control)**
+   - Sempre verifique se o usuário logado tem permissão para acessar/modificar o recurso solicitado (ex: `User::can('update', $post)` ou Policies no Laravel).
+   - Implemente o princípio do menor privilégio.
+
+2. **A02: Falhas Criptográficas (Cryptographic Failures)**
+   - Nunca armazene senhas em texto plano. Use Bcrypt ou Argon2.
+   - Não envie dados sensíveis (senhas, tokens) em respostas da API.
+
+3. **A03: Injeção (Injection)**
+   - **SQL Injection:** Sempre use ORMs (Eloquent, SQLAlchemy, GORM) ou Prepared Statements. NUNCA concatene strings em queries SQL.
+   - **XSS:** Sempre escape a saída de dados no frontend (ex: o Vue já faz isso com `{{ }}`, mas evite `v-html` com dados de usuários).
+   - **Command Injection:** Valide rigorosamente qualquer entrada que seja passada para o sistema operacional.
+
+4. **A04: Design Inseguro (Insecure Design)**
+   - Valide todas as entradas do usuário no lado do servidor (FormRequests no Laravel, Pydantic no FastAPI).
+   - Use listas de permissão (allowlists) em vez de listas de bloqueio (blocklists) para validação.
+
+5. **A05: Configuração Insegura (Security Misconfiguration)**
+   - Não exponha stack traces ou erros detalhados em produção (retorne mensagens genéricas de erro 500).
+   - Desabilite métodos HTTP desnecessários.
+
+6. **A07: Falhas de Identificação e Autenticação (Identification and Authentication Failures)**
+   - Implemente proteção contra força bruta (Rate Limiting) em endpoints de login.
+   - Invalide tokens de sessão no logout.
+
+7. **A08: Falhas na Integridade de Software e Dados (Software and Data Integrity Failures)**
+   - Não confie em dados enviados pelo cliente sem validação.
+   - Assine digitalmente JWTs com chaves fortes e secretas.
+
+8. **A10: Falsificação de Solicitação do Lado do Servidor (SSRF)**
+   - Se a aplicação fizer requisições HTTP para URLs fornecidas pelo usuário, valide a URL e bloqueie acessos à rede interna (ex: `127.0.0.1`, `localhost`, metadados da AWS).

package/templates/ide/cursor/.cursor/rules/skill-telemetry.mdc

@@ -0,0 +1,156 @@
+---
+description: Rastreamento de Tokens e Modelos do Cursor utilizados em cada etapa do DARE
+globs: DARE/*.md, DARE/EXECUTION/*.md
+---
+# Rastreamento de Telemetria (Cursor - Tokens e Modelos)
+
+Você é um especialista em monitoramento e observabilidade. Seu objetivo é rastrear e registrar o consumo de tokens e modelos de IA em cada etapa do Método DARE para fins de auditoria, monitoramento de performance e análise de uso. O Cursor é a IA utilizada (por compliance), então registre qual modelo do Cursor foi usado (GPT-4, Claude, Gemini, etc).
+
+## Modelos Disponíveis no Cursor
+
+O Cursor suporta múltiplos modelos de IA. Registre qual foi utilizado em cada etapa:
+
+| Modelo | Provedor | Características | Melhor Para |
+|--------|----------|-----------------|------------|
+| GPT-4 Turbo | OpenAI | Rápido e versátil | Tarefas gerais, código |
+| Claude 3.5 Sonnet | Anthropic | Análise profunda | Análise complexa, segurança |
+| Gemini 2.0 Flash | Google | Ultra rápido | Tarefas simples, processamento rápido |
+| Modelos Locais | Customizados | Privacidade total | Dados sensíveis |
+
+## Estrutura de Rastreamento
+
+Cada etapa do DARE deve registrar as seguintes informações em um arquivo de telemetria:
+
+### Arquivo de Telemetria: `DARE/TELEMETRY.md`
+
+Este arquivo centraliza todas as métricas de consumo. Ele deve ser atualizado ao final de cada comando executado.
+
+```markdown
+# Telemetria do Projeto: [Nome do Projeto]
+
+## Resumo Executivo
+- **Projeto:** [Nome]
+- **Data de Início:** [Data]
+- **Tokens Totais Processados:** [Número] (monitoramento de uso)
+- **IA Utilizada:** Cursor (por compliance)
+- **Modelos do Cursor Utilizados:** [Lista de modelos]
+- **Tempo Total de Execução:** [Tempo]
+
+## Detalhamento por Etapa
+
+### 1. Design (`/generate-design`)
+- **Data/Hora:** [Timestamp]
+- **Modelo do Cursor:** GPT-4 Turbo (ou Claude, Gemini)
+- **Tokens Estimados:** 7,390
+- **Tempo de Execução:** 45 segundos
+- **Comando Executado:** `/generate-design "Criar API de autenticação"`
+- **Observações:** [Qualidade da resposta, ajustes necessários, etc]
+
+### 2. Blueprint (`/generate-blueprint`)
+- **Data/Hora:** [Timestamp]
+- **Modelo do Cursor:** GPT-4 Turbo (ou Claude, Gemini)
+- **Tokens Estimados:** 21,373
+- **Tempo de Execução:** 2 minutos
+- **Arquivo Processado:** DARE/DESIGN.md
+- **Observações:** [Qualidade da arquitetura, ajustes necessários, etc]
+
+### 3. Tasks (`/generate-tasks`)
+- **Data/Hora:** [Timestamp]
+- **Modelo do Cursor:** GPT-4 Turbo (ou Claude, Gemini)
+- **Tokens Estimados:** 33,912
+- **Tempo de Execução:** 3 minutos 20 segundos
+- **Arquivo Processado:** DARE/BLUEPRINT.md
+- **Tasks Geradas:** 12
+- **Observações:** [Qualidade das tasks, clareza das especificações, etc]
+
+### 4. Execute Tasks (`/execute-task`)
+- **Task 001: Migration de Users**
+  - Data/Hora: [Timestamp]
+  - Modelo do Cursor: GPT-4 Turbo (ou Claude, Gemini)
+  - Tokens Estimados: 7,801
+  - Tempo: 1 minuto 30 segundos
+  - Tentativas (Ralph Loop): 1
+  - Status: ✓ Sucesso
+
+- **Task 002: AuthController**
+  - Data/Hora: [Timestamp]
+  - Modelo do Cursor: GPT-4 Turbo (ou Claude, Gemini)
+  - Tokens Estimados: 11,357
+  - Tempo: 2 minutos
+  - Tentativas (Ralph Loop): 2
+  - Status: ✓ Sucesso
+
+[... mais tasks ...]
+
+## Análise de Tokens Processados
+
+| Etapa | Tokens Estimados | % do Total | Tempo Total |
+|-------|------------------|-----------|-------------|
+| Design | 7,390 | 5% | 45 seg |
+| Blueprint | 21,373 | 15% | 2 min |
+| Tasks | 33,912 | 24% | 3 min 20 seg |
+| Execute (12 tasks) | 85,234 | 56% | 25 min |
+| **TOTAL** | **147,909** | **100%** | **~31 min** |
+
+## Modelos do Cursor Utilizados
+
+- **GPT-4 Turbo:** 147,909 tokens (100%)
+- **Claude 3.5 Sonnet:** 0 tokens (0%)
+- **Gemini 2.0 Flash:** 0 tokens (0%)
+```
+
+## Instruções para Rastreamento Manual
+
+Após executar cada comando DARE, adicione uma entrada em `DARE/TELEMETRY.md`:
+
+1. **Após `/generate-design`:**
+   - Procure na barra de status do Cursor pelo modelo utilizado
+   - Anote o tempo de execução
+   - Adicione uma entrada na seção "Design"
+
+2. **Após `/generate-blueprint`:**
+   - Repita o processo acima
+   - Adicione uma entrada na seção "Blueprint"
+
+3. **Após `/generate-tasks`:**
+   - Adicione uma entrada na seção "Tasks"
+   - Inclua o número de tasks geradas
+
+4. **Após cada `/execute-task`:**
+   - Adicione uma entrada na seção "Execute Tasks"
+   - Inclua o status (Sucesso/Falha)
+   - Se falhou, anote quantas tentativas foram necessárias (Ralph Loop)
+
+## Capturando Informações do Cursor
+
+O Cursor exibe informações sobre o modelo e tokens utilizados. Procure por:
+
+**Na barra de status (canto inferior direito):**
+- Ícone do modelo (ex: GPT-4, Claude, Gemini)
+- Informações de tempo de resposta
+
+**No histórico de conversa:**
+- Clique no ícone de informações da resposta
+- Veja detalhes do modelo utilizado
+- Tempo de processamento
+
+**Exemplo de informação exibida:**
+```
+Model: GPT-4 Turbo
+Time: 2.3s
+Tokens: ~12,345 (estimado)
+```
+
+Copie estas informações e adicione ao `DARE/TELEMETRY.md`.
+
+## Otimizações Recomendadas
+
+1. **Escolher o Modelo Certo:** Use GPT-4 para tarefas complexas, Claude para tarefas de análise, Gemini para processamento rápido.
+
+2. **Reutilizar Contexto:** Se você rodar `/execute-task` múltiplas vezes na mesma sessão do Composer, o contexto é reutilizado, economizando processamento.
+
+3. **Revisar Antes de Executar:** Revisar o Blueprint antes de gerar tasks economiza tokens desnecessários.
+
+4. **Agrupar Tasks:** Execute tasks relacionadas na mesma conversa do Composer para reutilizar contexto.
+
+5. **Monitorar Tentativas (Ralph Loop):** Se uma task requer muitas tentativas, pode indicar que a especificação precisa ser mais clara.

package/templates/ide/cursor/templates/BLUEPRINT-template.md

@@ -0,0 +1,53 @@
+# BLUEPRINT DE IMPLEMENTAÇÃO: [Nome do Projeto]
+
+## 1. VISÃO GERAL DA ARQUITETURA
+[Descrição da arquitetura do sistema: Monolito modular, Microserviços, Hexagonal, etc.]
+[Diagrama em formato Mermaid se aplicável]
+
+## 2. STACK TÉCNICA DEFINIDA
+- **Linguagem:** [ex: PHP 8.3]
+- **Framework:** [ex: Laravel 11.x]
+- **Banco de Dados:** [ex: PostgreSQL 16.x]
+- **Pacotes Essenciais:** [Lista de dependências do composer/npm]
+
+## 3. MODELO DE DADOS
+[Entidades principais, relacionamentos e tipos de dados]
+[Exemplo de Migration Laravel ou Model Pydantic/Go Struct]
+
+## 4. ESTRUTURA DE PASTAS E ARQUIVOS
+[Árvore de diretórios completa focando nos arquivos que serão criados/modificados]
+```text
+app/
+├── Http/
+│   ├── Controllers/
+│   └── Requests/
+├── Models/
+├── Services/
+└── ...
+```
+
+## 5. ENDPOINTS DA API
+| Método | Endpoint | Controller@Method | Descrição | Request Body | Response | Auth |
+|---|---|---|---|---|---|---|
+| POST | /api/v1/users | UserController@store | Cria usuário | {name, email, pass} | {id, token} | Não |
+| GET | /api/v1/users | UserController@index | Lista usuários | - | [{id, name}] | Sim |
+
+## 6. CÓDIGO-BASE / PADRÕES A SEGUIR
+[Trechos de código críticos que definem o padrão do projeto]
+[Exemplo: Interface de repositório, FormRequest base, Trait de respostas de API]
+
+## 7. PLANO DE EXECUÇÃO (FASES)
+- **Fase 1:** Setup do projeto e Banco de Dados (Migrations/Seeds)
+- **Fase 2:** Autenticação e Autorização (Middlewares/Policies)
+- **Fase 3:** [Módulo Principal 1]
+- **Fase 4:** [Módulo Principal 2]
+- **Fase N:** Testes e Documentação
+
+## 8. COMANDOS DE SETUP
+[Todos os comandos para rodar o projeto do zero, ex: docker-compose up, php artisan migrate, etc]
+
+## 9. CRITÉRIOS DE SUCESSO GERAIS
+- [ ] O código passa em todos os testes (`php artisan test`)
+- [ ] Não há erros de linting (`./vendor/bin/pint`)
+- [ ] A API responde conforme os endpoints definidos
+- [ ] A documentação Swagger/OpenAPI está atualizada

package/templates/ide/cursor/templates/DESIGN-template.md

@@ -0,0 +1,34 @@
+# PROJETO: [Nome do Projeto]
+
+## DESCRIÇÃO
+[O que é o sistema em 2-3 frases claras e objetivas]
+
+## FUNCIONALIDADES
+- [Funcionalidade 1: descrição detalhada]
+- [Funcionalidade 2: descrição detalhada]
+- [...]
+
+## STACK TÉCNICA
+- **Linguagem:** [ex: PHP 8.3]
+- **Framework:** [ex: Laravel 11]
+- **Banco de Dados:** [ex: PostgreSQL 16]
+- **Frontend:** [ex: Vue.js 3 / Nuxt]
+- **Outros:** [ex: Redis, S3]
+
+## REQUISITOS TÉCNICOS E DE NEGÓCIO
+- [Requisito 1: ex. API deve responder em menos de 200ms]
+- [Requisito 2: ex. Autenticação via JWT (Sanctum)]
+- [Requisito 3: ex. Cobertura de testes unitários > 80%]
+
+## INTEGRAÇÕES
+- [Integração 1: ex. Stripe para pagamentos (link da doc)]
+- [Integração 2: ex. AWS S3 para armazenamento de arquivos]
+
+## RESTRIÇÕES
+- **Prazo:** [Data limite ou restrição de tempo]
+- **Orçamento:** [Limitações de custo com infra/APIs]
+- **Limitações Técnicas:** [ex. Não pode usar banco NoSQL]
+
+## FORA DO ESCOPO
+- [O que NÃO será feito nesta versão]
+- [Funcionalidades adiadas para v2]

package/templates/ide/cursor/templates/TASK-SPEC-template.md

@@ -0,0 +1,43 @@
+# ESPECIFICAÇÃO DE TAREFA: [ID da Task, ex: task-001]
+
+## OBJETIVO DA TAREFA
+[Descrição concisa do que precisa ser implementado, ex: Criar o Model, Migration e Factory para a entidade Usuário.]
+
+## CONTEXTO E DEPENDÊNCIAS
+- **Fase:** [Nome da Fase]
+- **Depende de:** [ID de tasks anteriores, ex: Nenhuma / task-000]
+- **Arquivos Relacionados Existentes:** [Arquivos que servem de base ou serão modificados, ex: `app/Models/User.php`]
+
+## ESPECIFICAÇÃO DE IMPLEMENTAÇÃO (O QUE FAZER)
+[Instruções detalhadas passo a passo para a IA Executora]
+
+1. **[Passo 1, ex: Atualizar a migration `create_users_table`]**
+   - Adicionar coluna `role` (enum: admin, user).
+   - Adicionar coluna `is_active` (boolean, default true).
+
+2. **[Passo 2, ex: Atualizar o Model `User`]**
+   - Adicionar campos ao `$fillable`.
+   - Criar os casts corretos.
+
+3. **[Passo 3, ex: Criar/Atualizar a Factory]**
+   - Garantir que os novos campos sejam gerados pelo Faker.
+
+## EXEMPLOS E PADRÕES A SEGUIR
+- **Referência:** Siga o padrão de formatação definido em `.cursorrules`.
+- **Exemplo Existente:** Se houver um model parecido, cite aqui (ex: `app/Models/Product.php`).
+
+## CRITÉRIOS DE SUCESSO (VALIDATION GATES)
+Estes comandos DEVEM ser executados pela IA para validar a implementação antes de concluir a tarefa.
+
+```bash
+# 1. Linting / Formatação
+./vendor/bin/pint
+
+# 2. Análise Estática (se aplicável, ex: PHPStan/Larastan)
+./vendor/bin/phpstan analyse
+
+# 3. Testes Unitários/Feature
+php artisan test --filter=UserTest
+```
+
+Se algum comando falhar, a IA deve ler o erro, consertar o código e rodar o comando novamente (Ralph Loop) até que todos os testes passem.