@dewtech/dare-cli 2.11.0 → 2.12.0

package/templates/ide/antigravity/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/claude/.claude/commands/dare-blueprint.md

@@ -1,11 +1,12 @@
 # /dare-blueprint
 
-Gera os 4 artefatos a partir do `DARE/DESIGN.md`:
+Gera os 5 artefatos a partir do `DARE/DESIGN.md`:
 
-1. `DARE/BLUEPRINT.md` — arquitetura técnica
+1. `DARE/BLUEPRINT.md` — arquitetura técnica detalhada
 2. `DARE/TASKS.md` — visão humana das tasks
 3. `DARE/dare-dag.yaml` — grafo executável pelo CLI
-4. `DARE/EXECUTION/task-<id>.md` — uma spec detalhada por task
+4. `DARE/EXECUTION/task-<id>.md` — spec detalhada por task
+5. `DARE/dag-graph.mmd` — visualização Mermaid do DAG
 
 ## Como usar
 
@@ -20,15 +21,52 @@ Gera os 4 artefatos a partir do `DARE/DESIGN.md`:
 
 Obrigatório. Se não existir, peça para rodar `/dare-design` primeiro.
 
+Extraia e memorize para uso neste comando:
+- Stack técnica (linguagem, framework, versões)
+- Requisitos funcionais priorizados (RF-*)
+- Requisitos de segurança (RS-*)
+- Integrações externas confirmadas
+- Restrições e escopo
+
 ### 2. Gerar `DARE/BLUEPRINT.md`
 
-- Stack tecnológico detalhado (versões, libs)
-- Módulos e responsabilidades
-- Contratos de API (endpoints, schemas em OpenAPI)
-- Modelo de dados (tabelas, índices, relações)
-- Decisões arquiteturais com justificativa
-- Estratégia de testes
-- Estratégia de deploy
+Siga o template `templates/BLUEPRINT-template.md`. Seções obrigatórias:
+
+**2.1 Visão Geral da Arquitetura**
+- Diagrama Mermaid da arquitetura
+- Tabela de decisões arquiteturais com justificativa (não apenas "escolha X")
+
+**2.2 Stack Técnica Definida** — versões fixas, não ranges
+
+**2.3 Estrutura de Pastas** — árvore completa dos arquivos que serão criados
+
+**2.4 Modelo de Dados** — entidades, campos tipados, relacionamentos, índices necessários
+
+**2.5 Contratos de API** — tabela completa: método, rota, auth, request body, response, status codes
+
+**2.6 Plano de Execução (Fases)** — cada fase com:
+- Nome e objetivo
+- **Critério de DONE** — comportamento verificável e testável (não "código feito")
+- Lista de entregáveis concretos
+
+  > **Fase 1 é sempre containerização** (Dockerfile + docker-compose + healthcheck)
+  > **Fase N-1 é sempre auditoria de segurança e dependências**
+
+**2.7 Validation Gates 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 | verificar imports | `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` |
+
+**2.8 Controles de Segurança** — checklist com todos os RS-* do DESIGN mapeados para tasks específicas
+
+**2.9 Estratégia de Testes** — unitários + integração + segurança (auditoria de deps) + E2E se frontend
+
+**2.10 Estratégia de Deploy** — por ambiente com branch, trigger e infra
 
 ### 3. Gerar `DARE/dare-dag.yaml` (grafo executável)
 
@@ -39,44 +77,38 @@ title: "<Nome do Projeto> - Development Tasks"
 version: "1.0.0"
 
 limits:
-  parent_context_chars: 2000   # snippet de output de cada pai injetado no filho
-  task_output_chars: 4000      # cap do output capturado por task
-  timeout_seconds: 600         # AbortController por task
+  parent_context_chars: 2000
+  task_output_chars: 4000
+  timeout_seconds: 600
 
 models:
   cursor:      { HIGH: gpt-5.3-codex,     MED: composer-2,       LOW: auto-low }
-  claude:      { HIGH: claude-sonnet-4-5, MED: claude-haiku-4,   LOW: claude-haiku-4 }
+  claude:      { HIGH: claude-sonnet-4-6, MED: claude-haiku-4-5, LOW: claude-haiku-4-5 }
   antigravity: { HIGH: gemini-2.5-pro,    MED: gemini-2.5-flash, LOW: gemini-2.5-flash }
 
 tasks:
   - id: task-001
-    title: "Setup project structure"
+    title: "Containerização — Dockerfile + docker-compose"
     depends_on: []
     complexity: LOW
     spec_file: EXECUTION/task-001.md
     subtask_prompt: |
-      <prompt completamente self-contained — o subagente vê só este texto
-      mais snippets de até 2000 chars de cada pai>
+      <prompt completamente self-contained>
 ```
 
-**Regras inegociáveis ao construir o DAG:**
+**Regras inegociáveis:**
 
 - `id` em kebab-case e único
-- `depends_on` **mínimo** — só adicione quando a task filha *literalmente*
-  não pode começar sem o output da pai (arquivo, schema, decisão exportada)
-- `subtask_prompt` totalmente self-contained — não vale "use o padrão da
-  task-001"
-- Pelo menos 2 tasks no rank 0 (`depends_on: []`) para haver paralelismo
-- Cadeia linear (`001→002→003→...`) é antipattern — reanalise
-- `complexity` honesta: `HIGH` só para lógica crítica/segurança
-- Output cap de 4000 chars: se a task gera muito, escreva em arquivo e
-  retorne só resumo + caminhos
-- **A primeira task deve containerizar a aplicação** (Dockerfile + compose
-  + healthcheck) — sem isso o Ralph Loop automático não tem onde rodar
-- **NÃO crie task "Ralph Loop final" / "Hardening" / "QA final"** — o
-  Ralph Loop roda em CADA `dare execute --complete`, automaticamente
-- **Tests com assertions reais** — `assertTrue(true)` quebra o gate `test`
-  e a task vai para FAILED
+- `depends_on` **mínimo** — só quando a task filha literalmente não pode começar sem o output da pai
+- `subtask_prompt` totalmente self-contained — não use "siga o padrão da task-001"
+- Pelo menos 2 tasks no rank 0 (`depends_on: []`) para haver paralelismo real
+- Cadeia linear (`001→002→003→...`) é antipattern — reanalise o grafo
+- `complexity: HIGH` apenas para lógica de segurança crítica, algoritmos complexos ou integrações externas arriscadas
+- **task-001 = containerização** sempre
+- **task-N-1 ou task-N = auditoria de segurança + dependências** (sem CVE HIGH/CRITICAL)
+- **NÃO crie task "Ralph Loop final" / "QA final"** — o Ralph Loop roda em CADA `--complete`
+- **NÃO crie task "Refactoring geral"** — refactoring faz parte de cada task
+- Testes com assertions reais — `assertTrue(true)` quebra o gate e a task vai para FAILED
 
 ### 4. Gerar `DARE/TASKS.md` (visão humana)
 
@@ -91,78 +123,52 @@ tasks:
 
 | ID       | Título                    | Status      | Depends On       | Complexity |
 |----------|---------------------------|-------------|------------------|------------|
-| task-001 | Setup project structure   | ⏳ PENDING  | —                | LOW        |
+| task-001 | Containerização           | ⏳ PENDING  | —                | LOW        |
 | task-002 | DB migrations             | ⏳ PENDING  | —                | MED        |
-| task-003 | Auth controllers          | ⏳ PENDING  | task-001, 002    | HIGH       |
+| task-003 | Auth endpoints            | ⏳ PENDING  | task-001, 002    | HIGH       |
 ```
 
 ### 5. Gerar `DARE/EXECUTION/task-<id>.md` (uma por task)
 
-Para CADA task em `dare-dag.yaml`, crie a spec correspondente seguindo
-`templates/TASK-SPEC-template.md`:
-
-- **Objetivo** claro
-- **Arquivos a criar/modificar**
-- **Validation Gates** específicos da stack (PHPUnit, Pytest, Vitest, cargo test)
-- **Testes esperados**
-- **Considerações de segurança**
-- **Próxima task** sugerida
+Para CADA task, use o template `templates/TASK-SPEC-template.md`:
+- Objetivo verificável (não uma ação, mas um estado observável)
+- Arquivos a criar/modificar (tabela)
+- Implementação passo a passo
+- **Considerações de segurança** (seção obrigatória mesmo para tasks de infra)
+- **Validation Gates** específicos da stack (build + test + lint + audit se nova dep)
+- Critérios de DONE explícitos
 
-O `subtask_prompt` no YAML pode referenciar `spec_file: EXECUTION/task-001.md`
-para que o subagente leia a spec na hora de executar.
+### 6. Validar consistência dos 5 artefatos
 
-### 6. Validar consistência dos 4 artefatos
-
-Antes de entregar:
 - [ ] Mesmos `id`s em `TASKS.md`, `dare-dag.yaml` e `EXECUTION/task-*.md`
-- [ ] Mesmas `depends_on` nos três
-- [ ] Mesmas `complexity`
-- [ ] Sem ciclos
+- [ ] Mesmas `depends_on` nos três artefatos
+- [ ] Mesma `complexity` nos três artefatos
+- [ ] Sem ciclos no DAG
 - [ ] Pelo menos 2 tasks no rank 0
-- [ ] Cada `subtask_prompt` executável sem contexto adicional
-
-### 7. Regenerar a visualização do DAG
+- [ ] task-001 é containerização
+- [ ] Existe task de auditoria de segurança/dependências
+- [ ] Cada `subtask_prompt` é executável sem contexto adicional
 
-Depois de salvar o `dare-dag.yaml`, rode:
+### 7. Regenerar visualização do DAG
 
 ```bash
 dare dag viz -o DARE/dag-graph.mmd
 ```
 
-Isso reescreve `DARE/dag-graph.mmd` (Mermaid) refletindo o grafo atualizado.
-O usuário pode abrir no editor com Markdown Preview Mermaid para ver o
-grafo estático com cores por status antes de executar.
-
 ### 8. Aguardar aprovação humana
 
-**Não execute nenhuma task** até o usuário revisar e aprovar os 5 artefatos
-(BLUEPRINT, TASKS, dare-dag.yaml, EXECUTION/task-*, dag-graph.mmd).
-
-## Templates disponíveis
-
-- `templates/BLUEPRINT-template.md`
-- `templates/TASKS-template.md`
-- `templates/TASK-SPEC-template.md`
+**Não execute nenhuma task** até o usuário revisar e aprovar os 5 artefatos.
 
 ## Próximos passos
 
-Após aprovação humana:
+Após aprovação:
 
 ```bash
-# Paralelo (recomendado)
 dare execute --parallel --runner claude
-
-# Sequencial (debug)
-dare execute --runner claude
-
-# Task única
-dare execute --task task-003 --runner claude
+dare execute --runner claude          # sequencial (debug)
+dare execute --task task-003 --runner claude  # task única
 ```
 
-Ou pelos slash commands:
-
-- `/dare-dag-run` — executa o DAG completo em paralelo
-- `/dare-execute task-001` — executa uma task específica
-- `/dare-tasks` — mostra status atual das tasks
+Ou slash commands: `/dare-dag-run` · `/dare-execute task-001` · `/dare-tasks`
 
 $ARGUMENTS

package/templates/ide/claude/.claude/commands/dare-design.md

@@ -6,50 +6,64 @@ Gera ou atualiza o `DARE/DESIGN.md` a partir de uma descrição do projeto ou fe
 
 ```
 /dare-design Quero uma API REST de autenticação com JWT e refresh token
-/dare-design Adicionar endpoint de upload de arquivos com validação
+/dare-design Adicionar módulo de pagamentos com Stripe e webhook
 ```
 
 ## O que fazer
 
-1. **Leia o contexto atual do projeto:**
-   - `package.json` / `composer.json` / `Cargo.toml` / `requirements.txt` para entender stack
-   - Estrutura de pastas existente
-   - `DARE/DESIGN.md` se já existir (não sobrescreva sem autorização)
+### 1. Leia o contexto atual do projeto
 
-2. **Crie ou atualize `DARE/DESIGN.md` com:**
-   - **Descrição** clara do que será construído
-   - **Objetivos** mensuráveis (use checkboxes `- [ ]`)
-   - **Restrições** técnicas, de negócio e de tempo
-   - **Critérios de sucesso** verificáveis
-   - **Stakeholders** e personas afetadas
-   - **Riscos** identificados
+- `package.json` / `composer.json` / `Cargo.toml` / `go.mod` / `requirements.txt` — stack atual
+- Estrutura de pastas existente
+- `DARE/DESIGN.md` se já existir — não sobrescreva sem aprovação explícita do usuário
 
-3. **Use o template** em `templates/DESIGN-template.md` se disponível
+### 2. Gere `DARE/DESIGN.md` com as seguintes seções obrigatórias
 
-4. **Confirme com o usuário** antes de prosseguir para a fase de Architect
+**2.1 Descrição** — 3 a 5 frases claras: o que é, qual problema resolve, quem usa.
 
-## Formato esperado do DESIGN.md
+**2.2 Objetivos e Métricas de Sucesso** — tabela numerada (O-01, O-02…) com métrica verificável e meta numérica para cada objetivo. Evite objetivos vagos como "melhorar performance" — use "p99 < 200 ms".
 
-```markdown
-# DESIGN: <Nome do Projeto/Feature>
+**2.3 Stakeholders** — tabela: papel, nome/time, interesse principal.
 
-## Descrição
-<O que será construído e por quê>
+**2.4 Requisitos Funcionais** — tabela numerada (RF-01, RF-02…) com prioridade MUST/SHOULD/COULD e critério de aceite verificável para cada um.
 
-## Objetivos
-- [ ] Objetivo mensurável 1
-- [ ] Objetivo mensurável 2
+**2.5 Requisitos Não-Funcionais** — tabela numerada (RNF-01…) cobrindo: performance, disponibilidade, segurança (autenticação, rate limiting, segredos), observabilidade, manutenibilidade.
 
-## Restrições
-- Técnicas: <stack, performance, etc>
-- Negócio: <prazo, budget, regulatórias>
+**2.6 Requisitos de Segurança** — tabela numerada (RS-01…). Inclua **sempre**:
+- RS-01: validação de entrada (OWASP A03)
+- RS-02: proteção de dados sensíveis / hash de senhas (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
+- Adicione requisitos específicos do domínio do projeto
 
-## Critérios de Sucesso
-- <Critério verificável 1>
-- <Critério verificável 2>
+**2.7 Stack Técnica** — tabela por camada com tecnologia e versão.
 
-## Riscos
-- <Risco 1 e mitigação>
-```
+**2.8 Integrações Externas** — tabela: sistema, tipo, protocolo, direção, dados trocados, responsável. Inclua apenas integrações confirmadas; marque incertas como "A confirmar".
+
+**2.9 Restrições** — prazo, orçamento de infra, limitações técnicas, compliance regulatório.
+
+**2.10 Fora do Escopo (v1)** — lista explícita do que NÃO será feito e o motivo.
+
+**2.11 Riscos e Mitigações** — tabela: risco, probabilidade (Alta/Média/Baixa), impacto (Alto/Médio/Baixo), mitigação concreta.
+
+**2.12 Checklist de Aprovação** — checkboxes para o usuário revisar antes de avançar ao `/dare-blueprint`.
+
+### 3. Use o template em `templates/DESIGN-template.md`
+
+Siga o template fielmente. Não omita seções — use "[A definir]" se a informação não estiver disponível ainda, mas deixe a seção explícita para o usuário preencher.
+
+### 4. Qualidade esperada
+
+O DESIGN.md gerado deve permitir que qualquer engenheiro novo no projeto entenda:
+- **O QUÊ** vai ser construído (requisitos funcionais)
+- **POR QUÊ** (objetivos e métricas)
+- **PARA QUEM** (stakeholders e personas)
+- **O QUE NÃO** vai ser feito (escopo)
+- **QUAIS RISCOS** existem (com mitigação)
+
+### 5. Confirme com o usuário antes de prosseguir
+
+Após gerar o DESIGN.md, apresente um resumo das seções geradas e pergunte se o usuário quer ajustar algo antes de rodar `/dare-blueprint`.
 
 $ARGUMENTS