@dewtech/dare-cli 2.16.0 → 2.17.0

package/dist/utils/version-compare.js

@@ -0,0 +1,47 @@
+/**
+ * Minimal semver comparison utilities for `dare update`.
+ *
+ * We don't pull in `semver` from npm because the comparisons we need are
+ * trivial (compare `MAJOR.MINOR.PATCH` triples, no ranges, no pre-releases)
+ * and the CLI already ships a slim dependency tree.
+ */
+const SEMVER_RE = /^(\d+)\.(\d+)\.(\d+)(?:[-+].*)?$/;
+/**
+ * Parse a semver-like string. Throws on invalid input so callers don't end up
+ * silently comparing `NaN`s.
+ */
+export function parseVersion(input) {
+    const match = SEMVER_RE.exec(input.trim());
+    if (!match) {
+        throw new Error(`Invalid version string: "${input}"`);
+    }
+    return {
+        major: Number(match[1]),
+        minor: Number(match[2]),
+        patch: Number(match[3]),
+    };
+}
+/** Return `-1` if `a < b`, `0` if equal, `1` if `a > b`. */
+export function compareVersions(a, b) {
+    const va = parseVersion(a);
+    const vb = parseVersion(b);
+    if (va.major !== vb.major)
+        return va.major < vb.major ? -1 : 1;
+    if (va.minor !== vb.minor)
+        return va.minor < vb.minor ? -1 : 1;
+    if (va.patch !== vb.patch)
+        return va.patch < vb.patch ? -1 : 1;
+    return 0;
+}
+/** True when `version` is strictly greater than `baseline`. */
+export function isNewerThan(version, baseline) {
+    return compareVersions(version, baseline) === 1;
+}
+/**
+ * Sort version strings ascending (oldest first). Caller-owned array stays
+ * untouched.
+ */
+export function sortVersionsAscending(versions) {
+    return [...versions].sort(compareVersions);
+}
+//# sourceMappingURL=version-compare.js.map

package/dist/utils/version-compare.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"version-compare.js","sourceRoot":"","sources":["../../src/utils/version-compare.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAQH,MAAM,SAAS,GAAG,kCAAkC,CAAC;AAErD;;;GAGG;AACH,MAAM,UAAU,YAAY,CAAC,KAAa;IACxC,MAAM,KAAK,GAAG,SAAS,CAAC,IAAI,CAAC,KAAK,CAAC,IAAI,EAAE,CAAC,CAAC;IAC3C,IAAI,CAAC,KAAK,EAAE,CAAC;QACX,MAAM,IAAI,KAAK,CAAC,4BAA4B,KAAK,GAAG,CAAC,CAAC;IACxD,CAAC;IACD,OAAO;QACL,KAAK,EAAE,MAAM,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC;QACvB,KAAK,EAAE,MAAM,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC;QACvB,KAAK,EAAE,MAAM,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC;KACxB,CAAC;AACJ,CAAC;AAED,4DAA4D;AAC5D,MAAM,UAAU,eAAe,CAAC,CAAS,EAAE,CAAS;IAClD,MAAM,EAAE,GAAG,YAAY,CAAC,CAAC,CAAC,CAAC;IAC3B,MAAM,EAAE,GAAG,YAAY,CAAC,CAAC,CAAC,CAAC;IAC3B,IAAI,EAAE,CAAC,KAAK,KAAK,EAAE,CAAC,KAAK;QAAE,OAAO,EAAE,CAAC,KAAK,GAAG,EAAE,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC;IAC/D,IAAI,EAAE,CAAC,KAAK,KAAK,EAAE,CAAC,KAAK;QAAE,OAAO,EAAE,CAAC,KAAK,GAAG,EAAE,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC;IAC/D,IAAI,EAAE,CAAC,KAAK,KAAK,EAAE,CAAC,KAAK;QAAE,OAAO,EAAE,CAAC,KAAK,GAAG,EAAE,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC;IAC/D,OAAO,CAAC,CAAC;AACX,CAAC;AAED,+DAA+D;AAC/D,MAAM,UAAU,WAAW,CAAC,OAAe,EAAE,QAAgB;IAC3D,OAAO,eAAe,CAAC,OAAO,EAAE,QAAQ,CAAC,KAAK,CAAC,CAAC;AAClD,CAAC;AAED;;;GAGG;AACH,MAAM,UAAU,qBAAqB,CAAC,QAAkB;IACtD,OAAO,CAAC,GAAG,QAAQ,CAAC,CAAC,IAAI,CAAC,eAAe,CAAC,CAAC;AAC7C,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dewtech/dare-cli",
-  "version": "2.16.0",
+  "version": "2.17.0",
   "description": "DARE Framework - CLI, GraphRAG engine, MCP server and shared types in a single package",
   "type": "module",
   "main": "./dist/index.js",

package/templates/UPDATE-MANIFEST.json

@@ -0,0 +1,48 @@
+{
+  "schemaVersion": 1,
+  "releases": {
+    "2.16.0": {
+      "releasedAt": "2026-05-10",
+      "summary": "Excalidraw DAG visualization",
+      "changelog": "Adiciona renderer Excalidraw para visualizar o DAG (tasks + dependências) em diagrama interativo.",
+      "changes": []
+    },
+    "2.17.0": {
+      "releasedAt": "2026-05-16",
+      "summary": "dare update + dare review + dare refine + Anti-Stub Contract",
+      "changelog": "Release grande, três frentes complementares que resolvem três problemas reais:\n\n## 1. `dare update` — sincronizar projeto com CLI\n\nDev atualiza o CLI globalmente (npm install -g @dewtech/dare-cli@latest) e roda `dare update` em cada projeto pra puxar templates / skills / commands novos — sem mexer em DESIGN, BLUEPRINT, TASKS, dare-dag.yaml. UPDATE-MANIFEST.json declarativo lista changes + migrations por release. Backup automático em `.dare/backup-<version>/`. Detecção de customizações por hash SHA-256 (keep / replace / force). Filtro por IDE configurado.\n\nFlags: `--dry-run`, `--yes`, `--force`, `--target <version>`.\n\n## 2. `dare review` + `dare refine` — Anti-stub gates\n\nProblema: tasks marcadas como DONE com código mockado, stubs, esqueletos de função, TODOs pendentes.\n\n`dare review <task-id>`:\n- Camada estática (regex): TODO/FIXME/XXX/HACK, throw new Error('not implemented'), unimplemented!(), todo!(), NotImplementedError, funções vazias, retorno-fantasma (return null como única statement), mocks fora de testes (jest.fn, vi.mock, sinon.stub, MagicMock), placeholders\n- Camada semântica (opt-in via `--from-agent <verdict.json>`): IDE agent valida critério-a-critério se implementação satisfaz spec\n- Skills `dare-review` (Claude Code), `review-task` (Cursor), `dare-review` (Antigravity) produzem o verdito semântico\n- Gate opt-in no Ralph Loop: `review.onComplete: true` no dare.config.json bloqueia `dare execute --complete` quando review falha\n\n`dare refine <task-id>`:\n- Heurística determinística de complexidade: # arquivos, # funções/endpoints, # testes, # deps, keywords pesadas (refactor/migrate/integrate)\n- Buckets LOW (0-5) / MED (6-12) / HIGH (13-20) / CRITICAL (21+); thresholds configuráveis em `refine.thresholds`\n- `--split` propõe quebra em sub-tasks agrupadas por diretório\n- Skills `dare-refine` (todas IDEs) produzem split semântico (por camada, por endpoint, por feature, refactor-then-feature, migration-then-code)\n\n## 3. Anti-Stub Contract nos prompts de geração\n\nBlueprint e Tasks agora forçam especificação executável: para cada endpoint, função pública, evento ou job — assinatura completa, request/response shape por status code, validações enumeradas, edge cases, side effects, exemplos concretos. TASK-SPEC-template ganha seção 'PADRÕES PROIBIDOS' explícita e Definition of Done anti-mock obrigatório.\n\n## 4. Mudanças de schema em `dare.config.json`\n\n- Campo `version` agora rastreia a release do DARE (antes era placeholder zombie `0.1.0`).\n- Novo objeto `review`: `{ onComplete: false, strict: false }` (opt-in pra projetos legados, on para novos).\n- Novo objeto `refine`: `{ thresholds: { low: 5, med: 12, high: 20 } }`.\n\nMigrações `unify-version-field` e `add-review-refine-defaults` cuidam de projetos pré-2.17 automaticamente.",
+      "changes": [
+        {
+          "type": "modified",
+          "path": "dare.config.json#version",
+          "description": "Campo `version` agora rastreia a release do DARE (antes era placeholder `0.1.0` zombie)",
+          "appliesTo": ["*"]
+        },
+        {
+          "type": "added",
+          "path": "dare.config.json#review",
+          "description": "Adiciona objeto `review` ({ onComplete, strict }) em dare.config.json — gate opt-in pré-DONE no Ralph Loop",
+          "appliesTo": ["*"]
+        },
+        {
+          "type": "added",
+          "path": "dare.config.json#refine",
+          "description": "Adiciona objeto `refine.thresholds` em dare.config.json para customizar buckets de complexidade",
+          "appliesTo": ["*"]
+        }
+      ],
+      "migrations": [
+        {
+          "id": "unify-version-field",
+          "description": "Migra `dareVersion` → `version` e substitui o placeholder legacy `0.1.0` por `2.16.0` quando necessário",
+          "optional": false
+        },
+        {
+          "id": "add-review-refine-defaults",
+          "description": "Adiciona `review: { onComplete: false, strict: false }` e `refine: { thresholds: ... }` em projetos pré-2.17 (opt-in — não ativa o gate automaticamente)",
+          "optional": false
+        }
+      ]
+    }
+  }
+}

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

@@ -122,34 +122,90 @@ Crie um documento `DARE/BLUEPRINT.md` com a seguinte estrutura:
 
 ## Estrutura de Diretórios
 
+> Mantenha esta seção **stack-agnóstica**. Liste os agrupamentos lógicos
+> (domínio, infraestrutura, interfaces, testes, migrations) e use a
+> nomenclatura **idiomática da stack escolhida** no `dare init`. Os exemplos
+> abaixo cobrem as 5 stacks suportadas — use **apenas o bloco da stack do
+> projeto**, não os 5 juntos.
+
+<details>
+<summary>Exemplo — Node.js / NestJS</summary>
+
+```
+projeto/
+├── src/
+│   ├── auth/
+│   │   ├── auth.controller.ts
+│   │   ├── auth.service.ts
+│   │   ├── auth.module.ts
+│   │   └── dto/{register,login}.dto.ts
+│   ├── users/{users.entity.ts,users.service.ts}
+│   └── main.ts
+├── migrations/{001_users.ts,002_refresh_tokens.ts}
+└── test/auth.e2e-spec.ts
+```
+</details>
+
+<details>
+<summary>Exemplo — Rust / Axum</summary>
+
+```
+projeto/
+├── src/
+│   ├── domain/{user.rs,refresh_token.rs}
+│   ├── handlers/{register.rs,login.rs,refresh.rs,logout.rs}
+│   ├── middleware/jwt.rs
+│   └── main.rs
+├── migrations/{001_users.sql,002_refresh_tokens.sql}
+└── tests/auth_integration.rs
+```
+</details>
+
+<details>
+<summary>Exemplo — Python / FastAPI</summary>
+
 ```
 projeto/
 ├── app/
-│   ├── Models/
-│   │   ├── User.php
-│   │   └── RefreshToken.php
-│   ├── Http/
-│   │   ├── Controllers/
-│   │   │   └── AuthController.php
-│   │   ├── Requests/
-│   │   │   ├── RegisterRequest.php
-│   │   │   └── LoginRequest.php
-│   │   └── Resources/
-│   │       └── UserResource.php
-│   ├── Services/
-│   │   └── AuthService.php
-│   └── Exceptions/
-│       └── AuthException.php
-├── database/
-│   └── migrations/
-│       ├── create_users_table.php
-│       └── create_refresh_tokens_table.php
-├── routes/
-│   └── api.php
-└── tests/
-    └── Feature/
-        └── AuthTest.php
+│   ├── routers/auth.py
+│   ├── models/{user.py,refresh_token.py}
+│   ├── schemas/{register.py,login.py}
+│   ├── services/auth.py
+│   └── main.py
+├── alembic/versions/{001_users.py,002_refresh_tokens.py}
+└── tests/test_auth.py
 ```
+</details>
+
+<details>
+<summary>Exemplo — PHP / Laravel</summary>
+
+```
+projeto/
+├── app/Http/Controllers/AuthController.php
+├── app/Http/Requests/{RegisterRequest,LoginRequest}.php
+├── app/Models/{User,RefreshToken}.php
+├── app/Services/AuthService.php
+├── database/migrations/{create_users,create_refresh_tokens}_table.php
+├── routes/api.php
+└── tests/Feature/AuthTest.php
+```
+</details>
+
+<details>
+<summary>Exemplo — Go / Gin</summary>
+
+```
+projeto/
+├── cmd/server/main.go
+├── internal/
+│   ├── handlers/{register,login,refresh,logout}.go
+│   ├── models/{user,refresh_token}.go
+│   └── middleware/jwt.go
+├── migrations/{001_users.sql,002_refresh_tokens.sql}
+└── handlers_test.go
+```
+</details>
 
 ## Plano de Execução
 
@@ -175,26 +231,71 @@ projeto/
 
 ## Comandos de Setup
 
+> Liste **somente os comandos da stack do projeto** (definida em
+> `dare init` / `dare.config.json#backend`). Não inclua todos os blocos
+> abaixo — use o que casa com a stack escolhida.
+
+<details>
+<summary>Node.js / NestJS</summary>
+
 ```bash
-# Instalar dependências
-composer install
+npm install
+cp .env.example .env
+npm run migration:run
+npm test
+npm run start:dev
+```
+</details>
+
+<details>
+<summary>Rust / Axum</summary>
 
-# Criar arquivo .env
+```bash
+cargo build
 cp .env.example .env
-php artisan key:generate
+sqlx migrate run
+cargo test
+cargo run
+```
+</details>
 
-# Rodar migrations
-php artisan migrate
+<details>
+<summary>Python / FastAPI</summary>
 
-# Gerar JWT secret
-php artisan jwt:secret
+```bash
+python -m venv .venv && source .venv/bin/activate
+pip install -r requirements.txt
+cp .env.example .env
+alembic upgrade head
+pytest
+uvicorn app.main:app --reload
+```
+</details>
 
-# Rodar testes
-php artisan test
+<details>
+<summary>PHP / Laravel</summary>
 
-# Iniciar servidor
+```bash
+composer install
+cp .env.example .env
+php artisan key:generate
+php artisan migrate
+php artisan test
 php artisan serve
 ```
+</details>
+
+<details>
+<summary>Go / Gin</summary>
+
+```bash
+go mod download
+cp .env.example .env
+migrate -path ./migrations -database "$DATABASE_URL" up
+go test ./...
+go run ./cmd/server
+```
+</details>
 
 ## Próximas Etapas
 1. Revisar e aprovar este Blueprint
@@ -202,7 +303,50 @@ php artisan serve
 3. Continuar com o Método DARE
 ```
 
-### Passo 5: Pedir Aprovação
+### Passo 5: Aplicar ANTI-STUB CONTRACT (regra inegociável)
+
+> **Por que existe esta regra:** a skill `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` (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**:
+
+**Endpoints HTTP/RPC:**
+- Assinatura completa (método, path, headers obrigatórios, content-type)
+- Request schema (todos os campos com tipo, restrições, opcionalidade)
+- Response schema **por status code** (2xx, 4xx, 5xx — não só "200 OK")
+- Validações server-side (lista exaustiva: `email único`, `senha ≥ 8 chars + maiúscula + dígito`)
+- Edge cases enumerados (input vazio, duplicado, expirado, sem permissão)
+- Side effects (tabelas/filas/caches/emails tocados, em ordem)
+- Exemplo concreto (payload real, response real — não placeholder)
+
+**Funções de domínio / services:**
+- Assinatura tipada (`fn name(args: Types) -> ReturnType`)
+- Pré-condições e pós-condições verificáveis
+- Estados de erro com tipo de exceção/Result esperado
+- Comportamento em concorrência (idempotência, locking, retry)
+
+**Jobs / event handlers / workers:**
+- Trigger (evento/cron/fila — nome canônico)
+- Payload schema tipado
+- Retry policy (backoff, max attempts, DLQ)
+- Idempotência (chave + estratégia)
+
+**Modelos de dados:**
+- Cada campo com tipo, nullable, default, constraints (unique, fk, check), índices
+- Triggers ou hooks (soft-delete, audit, encryption-at-rest)
+
+**Critério "Blueprint detalhado o suficiente"** (auto-validação antes de salvar):
+
+- [ ] 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 só "validar email")?
+- [ ] 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 vira stub. Especifique algoritmo, campos, regras.
+
+### Passo 6: Pedir Aprovação
 Após gerar o Blueprint, peça ao usuário:
 - Revisar a arquitetura
 - Aprovar endpoints e modelos

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

@@ -0,0 +1,114 @@
+---
+name: dare-refine
+description: Analisa complexidade de uma task DARE e, quando alta, quebra em sub-tasks menores. Use após gerar o DAG (para tasks HIGH/CRITICAL), quando o dev pedir refinamento manual, ou quando o escopo mudou e uma task ficou grande. Combina heurística determinística (CLI) com decisão semântica do agente.
+---
+
+# DARE Refine Skill
+
+Você é o refinador de tasks do método DARE. Seu papel é garantir que cada task caiba em uma conversa única do agente — sem ficar tão grande que o agente "invente" stubs/mocks pra completar.
+
+## Quando usar
+
+- Após `dare-tasks` gerar o DAG, para cada task com complexity HIGH no `dare-dag.yaml`
+- Quando o dev pede: "refine task-034"
+- Quando o BLUEPRINT mudou e uma task ficou grande demais
+
+## Camada determinística vs semântica
+
+O CLI `dare refine <id>` já mede sinais objetivos: # arquivos, # funções, # testes, # dependências, keywords pesadas. Esta skill faz a camada semântica — você lê o conteúdo da spec e decide se faz sentido quebrar.
+
+## Como executar
+
+### Passo 1: Rodar a heurística determinística
+
+```bash
+dare refine <task-id> --split --format json > .dare/refine-<task-id>.json
+```
+
+JSON traz:
+- `report.score`, `report.level`
+- `report.signals` — explica a pontuação
+- `report.recommendsSplit` — true se HIGH/CRITICAL
+- `proposal.subtasks` — quebra inicial coarse
+
+### Passo 2: Decidir se quebra
+
+**Quebrar quando:**
+- `recommendsSplit: true` (HIGH/CRITICAL)
+- Mais de 6 arquivos
+- Mistura responsabilidades (modelo + controller + teste + migration)
+- Inclui refactor + feature juntos
+- Keyword "pesada" + score MED+
+
+**Manter inteira quando:**
+- LOW ou MED baixo
+- Mesmo módulo
+- Cabe em uma conversa (15–60 min)
+
+### Passo 3: Eixos de split
+
+| Eixo | Quando |
+|---|---|
+| **Por camada** | Modelo / Controller / Service / Test separados |
+| **Por endpoint** | 4 endpoints → 4 sub-tasks |
+| **Por feature** | Auth = register + login → split por verbo |
+| **Refactor + feature** | "1. refactor" + "2. feature em cima" |
+| **Migration + código** | "1. migration" + "2. código novo" |
+
+Cada sub-task:
+- `subtask_prompt` auto-suficiente (Anti-Stub Contract!)
+- Spec própria em `DARE/EXECUTION/<sub-id>.md`
+- `depends_on` mínimo mas correto
+- Complexity honesta — se sub ainda for HIGH, quebrar de novo
+
+### Passo 4: Verdito
+
+`.dare/refine-verdict-<task-id>.json`:
+
+```json
+{
+  "manageable": false,
+  "reasons": ["Score 18 (HIGH) — 7 endpoints + migration", "Mistura refactor com features novas"],
+  "proposedSubtasks": [
+    {
+      "id": "task-034a",
+      "title": "Refactor UserService",
+      "files": ["src/services/UserService.ts", "tests/services/UserService.test.ts"],
+      "rationale": "Refactor isolado antes da feature",
+      "estimatedLevel": "MED"
+    }
+  ]
+}
+```
+
+Manuseável:
+
+```json
+{
+  "manageable": true,
+  "reasons": ["Score 7 (MED), 4 arquivos mesmo módulo"]
+}
+```
+
+### Passo 5: Aplicar o split
+
+1. Editar `DARE/dare-dag.yaml` substituindo a task pelas sub-tasks
+2. Criar specs em `DARE/EXECUTION/<sub-id>.md` (template + Anti-Stub Contract)
+3. Atualizar `DARE/TASKS.md` (visão humana)
+4. Regenerar Mermaid: `dare dag viz -o DARE/dag-graph.mmd`
+5. Marcar task original como SPLIT (preservar histórico)
+
+### Passo 6: Mensagem
+
+Manuseável:
+> ✅ Task bem-dimensionada (score X, level Y). Sem split.
+
+Quebrada:
+> 🪓 Task quebrada em N sub-tasks: [lista]. Revise com `dare validate` e `dare dag viz`.
+
+## Regras inegociáveis
+
+- Não quebrar tasks LOW
+- Não inventar dependências falsas
+- Cada sub-task testável independentemente
+- Anti-Stub Contract aplica em cada sub-task

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: