@dewtech/dare-cli 2.10.0 → 2.12.0

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

@@ -1,53 +1,193 @@
-# 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
+# BLUEPRINT: [Nome do Projeto]
+
+> **Gerado a partir de:** `DARE/DESIGN.md` v[X.Y]  
+> **Data:** YYYY-MM-DD | **Status:** DRAFT → APROVADO
+
+---
+
+## 1. VISÃO GERAL DA ARQUITETURA
+
+[Descrição da arquitetura: Monolito modular / Microserviços / Hexagonal / Clean Architecture]
+
+```mermaid
+graph TD
+    A[Cliente] --> B[API Gateway / BFF]
+    B --> C[Auth Service]
+    B --> D[Core Service]
+    D --> E[(PostgreSQL)]
+    D --> F[(Redis)]
+```
+
+**Decisões arquiteturais principais:**
+
+| Decisão | Escolha | Justificativa |
+|---------|---------|---------------|
+| Padrão de módulos | [ex: Hexagonal] | [motivo] |
+| Comunicação inter-serviços | [ex: REST síncrono] | [motivo] |
+| Autenticação | [ex: JWT stateless] | [motivo] |
+
+---
+
+## 2. STACK TÉCNICA DEFINIDA
+
+| Camada | Tecnologia | Versão | Papel |
+|--------|-----------|--------|-------|
+| Linguagem | | | |
+| Framework | | | |
+| Banco principal | | | |
+| Cache / filas | | | |
+| Frontend | | | |
+| Container | Docker | latest | Dev + CI |
+| Observabilidade | | | Logs, métricas, traces |
+
+---
+
+## 3. ESTRUTURA DE PASTAS E ARQUIVOS
+
+```text
+[nome-do-projeto]/
+├── [diretório principal]/
+│   ├── [módulo 1]/
+│   └── [módulo 2]/
+├── DARE/
+│   ├── DESIGN.md
+│   ├── BLUEPRINT.md
+│   ├── TASKS.md
+│   ├── dare-dag.yaml
+│   └── EXECUTION/
+├── Dockerfile
+├── docker-compose.yml
+└── [arquivo de configuração principal]
+```
+
+> **Constraints de workspace (Rust):** se Cargo workspace, NÃO definir `[build] target` global no `.cargo/config.toml` (quebra crates WASM + native). Cada crate declara suas próprias features Leptos.
+
+---
+
+## 4. MODELO DE DADOS
+
+### Entidades principais
+
+```
+[Entidade 1]
+- id: UUID (PK)
+- [campo]: [tipo] [restrições]
+- created_at, updated_at
+
+[Entidade 2]
+- id: UUID (PK)
+- [entidade_1_id]: FK → Entidade1
+```
+
+### Relacionamentos
+
+| De | Para | Cardinalidade | Via |
+|----|------|---------------|-----|
+| [Entidade 1] | [Entidade 2] | 1:N | FK |
+
+---
+
+## 5. CONTRATOS DE API
+
+| Método | Endpoint | Auth | Request Body | Response | Status codes |
+|--------|----------|------|-------------|----------|--------------|
+| POST | `/api/v1/[recurso]` | Não | `{campo1, campo2}` | `{id, ...}` | 201, 400, 422 |
+| GET | `/api/v1/[recurso]` | JWT | — | `[{id, ...}]` | 200, 401 |
+| GET | `/api/v1/[recurso]/:id` | JWT | — | `{id, ...}` | 200, 401, 404 |
+| PUT | `/api/v1/[recurso]/:id` | JWT + Owner | `{campos}` | `{id, ...}` | 200, 401, 403, 404 |
+| DELETE | `/api/v1/[recurso]/:id` | JWT + Admin | — | `{}` | 204, 401, 403, 404 |
+
+---
+
+## 6. PLANO DE EXECUÇÃO (FASES)
+
+### Fase 1: Containerização e Setup ← **SEMPRE PRIMEIRA**
+**Critério de DONE:** `docker compose up -d` sobe sem erros; healthcheck `/health` retorna 200.
+- Dockerfile multi-stage
+- docker-compose.yml com todos os serviços
+- Variáveis de ambiente via `.env.example`
+
+### Fase 2: Banco de Dados e Migrations
+**Critério de DONE:** migrations rodando; schema validado; seeds de desenvolvimento funcionando.
+- Migrations / schema inicial
+- Seeds de desenvolvimento
+- Índices para queries críticas
+
+### Fase 3: Autenticação e Autorização
+**Critério de DONE:** login retorna JWT; endpoint protegido rejeita token inválido com 401; acesso sem permissão retorna 403.
+- Registro, login, refresh, logout
+- Middleware de autenticação
+- Sistema de permissões (RBAC/ACL)
+
+### Fase 4: [Módulo de negócio principal]
+**Critério de DONE:** [comportamento testável esperado].
+- [Descrever aqui]
+
+### Fase N-1: Auditoria de Segurança e Dependências
+**Critério de DONE:** `[audit-cmd]` sem CVE HIGH/CRITICAL; security headers presentes; sem secrets em código.
+- `npm audit --audit-level=high` / `cargo audit` / `pip-audit` / `composer audit`
+- Headers HTTP de segurança (HSTS, CSP, X-Frame-Options)
+- Scan de secrets no repositório
+
+### Fase N: Observabilidade e Documentação
+**Critério de DONE:** logs estruturados em JSON; endpoint `/metrics` ou equivalente; documentação API gerada.
+- Logs estruturados (JSON) com trace-id
+- Métricas de negócio e técnicas
+- Documentação API (OpenAPI / Swagger)
+
+---
+
+## 7. VALIDAÇÃO E SEGURANÇA
+
+### Validation Gates (Ralph Loop) por stack
+
+| Stack | Build | Test | Lint/Audit |
+|-------|-------|------|------------|
+| Rust/Axum | `cargo build` | `cargo test --workspace` | `cargo clippy && cargo audit` |
+| Node/NestJS | `npm run build` | `npm test` | `npx eslint src && npm audit --audit-level=high` |
+| Python/FastAPI | `python -m py_compile` | `pytest` | `ruff check . && pip-audit` |
+| PHP/Laravel | `php artisan config:cache` | `php artisan test` | `./vendor/bin/phpstan && composer audit` |
+| Go | `go build ./...` | `go test ./...` | `golangci-lint run` |
+
+### Controles de segurança obrigatórios
+
+- [ ] Rate limiting em endpoints de autenticação e públicos
+- [ ] Input validation no servidor para todos os endpoints
+- [ ] Dados sensíveis (PII, tokens, senhas) nunca em logs
+- [ ] Todas as dependências sem CVE HIGH/CRITICAL (ver Fase N-1)
+- [ ] HTTP Security Headers em produção
+- [ ] Secrets apenas em variáveis de ambiente / vault
+
+---
+
+## 8. ESTRATÉGIA DE TESTES
+
+| Tipo | Ferramenta | Cobertura mínima | O que cobre |
+|------|-----------|------------------|-------------|
+| Unitários | [jest/pytest/cargo test] | 80 % das funções críticas | Lógica de negócio isolada |
+| Integração | [supertest/httpx/reqwest] | Todos os endpoints | Contrato da API |
+| Segurança | [npm audit/cargo audit/pip-audit] | 100 % deps | CVEs conhecidos |
+| E2E | [playwright/cypress] se frontend | Fluxo principal | Jornada do usuário |
+
+---
+
+## 9. ESTRATÉGIA DE DEPLOY
+
+| Ambiente | Branch | Trigger | Infra |
+|----------|--------|---------|-------|
+| `dev` | `develop` | Push automático | [ex: Docker local / Railway] |
+| `staging` | `main` | PR merge | [ex: OKE / ECS / Fly.io] |
+| `prod` | tag `v*.*.*` | Manual | [ex: OKE / ECS / Fly.io] |
+
+---
+
+## 10. CHECKLIST DE APROVAÇÃO DO BLUEPRINT
+
+- [ ] Arquitetura revisada e aprovada
+- [ ] Modelo de dados validado
+- [ ] Contratos de API definidos e completos
+- [ ] Fases com critérios de DONE claros
+- [ ] Validation gates por stack definidos
+- [ ] Controles de segurança mapeados
+- [ ] Estratégia de testes cobrindo todos os tipos
+- [ ] DAG de tasks gerado (`dare-dag.yaml`)

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

@@ -1,34 +1,129 @@
-# 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]
+# DESIGN: [Nome do Projeto / Feature]
+
+> **Versão:** v1.0 | **Data:** YYYY-MM-DD | **Status:** DRAFT → APROVADO
+
+---
+
+## 1. DESCRIÇÃO
+
+[O que é o sistema e qual problema ele resolve — 3 a 5 frases claras e objetivas. Evite jargão.]
+
+---
+
+## 2. OBJETIVOS E MÉTRICAS DE SUCESSO
+
+| # | Objetivo | Métrica verificável | Meta |
+|---|----------|---------------------|------|
+| O-01 | [ex: Reduzir tempo de resposta da API] | p99 latência em produção | < 200 ms |
+| O-02 | [ex: Aumentar cobertura de testes] | `coverage --summary` | > 80 % |
+| O-03 | | | |
+
+---
+
+## 3. STAKEHOLDERS
+
+| Papel | Nome / Time | Interesse principal |
+|-------|-------------|---------------------|
+| Product Owner | | Aprovação de scope e prioridades |
+| Tech Lead | | Decisões arquiteturais |
+| Usuário Final | | [Persona] — [necessidade] |
+| Operações / SRE | | SLA, alertas, deploys |
+
+---
+
+## 4. REQUISITOS FUNCIONAIS
+
+| ID | Requisito | Prioridade | Critério de aceite |
+|----|-----------|------------|--------------------|
+| RF-01 | | MUST | |
+| RF-02 | | SHOULD | |
+| RF-03 | | COULD | |
+
+> Prioridades: **MUST** (bloqueia v1) · **SHOULD** (importante, mas não bloqueia) · **COULD** (nice to have)
+
+---
+
+## 5. REQUISITOS NÃO-FUNCIONAIS
+
+| ID | Categoria | Requisito | Meta |
+|----|-----------|-----------|------|
+| RNF-01 | Performance | [ex: API responde dentro do SLA] | p95 < 500 ms |
+| RNF-02 | Disponibilidade | [ex: uptime mensal] | ≥ 99,5 % |
+| RNF-03 | Segurança | Autenticação obrigatória em todos os endpoints sensíveis | JWT + refresh |
+| RNF-04 | Segurança | Rate limiting em endpoints públicos | ≤ 60 req/min/IP |
+| RNF-05 | Segurança | Dados sensíveis (PII, tokens) nunca em logs | auditoria automática |
+| RNF-06 | Observabilidade | Logs estruturados (JSON) com trace-id | OpenTelemetry |
+| RNF-07 | Manutenibilidade | Cobertura de testes | > 80 % |
+
+---
+
+## 6. REQUISITOS DE SEGURANÇA
+
+| ID | Requisito | Referência |
+|----|-----------|------------|
+| RS-01 | Todas as entradas do usuário validadas no servidor antes de qualquer processamento | OWASP A03 |
+| RS-02 | Senhas e segredos nunca armazenados em texto plano; hash Argon2/Bcrypt | OWASP A02 |
+| RS-03 | Controle de acesso verificado por recurso (não só por rota) | OWASP A01 |
+| RS-04 | Dependências auditadas antes de cada release (sem CVE HIGH/CRITICAL) | OWASP A06 |
+| RS-05 | Segredos gerenciados via variáveis de ambiente / vault — nunca em código | Supply chain |
+| RS-06 | [Requisito específico do domínio] | |
+
+---
+
+## 7. STACK TÉCNICA
+
+| Camada | Tecnologia | Versão |
+|--------|-----------|--------|
+| Linguagem / Runtime | | |
+| Framework principal | | |
+| Banco de dados | | |
+| Cache | | |
+| Frontend | | |
+| Infra / deploy | | |
+| Observabilidade | | |
+
+---
+
+## 8. INTEGRAÇÕES EXTERNAS
+
+| Sistema | Tipo | Protocolo | Direção | Dados trocados | Responsável |
+|---------|------|-----------|---------|----------------|-------------|
+| [ex: Stripe] | Pagamento | REST/webhook | Saída + entrada | Cobrança, confirmação | Time Pagamentos |
+| [ex: Auth0] | IdP | OIDC | Entrada | ID Token, Claims | Time Auth |
+
+---
+
+## 9. RESTRIÇÕES
+
+- **Prazo:** [Data de entrega ou milestone]
+- **Orçamento de infra:** [Limite de custo mensal ou por request]
+- **Limitações técnicas:** [ex: não pode usar banco NoSQL; deve usar Go ≥ 1.22]
+- **Regulatórias / Compliance:** [ex: LGPD, GDPR, SOC 2, PCI-DSS se aplicável]
+
+---
+
+## 10. FORA DO ESCOPO (v1)
+
+- [Funcionalidade adiada para v2 — e o motivo]
+- [Caso de uso que NÃO será tratado nesta versão]
+
+---
+
+## 11. RISCOS E MITIGAÇÕES
+
+| # | Risco | Probabilidade | Impacto | Mitigação |
+|---|-------|---------------|---------|-----------|
+| R-01 | [ex: Latência alta no serviço de terceiros] | Média | Alto | Circuit breaker + fallback |
+| R-02 | [ex: Falta de dados históricos para ML] | Alta | Médio | Dataset sintético inicial |
+| R-03 | | | | |
+
+---
+
+## 12. CHECKLIST DE APROVAÇÃO
+
+- [ ] Requisitos funcionais revisados e priorizados
+- [ ] Requisitos de segurança validados pelo Tech Lead
+- [ ] Stack técnica aprovada
+- [ ] Integrações externas confirmadas com responsáveis
+- [ ] Fora do escopo alinhado com Product Owner
+- [ ] Riscos críticos com mitigação definida

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

@@ -1,43 +1,100 @@
-# 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.
+# TASK [ID]: [Título da Task]
+
+> **Complexidade:** LOW / MED / HIGH  
+> **Depends on:** [task-ids ou —]  
+> **Estimativa:** [X horas]
+
+---
+
+## 1. OBJETIVO
+
+[Uma frase precisa do que esta task entrega. Deve ser verificável — termine com um estado observável, não uma ação.]
+
+Exemplo: _"Ao final desta task, o endpoint `POST /api/v1/users` aceita cadastro, valida unicidade de e-mail e retorna JWT."_
+
+---
+
+## 2. CONTEXTO
+
+- **Fase no BLUEPRINT:** Fase [N] — [Nome da fase]
+- **Arquivos existentes relevantes:** [caminhos de arquivos que servem de referência ou serão modificados]
+- **Decisões do BLUEPRINT que afetam esta task:** [cite seção/decisão específica]
+
+---
+
+## 3. ARQUIVOS A CRIAR / MODIFICAR
+
+| Ação | Caminho | Descrição |
+|------|---------|-----------|
+| CRIAR | `src/[módulo]/[arquivo]` | [o que contém] |
+| MODIFICAR | `src/[módulo]/[arquivo]` | [o que muda] |
+| CRIAR | `tests/[arquivo].test.[ext]` | Testes da feature |
+
+---
+
+## 4. IMPLEMENTAÇÃO
+
+### Passo 1: [Nome do passo]
+[Descrição precisa do que fazer. Inclua assinaturas de função/struct se crítico.]
+
+```[lang]
+// Exemplo de padrão esperado
+```
+
+### Passo 2: [Nome do passo]
+[Descrição]
+
+### Passo 3: Testes
+- [ ] Teste do caminho feliz (`should_[comportamento]_when_[condição]`)
+- [ ] Teste de erro de validação (400 / erro de negócio)
+- [ ] Teste de autorização (401 / 403 quando aplicável)
+- [ ] Teste de edge case: [descrever]
+
+---
+
+## 5. CONSIDERAÇÕES DE SEGURANÇA
+
+- [ ] **Input validation:** toda entrada do usuário validada no servidor antes de qualquer processamento
+- [ ] **Autenticação / Autorização:** verificar se o usuário tem permissão sobre o *recurso específico*, não só sobre a rota
+- [ ] **Dados sensíveis:** senhas, tokens e PII nunca aparecem em logs, responses de erro ou mensagens de exceção
+- [ ] **SQL / Command Injection:** usar ORM / prepared statements; nunca concatenar strings em queries
+- [ ] **Dependências novas:** se esta task adicionar uma dependência, verificar CVEs com `npm audit` / `cargo audit` / `pip-audit` antes de commitar
+- [ ] **Segredo em código:** nenhum token, chave ou credencial hardcoded — sempre via variável de ambiente
+
+---
+
+## 6. VALIDATION GATES (RALPH LOOP)
+
+Execute **todos** antes de marcar a task como DONE. Se qualquer um falhar, leia o erro, corrija e reexecute.
+
+```bash
+# 1. Build — sem erros de compilação
+[comando de build da stack]
+
+# 2. Tests — todos passando, incluindo os novos
+[comando de test]
+
+# 3. Lint — sem warnings
+[comando de lint]
+
+# 4. Auditoria de dependências (se novas deps foram adicionadas nesta task)
+[npm audit --audit-level=high | cargo audit | pip-audit | composer audit]
+```
+
+> **Gate de segurança obrigatório:** se esta task adicionar dependências externas, `[audit-cmd]` não pode retornar CVE de nível HIGH ou CRITICAL.
+
+---
+
+## 7. CRITÉRIOS DE DONE
+
+- [ ] Todos os 4 validation gates passaram sem erros
+- [ ] Testes cobrem caminho feliz + erros + edge cases da seção 4
+- [ ] Considerações de segurança da seção 5 todas checadas
+- [ ] Arquivos listados na seção 3 criados/modificados conforme spec
+- [ ] `DARE/TASKS.md` atualizado com status `DONE`
+
+---
+
+## 8. PRÓXIMA TASK SUGERIDA
+
+`[task-id]` — [título] _(desbloqueada após conclusão desta task)_

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

@@ -1,21 +1,51 @@
-# Comando: /generate-blueprint
-
-## Descrição
-Este comando avança o Método DARE para a fase Architect, lendo o Design aprovado e gerando a arquitetura completa de implementação.
-
-## Instruções para o Cursor Composer
-
-1. **Leia o Documento Design:** Acesse e leia o arquivo `$ARGUMENTS` (geralmente `DARE/DESIGN.md`) que contém os requisitos do projeto.
-2. **Leia o Template:** Utilize a estrutura definida em `templates/BLUEPRINT-template.md`.
-3. **Analise o Contexto Global:** Leia o arquivo `.cursorrules` (ou equivalente) para entender as regras, convenções de nomenclatura e padrões de arquitetura exigidos pela stack do projeto.
-4. **Analise Exemplos:** Se houver arquivos na pasta `examples/`, analise-os para extrair os padrões de código esperados e incluí-los na seção "CÓDIGO-BASE / PADRÕES A SEGUIR".
-5. **Gere a Arquitetura (O Blueprint):**
-   - **Visão Geral:** Defina a arquitetura apropriada para o projeto (Monolito, Microserviços, Hexagonal, MVC).
-   - **Segurança (OWASP):** Adicione uma subseção explicando como as diretrizes da `skill-security.mdc` serão implementadas (ex: Bcrypt para senhas, Middlewares de Rate Limit, Validação estrita).
-   - **Modelo de Dados:** Projete o esquema completo do banco de dados (tabelas, campos, tipos, relacionamentos) e apresente em formato Markdown ou SQL simplificado. Certifique-se de que dados sensíveis estão protegidos.
-   - **Endpoints:** Liste todas as rotas da API necessárias com Request e Response esperados em uma tabela Markdown, incluindo as necessidades de Autenticação/Autorização.
-   - **Estrutura:** Esboce a árvore de diretórios dos arquivos que serão criados.
-   - **Plano de Execução:** Divida o projeto em Fases lógicas e sequenciais. A Fase 2 geralmente deve incluir o Setup de Segurança (Auth, Middlewares).
-   - **Comandos:** Liste comandos de setup (ex: migrations, composer install).
-6. **Salve o Arquivo:** Crie o arquivo `DARE/BLUEPRINT.md` com o conteúdo gerado.
-7. **Mensagem Final:** Informe ao usuário: "Documento BLUEPRINT.md gerado com sucesso. Por favor, revise a arquitetura e os endpoints. Quando estiver aprovado, execute `/generate-tasks DARE/BLUEPRINT.md`."
+# Comando: /generate-blueprint
+
+## Descrição
+Avança o DARE para a fase Architect: lê `DARE/DESIGN.md` aprovado e gera os 5 artefatos de arquitetura.
+
+## Instruções para o Cursor Composer
+
+1. **Leia `DARE/DESIGN.md`** — obrigatório. Se não existir, peça `/generate-design` primeiro. Extraia: stack, RF-*, RNF-*, RS-*, integrações, restrições.
+
+2. **Leia o template:** `templates/BLUEPRINT-template.md` — siga a estrutura fielmente.
+
+3. **Gere `DARE/BLUEPRINT.md`** com seções obrigatórias:
+
+   - **Visão Geral da Arquitetura** — diagrama Mermaid + tabela de decisões com justificativa
+   - **Stack Técnica Definida** — versões fixas (não ranges)
+   - **Estrutura de Pastas** — árvore completa dos arquivos a criar
+   - **Modelo de Dados** — entidades, campos tipados, relacionamentos, índices
+   - **Contratos de API** — método, rota, auth, request/response, status codes
+   - **Plano de Execução (Fases)** — cada fase com critério de DONE verificável:
+     - **Fase 1 = containerização** (Dockerfile + docker-compose + healthcheck) — sempre
+     - **Fase N-1 = auditoria de segurança + dependências** — sempre
+   - **Validation Gates por stack:**
+     | Stack | Build | Test | Lint/Audit |
+     |-------|-------|------|------------|
+     | Rust | `cargo build` | `cargo test --workspace` | `cargo clippy && cargo audit` |
+     | Node | `npm run build` | `npm test` | `npx eslint src && npm audit --audit-level=high` |
+     | Python | verificar imports | `pytest` | `ruff check . && pip-audit` |
+     | PHP | `php artisan config:cache` | `php artisan test` | `./vendor/bin/phpstan && composer audit` |
+     | Go | `go build ./...` | `go test ./...` | `golangci-lint run` |
+   - **Controles de Segurança** — checklist mapeando cada RS-* do DESIGN para tasks específicas
+   - **Estratégia de Testes** — unitários + integração + auditoria de deps + E2E
+   - **Estratégia de Deploy** — por ambiente
+
+4. **Gere `DARE/dare-dag.yaml`** com regras:
+   - `id` kebab-case único; `depends_on` mínimo necessário
+   - Pelo menos 2 tasks no rank 0 (paralelismo real)
+   - task-001 = containerização; task final = auditoria de segurança
+   - Sem task "Ralph Loop final" ou "QA geral" — corre em cada `--complete`
+   - `subtask_prompt` totalmente self-contained
+
+5. **Gere `DARE/TASKS.md`** (tabela de status visual)
+
+6. **Gere `DARE/EXECUTION/task-<id>.md`** para cada task usando `templates/TASK-SPEC-template.md`:
+   - Objetivo verificável (estado, não ação)
+   - Arquivos a criar/modificar (tabela)
+   - Seção "Considerações de Segurança" obrigatória
+   - Validation gates específicos da stack (build + test + lint + audit se nova dep)
+
+7. **Valide consistência** dos 5 artefatos (IDs, depends_on, complexity iguais nos 3)
+
+8. **Salve e informe:** _"Blueprint gerado com [N] tasks em [K] ranks paralelos. Revise especialmente: [lista de tasks HIGH complexity]. Quando aprovado, execute `dare execute --parallel`."_