@dewtech/dare-cli 2.15.0 → 2.17.0

package/templates/ide/antigravity/.agents/skills/dare-review/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: dare-review
+description: Audita uma task DARE implementada — cruza a spec com o código real para detectar stubs, mocks fora de testes, funções vazias, TODOs e validar critério-a-critério se a implementação satisfaz o que a spec prometeu. Use antes de marcar uma task como DONE, ou quando o dev pedir revisão manual. Combina análise estática (via CLI) com verdito semântico (você).
+---
+
+# DARE Review Skill
+
+Você é o auditor de qualidade do método DARE. Seu papel é verificar se uma task implementada **realmente** entrega o que a spec promete — sem stubs, sem mocks em produção, sem funções vazias, sem TODOs pendentes.
+
+## Quando usar esta skill
+
+- Antes de marcar uma task como DONE (gate obrigatório no Definition of Done)
+- Quando `dare review <id>` estático passa mas precisa validação semântica
+- Quando o dev pede revisão manual: "revise a task-034"
+
+## Camada estática vs semântica
+
+O CLI `dare review <id>` já faz a camada **estática**: regex sobre os arquivos detecta TODO/FIXME/stubs/mocks/funções vazias. Esta skill faz a camada **semântica**: critério-a-critério da spec contra a implementação real.
+
+## Como executar
+
+### Passo 1: Rodar a camada estática
+
+```bash
+dare review <task-id> --format json > .dare/review-static-<task-id>.json
+```
+
+Leia o JSON. Se houver erros estáticos, reporte-os primeiro. Geralmente não vale prosseguir com semântica se a estática falhou.
+
+### Passo 2: Carregar contexto
+
+- `DARE/EXECUTION/<task-id>.md` — spec da task
+- Cada arquivo listado na seção 3 ("ARQUIVOS A CRIAR / MODIFICAR")
+- `DARE/BLUEPRINT.md` — contratos de API / modelos
+
+### Passo 3: Auditoria critério-a-critério
+
+Para **cada** item das seções abaixo, marque ✅ / ❌ com evidência (arquivo + linha):
+
+#### 3.1 Objetivo (seção 1 da spec)
+A implementação atinge o estado observável prometido? Encontre evidência concreta.
+
+#### 3.2 Arquivos (seção 3)
+- Todos existem com conteúdo descrito?
+- Arquivos extras suspeitos?
+
+#### 3.3 Implementação (seção 4)
+- Cada passo numerado foi executado?
+- Assinaturas exatas correspondem?
+- Validações têm regras concretas (não "valida email" — a regex específica)?
+
+#### 3.4 Testes (seção 4 — subitem testes)
+- Cada teste listado existe?
+- Tem assertions reais (não `assertTrue(true)`)?
+- Edge cases enumerados cobertos?
+
+#### 3.5 Segurança (seção 5)
+- Input validation conforme spec?
+- Não há secrets/tokens hardcoded?
+- SQL/Command injection mitigado?
+
+#### 3.6 Anti-Stub (seção 7)
+A camada estática já checou. Só anote se encontrar algo que regex não pegaria (ex.: dados hardcoded disfarçados).
+
+### Passo 4: Emitir verdito semântico
+
+Salve em `.dare/review-semantic-<task-id>.json`:
+
+```json
+{
+  "passed": true,
+  "unmetCriteria": [],
+  "notes": "Resumo de 1-3 frases"
+}
+```
+
+Falha:
+
+```json
+{
+  "passed": false,
+  "unmetCriteria": [
+    "Seção 4.3: validação de senha sem regex de força",
+    "Seção 4.4: teste de 'email duplicado' não existe"
+  ],
+  "notes": "2 critérios não atendidos em src/auth/register.ts"
+}
+```
+
+### Passo 5: Rodar o review fundido
+
+```bash
+dare review <task-id> --from-agent .dare/review-semantic-<task-id>.json
+```
+
+Exit code 0 = pode ir para DONE; 1 = não pode.
+
+### Passo 6: Mensagem final
+
+Se passou:
+> ✅ Task aprovada. Marque DONE: `dare execute --complete <task-id>`
+
+Se falhou:
+> ❌ Task não passou. Itens a corrigir: [lista]. Re-rode após corrigir.
+
+## Regras inegociáveis
+
+- **Não invente** que algo está implementado se não viu o código no disco
+- **Não aceite** mocks/stubs em código de produção mesmo que façam testes passar
+- **Mocks são OK** dentro de `*.test.*`, `*.spec.*`, `__tests__/`, `tests/`, `spec/`
+- **Evidência concreta:** sempre cite arquivo + linha para suas conclusões

package/templates/ide/antigravity/.agents/skills/dare-tasks/SKILL.md

@@ -172,6 +172,47 @@ npm run build    # ou cargo build, composer install, etc.
 Task 002: DB migrations
 ```
 
+### Passo 5.1: ANTI-STUB CONTRACT (inegociável)
+
+> Tasks geradas com `subtask_prompt` ou spec genéricos forçam o agente a inventar — e ele vai produzir mock, stub ou esqueleto. **Não é negociável**. O comando `dare review <task-id>` (v2.17+) detecta isso e marca a task como FAILED.
+
+Cada `subtask_prompt` e `EXECUTION/task-<id>.md` deve atender este contrato:
+
+**O `subtask_prompt` deve ser auto-suficiente**
+
+O subagente recebe **apenas** o `subtask_prompt` + snippets de 2000 chars dos pais. Inclua:
+
+- Caminho exato dos arquivos a criar/modificar
+- Assinaturas exatas das funções/endpoints (`fn name(params: T) -> R`)
+- Schema de request/response com tipos
+- Validações específicas (não "validar input" — `email: regex`, `senha: ≥ 8 chars + maiúscula + dígito`)
+- Edge cases enumerados (input vazio, duplicado, expirado, sem permissão)
+- Lista de testes esperados com nome + comportamento
+
+**A `spec_file` deve ter Definition of Done anti-stub:**
+
+```markdown
+## Definition of Done (ANTI-STUB)
+
+- [ ] Nenhum `TODO`, `FIXME`, `XXX` ou `HACK` em arquivos modificados
+- [ ] Nenhuma função vazia (`fn x() {}`, `def x(): pass`, `function x() {}`)
+- [ ] Nenhum `throw new Error('not implemented')`, `unimplemented!()`, `todo!()`, `NotImplementedError`
+- [ ] Nenhum `return null` / `return undefined` / `return {}` como única statement de função pública
+- [ ] Mocks **somente** dentro de `*.test.*`, `*.spec.*`, `__tests__/`, `tests/`, `spec/`
+- [ ] Endpoints retornam dados reais (não fixos / hardcoded)
+- [ ] Cada validação produz erro real com status code correto (testado)
+- [ ] Cada edge case tem teste unitário/integração
+```
+
+**Verificação:** o agente vai rodar `dare review <id>` antes de DONE. Falhou → volta pra revisão.
+
+**Sinais de spec rasa:**
+
+- ❌ "Implementar X" — sem assinatura, sem retorno, sem validações
+- ❌ "Tratar erros adequadamente" — quais erros?
+- ❌ "Adicionar validações" — quais regras?
+- ✅ "Implementar `POST /auth/login` retornando `{ token, refresh }` com 200/401/429"
+
 ### Passo 6: Validar consistência
 
 Antes de entregar, confirme:

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

@@ -85,16 +85,57 @@ Execute **todos** antes de marcar a task como DONE. Se qualquer um falhar, leia
 
 ---
 
-## 7. CRITÉRIOS DE DONE
+## 7. PADRÕES PROIBIDOS (ANTI-STUB / ANTI-MOCK)
 
-- [ ] Todos os 4 validation gates passaram sem erros
-- [ ] Testes cobrem caminho feliz + erros + edge cases da seção 4
+> Esta seção é **inegociável**. O comando `dare review` (v2.17+) escaneia o código modificado por esta task e reprova se encontrar qualquer padrão abaixo.
+
+### Em código de produção (qualquer arquivo **fora** de `*.test.*`, `*.spec.*`, `__tests__/`, `tests/`, `spec/`)
+
+- ❌ **TODO / FIXME / XXX / HACK** — qualquer um desses marcadores em comentário
+- ❌ **Função vazia** — `fn x() {}`, `function x() {}`, `def x(): pass`, `def x(): ...`
+- ❌ **Stub explícito** — `throw new Error('not implemented')`, `unimplemented!()`, `todo!()`, `raise NotImplementedError`
+- ❌ **Retorno-fantasma** — `return null` / `return undefined` / `return {}` / `return []` como **única** statement de função pública declarada nesta task
+- ❌ **Mocks fora de testes** — `jest.fn()`, `sinon.stub()`, `mockReturnValue`, dados hardcoded fingindo ser do banco, fixtures injetadas em controllers/services
+- ❌ **Comentário de placeholder** — `// implement later`, `# placeholder`, `// stub`, `// FIXME implement`
+
+### Mocks são permitidos APENAS em
+
+- Arquivos de teste (`*.test.*`, `*.spec.*`, `__tests__/`, `tests/`, `spec/`)
+- Seeds / fixtures dentro de `database/seeders/`, `tests/fixtures/`
+- Helpers explicitamente marcados como auxiliares de teste
+
+### Verificação automática
+
+Antes de marcar a task como DONE, rode:
+
+```bash
+dare review <task-id>
+```
+
+Output esperado:
+
+```
+✅ task-XYZ: nenhum padrão proibido detectado em N arquivos modificados.
+```
+
+Se a review falhar, a task **não pode** ir para DONE — corrija os achados e re-rode.
+
+---
+
+## 8. CRITÉRIOS DE DONE
+
+- [ ] Todos os 4 validation gates passaram sem erros (build + test + lint + audit)
+- [ ] Testes cobrem caminho feliz + erros enumerados + 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 review <task-id>` passou** (seção 7 — sem stubs, mocks, TODOs)
+- [ ] Cada validação declarada na spec tem teste demonstrando o erro real (não placeholder)
+- [ ] Cada edge case enumerado tem teste cobrindo
+- [ ] Endpoints retornam dados reais do banco/service, não hardcoded
 - [ ] `DARE/TASKS.md` atualizado com status `DONE`
 
 ---
 
-## 8. PRÓXIMA TASK SUGERIDA
+## 9. PRÓXIMA TASK SUGERIDA
 
 `[task-id]` — [título] _(desbloqueada após conclusão desta task)_

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

@@ -66,6 +66,62 @@ Siga o template `templates/BLUEPRINT-template.md`. Seções obrigatórias:
 
 **2.11 Checklist de Aprovação** — checkboxes para o usuário revisar antes de prosseguir
 
+---
+
+## 🚫 ANTI-STUB CONTRACT (regra inegociável)
+
+> **Por que existe esta seção:** o `/dare-tasks` que vem depois usa este Blueprint como **única fonte de verdade**. Se um endpoint, função ou regra ficar genérico aqui, o agente que implementar a task **será forçado a inventar** — e vai produzir mocks, stubs e esqueletos para "preencher o vazio". Detalhe agora.
+>
+> Tasks que produzem mock/stub/skeleton **falham** no `dare review` (introduzido na v2.17) e bloqueiam o `dare execute --complete`.
+
+Para **cada** endpoint, função pública, evento ou job declarado no Blueprint, especifique de forma **executável**:
+
+### Para endpoints HTTP/RPC
+
+- **Assinatura completa:** método, path, headers obrigatórios, content-type
+- **Request schema:** todos os campos com tipo, restrições (min/max/regex), opcionalidade
+- **Response schema por status code:** estrutura para 2xx, 4xx, 5xx — não apenas "200 OK"
+- **Validações server-side:** lista exaustiva de regras (`email único`, `senha ≥ 8 chars + 1 maiúscula + 1 dígito`, etc.)
+- **Edge cases enumerados:** o que acontece com input vazio, duplicado, expirado, sem permissão, com dados inconsistentes
+- **Side effects:** que tabelas/filas/caches/emails são tocados — em ordem
+- **Exemplo concreto (não placeholder):** payload real, response real
+
+### Para funções de domínio / services
+
+- **Assinatura tipada** (`fn name(args: Types) -> ReturnType` ou equivalente)
+- **Pré-condições** verificáveis (estado obrigatório do banco/cache/etc.)
+- **Pós-condições** verificáveis (o que muda no sistema após retornar OK)
+- **Estados de erro** com tipo de exceção/Result/Either esperado
+- **Comportamento em concorrência** quando relevante (idempotência, locking, retry)
+
+### Para jobs / event handlers / workers
+
+- **Trigger:** evento, cron, fila — incluir o **nome canônico**
+- **Payload schema** com tipos
+- **Retry policy** (backoff, max attempts, DLQ)
+- **Idempotência:** chave + estratégia
+- **SLA / timeout**
+
+### Para modelos de dados
+
+- Cada campo: tipo, nullable, default, constraints (unique, fk, check), índices
+- Triggers ou hooks (soft-delete, audit, encryption-at-rest)
+- Estado inicial / seed obrigatório (se aplicável)
+
+### Critério de "Blueprint detalhado o suficiente"
+
+Antes de salvar, valide internamente — se a resposta a **qualquer** pergunta abaixo for "não", o Blueprint ainda está raso e precisa ser expandido:
+
+- [ ] Para cada endpoint, um humano não-familiarizado consegue escrever request/response sem perguntar nada?
+- [ ] Para cada função pública, está claro **o que retorna** em todos os caminhos (sucesso + erros enumerados)?
+- [ ] Edge cases foram **enumerados** ou só listados como "tratar edge cases"?
+- [ ] Cada validação tem uma regra concreta (não "validar email" — `^[a-z0-9._%+-]+@...`)?
+- [ ] Cada decisão arquitetural tem **justificativa** (não só "escolhemos X")?
+
+**Anti-padrão a evitar:** seções como _"implementar autenticação"_ ou _"validar dados"_ — isso vai virar stub. Especifique **qual** algoritmo, **quais** campos, **quais** regras.
+
+---
+
 ### 3. Salvar e aguardar aprovação humana
 
 Salve `DARE/BLUEPRINT.md` e informe:

package/templates/ide/claude/.claude/commands/dare-dag-build.md

@@ -65,6 +65,47 @@ tasks:
 - Cadeia linear é antipattern
 - `complexity` honesta
 
+### 3.1 ANTI-STUB CONTRACT (inegociável)
+
+> Tasks geradas com `subtask_prompt` ou spec genéricos forçam o agente a inventar — e ele vai produzir mock, stub ou esqueleto. **Não é negociável**. O comando `dare review <task-id>` (v2.17+) detecta isso e marca a task como FAILED.
+
+Cada `subtask_prompt` e `EXECUTION/task-<id>.md` deve atender este contrato:
+
+**O `subtask_prompt` deve ser auto-suficiente**
+
+O subagente recebe **apenas** o `subtask_prompt` + snippets de 2000 chars dos pais. Tudo que ele precisa para implementar **sem inventar** deve estar ali ou na `spec_file`. Inclua:
+
+- Caminho exato dos arquivos a criar/modificar
+- Assinaturas exatas das funções/endpoints (`fn name(params: T) -> R`)
+- Schema de request/response com tipos
+- Validações específicas (não "validar input" — `email: regex /^.../`, `senha: ≥ 8 chars + 1 maiúscula + 1 dígito`)
+- Edge cases enumerados (input vazio, duplicado, expirado, sem permissão)
+- Lista de testes esperados com nome + comportamento
+
+**A `spec_file` (`EXECUTION/task-<id>.md`) deve ter Definition of Done anti-stub:**
+
+```markdown
+## Definition of Done (ANTI-STUB)
+
+- [ ] Nenhum `TODO`, `FIXME`, `XXX` ou `HACK` em arquivos modificados
+- [ ] Nenhuma função vazia (`fn x() {}`, `def x(): pass`, `function x() {}`)
+- [ ] Nenhum `throw new Error('not implemented')`, `unimplemented!()`, `todo!()`, `NotImplementedError`
+- [ ] Nenhum `return null` / `return undefined` / `return {}` como única statement de função pública
+- [ ] Mocks **somente** dentro de `*.test.*`, `*.spec.*`, `__tests__/`, `tests/`, `spec/` — NUNCA em código de produção
+- [ ] Todos os endpoints declarados na seção 3 retornam dados reais (não fixos / hardcoded)
+- [ ] Cada validação da spec produz erro real com status code correto (testado)
+- [ ] Cada edge case da spec tem teste unitário ou integração demonstrando comportamento
+```
+
+**Verificação automatizável:** o agente vai rodar `dare review <id>` antes de marcar DONE. Se a review falhar, a task volta para revisão.
+
+**Sinais de spec rasa** (auto-validar antes de salvar):
+
+- ❌ "Implementar X" — sem assinatura, sem retorno, sem validações
+- ❌ "Tratar erros adequadamente" — quais erros? como? que código?
+- ❌ "Adicionar validações" — quais regras?
+- ✅ "Implementar `POST /auth/login` retornando `{ token: string, refresh: string }` com 200 se credenciais válidas, 401 se inválidas, 429 se rate limit"
+
 ### 4. Validar consistência com `EXECUTION/task-*.md`
 
 Se uma spec existe em `DARE/EXECUTION/task-<id>.md`:

package/templates/ide/claude/.claude/commands/dare-dag-viz.md

@@ -0,0 +1,197 @@
+# /dare-dag-viz — Visualizar DAG com Excalidraw
+
+Gera diagrama interativo `.excalidraw` a partir do `dare-dag.yaml` atual, com cores semânticas por complexidade e status visual das tasks.
+
+## O que faz
+
+1. **Lê** `DARE/dare-dag.yaml` (grafo de tasks + dependências)
+2. **Mapeia** cada task para um retângulo Excalidraw com:
+   - Cor baseada em `complexity` (LOW=azul, MED=laranja, HIGH=rosa)
+   - Status visual (PENDING/RUNNING/DONE/FAILED)
+   - ID + nome da task
+3. **Agrupa** tasks por `rank` em colunas verticais (swim lanes)
+4. **Cria** setas para cada dependência (`depends_on`)
+5. **Salva** em `DARE/dag-graph.excalidraw`
+
+Output é um arquivo **editável e interativo** — abre direto em https://excalidraw.com.
+
+## Convenções visuais
+
+Referência: `/docs/DESIGN-TOKENS-EXCALIDRAW.md`
+
+**Cores por complexidade:**
+- 🔵 **Azul** (#e3f2fd) = LOW
+- 🟠 **Laranja** (#fff3e0) = MEDIUM
+- 🔴 **Rosa** (#fce4ec) = HIGH
+
+**Status:**
+- ⏳ PENDING = cinza, stroke normal
+- ⚙️ RUNNING = azul, stroke pontilhado
+- ✅ DONE = verde
+- ❌ FAILED = vermelho
+
+**Posicionamento:**
+- Cada task ocupa 120×60px
+- Tasks no mesmo rank ficam lado a lado (swim lane)
+- Setas conectam dependências
+
+## Exemplo de output
+
+Arquivo `DARE/dag-graph.excalidraw` com estrutura:
+
+```
+Rank 1
+├── task-001 (LOW, DONE)
+├── task-002 (HIGH, PENDING)
+
+Rank 2
+├── task-003 (MEDIUM, RUNNING) ← depende de task-001
+├── task-004 (LOW, PENDING) ← depende de task-001
+
+Rank 3
+└── task-005 (HIGH, PENDING) ← depende de task-003 e task-004
+```
+
+## Como usar
+
+### Primeira vez
+
+```bash
+/dare-dag-viz
+```
+
+Claude Code vai:
+1. Ler `DARE/dare-dag.yaml`
+2. Gerar JSON `.excalidraw`
+3. Salvar em `DARE/dag-graph.excalidraw`
+4. Output: "✅ DAG gerado — abra em https://excalidraw.com"
+
+### Atualizar após mudanças
+
+Sempre que você atualiza `dare-dag.yaml`:
+
+```bash
+/dare-dag-viz
+```
+
+Isso regenera o diagrama com as novas tasks/dependências.
+
+### Abrir e editar
+
+1. Acesse https://excalidraw.com
+2. File → Open → selecione `DARE/dag-graph.excalidraw`
+3. Edite livremente:
+   - Mova elementos
+   - Customize cores/textos
+   - Adicione anotações
+4. Salve no mesmo arquivo
+
+Dica: Se editou manualmente e quer regenerar com `dare-dag-viz` de novo, faça backup antes.
+
+## Detalhes técnicos
+
+### Estrutura do JSON gerado
+
+```json
+{
+  "elements": [
+    {
+      "id": "task-001",
+      "type": "rectangle",
+      "x": 20, "y": 20,
+      "width": 120, "height": 60,
+      "backgroundColor": "#e3f2fd",
+      "stroke": "#1976d2",
+      "text": "task-001\nSetup Auth\n[LOW]",
+      "fontSize": 12,
+      "roundness": { "type": 2, "value": 6 }
+    },
+    {
+      "type": "arrow",
+      "startBinding": { "elementId": "task-001" },
+      "endBinding": { "elementId": "task-003" },
+      "stroke": "#999"
+    }
+  ],
+  "appState": {
+    "gridMode": "grid",
+    "gridSize": 20
+  }
+}
+```
+
+### Algoritmo de posicionamento
+
+1. **Calcular ranks** — depth-first do DAG
+   ```
+   rank = 1 + max(rank of dependencies)
+   ```
+
+2. **Agrupar por rank**
+   ```
+   Rank 1: [task-001, task-002]
+   Rank 2: [task-003, task-004]
+   ```
+
+3. **Posicionar**
+   ```
+   x = 20 + (taskIndex * 140)
+   y = 20 + (rank - 1) * 160
+   ```
+
+4. **Desenhar setas**
+   ```
+   Para cada depends_on: arrow(source → target)
+   ```
+
+## Campos esperados em dare-dag.yaml
+
+```yaml
+tasks:
+  task-001:
+    name: "Setup Auth"
+    complexity: "LOW"           # ← determina cor
+    rank: 1                     # ← se não existir, é calculado
+    depends_on: []              # ← usada para setas
+    status: "DONE"              # ← determina stroke/fill
+    subtask_prompt: "..."       # ← (opcional)
+```
+
+**Campos obrigatórios:** `name`, `complexity`  
+**Campos opcionais:** `rank` (calculado), `status` (default PENDING), `depends_on` (default [])
+
+## Troubleshooting
+
+### "File not found: DARE/dare-dag.yaml"
+Certifique-se de que está em um projeto DARE. Se não, rode:
+```bash
+dare discover
+```
+
+### "JSON inválido"
+Valide seu `dare-dag.yaml`:
+```bash
+dare dag validate
+```
+
+### Diagrama muito grande/pequeno
+Abra em Excalidraw e ajuste com Ctrl+Mouse ou pinch zoom.
+
+## Próximos passos
+
+- 🎨 Customize as cores em `docs/DESIGN-TOKENS-EXCALIDRAW.md`
+- 📤 Exporte para PNG com botão "Export to Image" no Excalidraw
+- 🔄 Atualize após cada `dare design` ou `dare execute`
+- 📊 Compartilhe com stakeholders (Excalidraw é colaborativo)
+
+## Referência de design
+
+Ver `/docs/DESIGN-TOKENS-EXCALIDRAW.md` para detalhes de cores, fonts, tamanhos, e créditos.
+
+## Licença
+
+Esta skill é parte do DARE CLI e está sob AGPL v3.
+
+Você pode usar, modificar e compartilhar — mas contribuições voltam ao DARE.
+
+Créditos: Inspiração na [Excalidraw Diagram Skill](https://github.com/coleam00/excalidraw-diagram-skill) por Cole Medin.

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

@@ -0,0 +1,145 @@
+# Comando: /dare-refine
+
+## Descrição
+
+Analisa a complexidade de uma task e, quando alta, **quebra em sub-tasks menores** com escopo bem delimitado. Pode ser chamada:
+
+- Automaticamente pela skill `dare-tasks` logo após gerar o DAG (para cada task ≥ MED)
+- Manualmente pelo dev: `/dare-refine task-034`
+- Após mudança de escopo: quando o BLUEPRINT mudou e uma task ficou grande demais
+
+A camada determinística (heurística de complexidade) já é feita pelo CLI: `dare refine <id>`. Este comando adiciona a camada **semântica** — você lê a spec, decide se a quebra é necessária e, se for, produz sub-tasks coerentes.
+
+## Quando rodar
+
+- Logo após `/dare-tasks` para cada task com complexity HIGH no `dare-dag.yaml`
+- Quando o dev pede explicitamente: `/dare-refine task-034`
+- Quando você gerou uma task e ela "te parece grande" mesmo marcada MED — confie no instinto
+
+## Como executar
+
+### 1. Validar argumento
+
+`$ARGUMENTS` deve ter o `task-id`. Se vazio, peça.
+
+### 2. Rodar a camada determinística
+
+```bash
+dare refine $ARGUMENTS --split --format json > .dare/refine-$ARGUMENTS.json
+```
+
+Esse JSON traz:
+- `report.score` e `report.level` (LOW/MED/HIGH/CRITICAL)
+- `report.signals` — explica por que pontuou alto/baixo
+- `report.recommendsSplit` — true se HIGH ou CRITICAL
+- `proposal.subtasks` — quebra inicial baseada em diretórios (chute coarse)
+
+### 3. Decidir se vale quebrar
+
+Critérios para **quebrar**:
+
+- ✅ `recommendsSplit: true` da heurística (HIGH/CRITICAL)
+- ✅ Mais de 6 arquivos a criar/modificar
+- ✅ Mistura responsabilidades fortes (ex.: cria modelo + escreve controller + escreve teste + faz migration — split por camada)
+- ✅ Toca código que outra task ainda não criou (deveria ser depois)
+- ✅ Inclui refactor + feature nova juntos
+- ✅ Tem keyword "pesada" (refactor, migrate, integrate) E score MED+
+
+Critérios para **manter inteira**:
+
+- ✅ Score LOW e até MED
+- ✅ Todos os arquivos pertencem ao mesmo módulo/feature
+- ✅ Cabe em uma conversa única do agente (15–60 min de trabalho efetivo)
+
+### 4. Se decidir quebrar — produzir sub-tasks coerentes
+
+Não use a `proposal.subtasks` da CLI sem revisão — ela agrupa por diretório, o que nem sempre faz sentido semantico. **Reagrupe por responsabilidade**:
+
+| Eixo de split | Quando aplicar |
+|---|---|
+| **Por camada** | Modelo / Controller / Service / Test ficam em tasks separadas se cada um é grande |
+| **Por endpoint** | Task original tinha 4 endpoints REST → 4 sub-tasks de 1 endpoint cada |
+| **Por feature** | Auth tinha "register + login + refresh + logout" → split por verbo |
+| **Refactor + feature** | Quebra em "1. refactor X para preparar terreno" + "2. adiciona feature Y em cima" |
+| **Migration + código** | "1. migration + seeds" + "2. código que usa o novo schema" |
+
+Cada sub-task deve:
+
+- Ter `subtask_prompt` auto-suficiente (assinaturas exatas, validações, edge cases — o Anti-Stub Contract aplica)
+- Ter spec_file própria em `DARE/EXECUTION/<sub-id>.md`
+- Ter `depends_on` mínimo mas correto (sub-tasks da mesma família geralmente dependem em ordem)
+- Ter complexity honesta — se a sub ainda ficar HIGH, quebra de novo
+
+### 5. Emitir verdito + plano
+
+Salve em `.dare/refine-verdict-$ARGUMENTS.json`:
+
+```json
+{
+  "manageable": false,
+  "reasons": [
+    "Score 18 (HIGH) — 7 endpoints + migration + 12 testes no mesmo escopo",
+    "Mistura refactor de service layer com novos endpoints"
+  ],
+  "proposedSubtasks": [
+    {
+      "id": "task-034a",
+      "title": "Refactor UserService para suportar profile_settings",
+      "files": ["src/services/UserService.ts", "tests/services/UserService.test.ts"],
+      "rationale": "Refactor isolado antes da feature — gates passam sem mexer em controllers",
+      "estimatedLevel": "MED"
+    },
+    {
+      "id": "task-034b",
+      "title": "Endpoints GET/PATCH /users/me/profile",
+      "files": ["src/controllers/profile.ts", "tests/controllers/profile.test.ts"],
+      "rationale": "Endpoints novos consumindo o serviço refatorado",
+      "estimatedLevel": "MED"
+    }
+  ]
+}
+```
+
+Se a task **é** manuseável (não precisa quebrar):
+
+```json
+{
+  "manageable": true,
+  "reasons": ["Score 7 (MED), 4 arquivos no mesmo módulo, 6 testes — cabe em uma conversa"]
+}
+```
+
+### 6. Aplicar o split
+
+Se quebrou:
+
+1. **Edite** `DARE/dare-dag.yaml` substituindo a task original pelas sub-tasks
+2. **Crie** as specs novas em `DARE/EXECUTION/<sub-id>.md` (use `templates/TASK-SPEC-template.md` — seguindo o Anti-Stub Contract!)
+3. **Atualize** `DARE/TASKS.md` (visão humana) refletindo a quebra
+4. **Regenere** o Mermaid: `dare dag viz -o DARE/dag-graph.mmd`
+5. **Marque** a task original como SPLIT (não deletar — preservar histórico) ou remover e referenciar no header das sub-tasks
+
+### 7. Mensagem ao usuário
+
+Se manteve inteira:
+> ✅ Task `$ARGUMENTS` está bem-dimensionada (score X, level Y). Sem split necessário.
+
+Se quebrou:
+> 🪓 Task `$ARGUMENTS` quebrada em N sub-task(s):
+> - `<id>a`: <título>
+> - `<id>b`: <título>
+> ...
+>
+> Specs criadas em `DARE/EXECUTION/`. Revise antes de executar:
+> ```bash
+> dare validate                    # verifica DAG
+> dare dag viz                     # confirma grafo
+> dare execute --next              # roda a primeira sub-task pronta
+> ```
+
+## Regras inegociáveis
+
+- **Não quebre tasks LOW** — overhead não vale a pena
+- **Não invente dependências** — sub-tasks da mesma família frequentemente são sequenciais, não falsamente paralelas
+- **Cada sub-task precisa ser independentemente testável** — se você precisa rodar A para testar B, A precisa ser parent de B no DAG
+- **Anti-Stub Contract aplica em cada sub-task** — não relaxa critérios só porque é menor