@dewtech/dare-cli 2.11.0 → 2.12.0

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

@@ -1,18 +1,35 @@
-# Comando: /generate-design
-
-## Descrição
-Este comando inicia o Método DARE (Design) gerando um documento de requisitos a partir de uma ideia inicial.
-
-## Instruções para o Cursor Composer
-
-1. **Leia a Ideia Inicial:** Analise o prompt fornecido pelo usuário (`$ARGUMENTS`) que descreve o que ele deseja construir.
-2. **Leia o Template:** Utilize a estrutura definida em `templates/DESIGN-template.md`.
-3. **Analise o Contexto Global:** Leia o arquivo `.cursorrules` (ou equivalente na pasta `.cursor/rules/`) para entender a stack técnica do projeto e preencher automaticamente a seção de STACK TÉCNICA.
-4. **Gere o Documento:**
-   - Preencha o template com as informações extraídas do prompt.
-   - Organize as funcionalidades de forma clara.
-   - Identifique possíveis requisitos técnicos implícitos e restrições.
-   - **Integre Requisitos de Segurança (OWASP):** Adicione obrigatoriamente requisitos de segurança na seção correspondente (ex: Rate Limiting, HTTPS, Proteção contra Força Bruta) baseando-se na skill `skill-security.mdc`.
-   - Defina claramente o que fica FORA DO ESCOPO para manter o foco da versão.
-5. **Salve o Arquivo:** Crie o arquivo `DARE/DESIGN.md` com o conteúdo gerado.
-6. **Mensagem Final:** Informe ao usuário: "Documento DESIGN.md gerado com sucesso. Por favor, revise e aprove o documento. Quando estiver pronto, execute `/generate-blueprint DARE/DESIGN.md`."
+# Comando: /generate-design
+
+## Descrição
+Inicia o Método DARE (fase Design) gerando `DARE/DESIGN.md` a partir de uma ideia inicial.
+
+## Instruções para o Cursor Composer
+
+1. **Leia o contexto:** `package.json` / `Cargo.toml` / `composer.json` / `go.mod` / `requirements.txt` para identificar a stack atual. Leia `.cursorrules` para entender padrões do projeto. Se `DARE/DESIGN.md` já existir, não sobrescreva sem aprovação explícita.
+
+2. **Leia o template:** `templates/DESIGN-template.md` — siga a estrutura fielmente.
+
+3. **Gere `DARE/DESIGN.md` com as seções obrigatórias:**
+
+   - **Descrição** — 3 a 5 frases: o que é, qual problema resolve, quem usa
+   - **Objetivos e Métricas de Sucesso** — tabela numerada (O-01, O-02…) com métrica verificável e meta numérica
+   - **Stakeholders** — tabela: papel, time, interesse principal
+   - **Requisitos Funcionais** — tabela numerada (RF-01, RF-02…) com prioridade MUST/SHOULD/COULD e critério de aceite
+   - **Requisitos Não-Funcionais** — tabela numerada (RNF-01…): performance, disponibilidade, segurança, observabilidade, manutenibilidade
+   - **Requisitos de Segurança** — tabela numerada (RS-01…). **Sempre inclua:**
+     - RS-01: validação de entrada no servidor (OWASP A03)
+     - RS-02: hash de senhas / proteção de dados sensíveis (OWASP A02)
+     - RS-03: controle de acesso por recurso (OWASP A01)
+     - RS-04: auditoria de dependências sem CVE HIGH/CRITICAL (OWASP A06)
+     - RS-05: secrets via variáveis de ambiente — nunca em código
+     - Requisitos específicos do domínio do projeto
+   - **Stack Técnica** — tabela por camada com versões fixas
+   - **Integrações Externas** — tabela: sistema, tipo, protocolo, direção, dados, responsável
+   - **Restrições** — prazo, orçamento, técnicas, compliance
+   - **Fora do Escopo (v1)** — lista explícita
+   - **Riscos e Mitigações** — tabela com probabilidade, impacto e mitigação concreta
+   - **Checklist de Aprovação** — checkboxes para revisão humana
+
+4. **Qualidade:** O DESIGN.md deve responder claramente: O QUÊ, POR QUÊ, PARA QUEM, O QUE NÃO e QUAIS RISCOS. Use "[A definir]" para informações não disponíveis, mas nunca omita seções.
+
+5. **Salve** `DARE/DESIGN.md` e informe: _"DESIGN.md gerado. Revise as seções, especialmente os Requisitos de Segurança (RS-*) e Riscos. Quando aprovado, execute `/generate-blueprint`."_

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

@@ -1,57 +1,245 @@
----
-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).
+---
+description: Diretrizes de Segurança — OWASP Top 10, Supply Chain, Segredos e Dependências Vulneráveis para todas as fases do DARE
+globs: *.md, *.php, *.py, *.go, *.vue, *.js, *.ts, *.rs, *.toml, *.yaml, *.yml
+---
+
+# Diretrizes de Segurança DARE
+
+Você é um Especialista em AppSec. Garanta que **Design → Blueprint → Tasks → Execução** sigam rigorosamente as práticas a seguir.
+
+---
+
+## Aplicação nas Fases do DARE
+
+### Fase 1 — Design (`/generate-design` / `/dare-design`)
+
+- **Requisitos de segurança obrigatórios** (seção RS-*):
+  - RS-01: validação de entrada (OWASP A03)
+  - RS-02: hash de senhas / proteção de dados sensíveis (OWASP A02)
+  - RS-03: controle de acesso por recurso (OWASP A01)
+  - RS-04: auditoria de dependências sem CVE HIGH/CRITICAL (OWASP A06)
+  - RS-05: secrets via variáveis de ambiente — nunca em código
+- Identifique vetores de ataque na ideia inicial e adicione mitigações em **Riscos**
+
+### Fase 2 — Architect (`/generate-blueprint` / `/dare-blueprint`)
+
+- Endpoints da API: inclua coluna `Auth` (JWT/apiKey/público) e middleware de rate limiting
+- Modelo de dados: marque campos sensíveis (PII, tokens, hashes) e como são protegidos
+- Fases do plano: inclua **Fase N-1 = Auditoria de Segurança e Dependências** com critério de DONE explícito
+- Validation gates por stack devem incluir o comando de auditoria de dependências
+
+### Fase 3 — Tasks (`/generate-tasks`)
+
+- Toda task que adiciona dependência externa → validation gate inclui `npm audit` / `cargo audit` / `pip-audit` / `composer audit`
+- Crie task dedicada para: headers de segurança HTTP, rate limiting, scan de secrets
+- Seção "Considerações de Segurança" obrigatória em cada `EXECUTION/task-*.md`
+
+### Fase 4 — Execute (`/execute-task`)
+
+Aplique as proteções abaixo ao implementar qualquer código.
+
+---
+
+## OWASP Top 10 — Implementação
+
+### A01 — Broken Access Control
+
+- Verifique permissão no **recurso**, não só na rota: `user.can('update', post)` / `authorize('update', $post)` / `check_permission(user, resource)`
+- Princípio do menor privilégio: tokens têm escopos mínimos necessários
+- Nunca exponha IDs sequenciais em URLs para recursos privados — use UUID ou ULID
+- Multi-tenant: **sempre** filtre por `tenant_id` / `org_id` em toda query
+
+```ts
+// ✅ certo — verifica ownership antes de retornar
+const post = await db.post.findFirst({ where: { id, authorId: session.userId } });
+if (!post) throw new ForbiddenError();
+
+// ❌ errado — qualquer usuário autenticado acessa qualquer post
+const post = await db.post.findUnique({ where: { id } });
+```
+
+### A02 — Cryptographic Failures
+
+- Senhas: **Argon2id** (preferido) ou Bcrypt (min cost 12) — nunca MD5/SHA1/SHA256 para senhas
+- Dados sensíveis em repouso: criptografar PII com AES-256-GCM
+- Dados em trânsito: HTTPS obrigatório; HSTS header em produção
+- Nunca logue senha, token, chave de API, número de cartão, CPF completo
+- JWT: assine com RS256 (chave assimétrica) para tokens públicos; HS256 + segredo forte (≥ 256 bits) para internos
+
+```rust
+// ✅ Rust — Argon2 via argon2 crate
+use argon2::{Argon2, PasswordHash, PasswordHasher, PasswordVerifier};
+let hash = Argon2::default().hash_password(password.as_bytes(), &salt)?;
+```
+
+### A03 — Injection
+
+**SQL Injection:**
+```python
+# ✅ SQLAlchemy — parametrizado
+result = db.execute(select(User).where(User.email == email))
+
+# ❌ nunca
+db.execute(f"SELECT * FROM users WHERE email = '{email}'")
+```
+
+**Command Injection:**
+```go
+// ✅ Go — lista de args, não shell string
+cmd := exec.Command("convert", inputFile, outputFile)
+
+// ❌ nunca
+exec.Command("sh", "-c", "convert "+userInput)
+```
+
+**XSS:** escape de saída no frontend; `Content-Security-Policy` no backend; evite `innerHTML` / `dangerouslySetInnerHTML` com dados do usuário.
+
+**Prompt Injection (IA):** se o projeto processa entradas de usuários em prompts LLM:
+- Separe instrução do sistema e dados do usuário por delimitadores claros
+- Valide e sanitize a entrada antes de inserir no prompt
+- Nunca confie em output do LLM como código a ser executado sem sandboxing
+
+### A04 — Insecure Design
+
+- Valide **no servidor** sempre, mesmo que o frontend já valide
+- Allowlists > blocklists para validação de campos, tipos de arquivo, domínios
+- Implemente rate limiting antes de qualquer lógica de negócio em endpoints públicos
+
+### A05 — Security Misconfiguration
+
+- Stack traces e erros detalhados: **apenas em desenvolvimento** — produção retorna mensagem genérica
+- Headers de segurança obrigatórios em produção:
+  ```
+  Strict-Transport-Security: max-age=31536000; includeSubDomains
+  X-Frame-Options: DENY
+  X-Content-Type-Options: nosniff
+  Content-Security-Policy: default-src 'self'
+  Referrer-Policy: strict-origin-when-cross-origin
+  Permissions-Policy: camera=(), microphone=(), geolocation=()
+  ```
+- CORS: nunca `Access-Control-Allow-Origin: *` para endpoints autenticados
+- Desabilite métodos HTTP desnecessários (TRACE, OPTIONS em APIs simples)
+
+### A06 — Vulnerable and Outdated Components ← **crítico para Ralph Loop**
+
+**Comandos de auditoria por stack:**
+
+```bash
+# Node.js / npm — rodar antes de todo commit com novas deps
+npm audit --audit-level=high
+npm audit fix                      # corrige automaticamente quando possível
+
+# Rust / Cargo
+cargo install cargo-audit          # uma vez
+cargo audit                        # detecta CVEs no RustSec Advisory DB
+cargo update                       # bumpa versões compatíveis
+
+# Python
+pip install pip-audit
+pip-audit                          # CVEs via OSV + PyPI
+pip-audit --fix                    # auto-fix quando possível
+
+# PHP / Composer
+composer audit                     # nativo desde Composer 2.4
+composer update --with-all-dependencies [pacote]  # fix pontual
+
+# Go
+go list -json -m all | nancy sleuth  # ou govulncheck
+govulncheck ./...                   # ferramenta oficial Google
+
+# Docker images
+docker scout cves [imagem]          # se Docker Scout disponível
+```
+
+**Critério inegociável:** nenhuma dependência com CVE de nível **HIGH** ou **CRITICAL** pode entrar em produção sem justificativa documentada e plano de upgrade.
+
+### A07 — Authentication Failures
+
+- Rate limiting no endpoint de login: máx 5 tentativas / 15 min por IP + por usuário
+- Tokens JWT: `exp` máx 15 min para access token; refresh token com rotação
+- Logout: invalide refresh token no servidor (não confie só no lado cliente)
+- Senhas: mínimo 12 caracteres; bloquear senhas da lista HaveIBeenPwned
+- MFA: ofereça TOTP (RFC 6238) para contas com acesso a dados sensíveis
+
+### A08 — Software and Data Integrity
+
+- Valide assinatura / checksum de artefatos externos antes de usar
+- Nunca confie em dados enviados pelo cliente para decisões de autorização
+- CI/CD: pins de versão em actions (`actions/checkout@v4` não `@main`)
+- Lockfiles (`package-lock.json`, `Cargo.lock`, `poetry.lock`) devem ser commitados
+
+### A09 — Security Logging and Monitoring
+
+Logue (estruturado JSON, sem dados sensíveis):
+- Autenticação: login OK/FAIL, logout, refresh, MFA challenge
+- Autorização: acesso negado (403) com recurso e userId
+- Erros 5xx em produção com trace-id (sem stack trace completo)
+- Operações destrutivas: delete, disable, role change
+
+Nunca logue: senhas, tokens, chaves de API, números de cartão, CPF/SSN completo.
+
+### A10 — SSRF
+
+- Se a aplicação faz requisições para URLs fornecidas pelo usuário:
+  - Valide contra allowlist de domínios
+  - Bloqueie IPs privados (`127.x`, `10.x`, `172.16-31.x`, `192.168.x`, `169.254.x`)
+  - Bloqueie acesso a metadados de cloud (`169.254.169.254`)
+  - Use timeout agressivo (máx 5s) e sem redirects automáticos
+
+---
+
+## Segredos e Supply Chain
+
+### Nunca em código
+
+```bash
+# Padrões proibidos em commits — configure pre-commit hook ou git-secrets:
+password = "..."
+api_key = "..."
+secret_key = "..."
+AWS_SECRET_ACCESS_KEY = "..."
+DATABASE_URL = "postgres://user:password@..."
+```
+
+### Gestão de segredos
+
+- Desenvolvimento: arquivo `.env` (no `.gitignore`) com `.env.example` sem valores reais
+- CI/CD: variáveis de ambiente ou secrets do pipeline (GitHub Actions Secrets, etc.)
+- Produção: vault (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager)
+- Rotação: tokens de serviço rotacionados a cada 90 dias
+
+### Verificação pre-commit (recomendado)
+
+```bash
+# Instalar detect-secrets
+pip install detect-secrets
+detect-secrets scan > .secrets.baseline
+detect-secrets audit .secrets.baseline
+
+# Ou git-secrets
+git secrets --install
+git secrets --register-aws
+```
+
+---
+
+## Validation Gates de Segurança no Ralph Loop
+
+Adicione ao ciclo de cada task que mexe em dependências ou configuração:
+
+```bash
+# 1. Auditoria de dependências (obrigatório se houve mudança em deps)
+npm audit --audit-level=high         # Node
+cargo audit                          # Rust
+pip-audit                            # Python
+composer audit                       # PHP
+
+# 2. Scan de secrets (obrigatório em tasks de config/infra/CI)
+detect-secrets scan --baseline .secrets.baseline
+
+# 3. Headers de segurança (para tasks de configuração de servidor)
+# Verificar manualmente ou com curl:
+curl -I https://staging.example.com | grep -E "Strict-Transport|X-Frame|X-Content|Content-Security"
+```
+
+> **Gate obrigatório:** CVE HIGH/CRITICAL nas dependências = task **FAILED** até corrigi-las.

package/templates/ide/cursor/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`)