@dewtech/dare-cli 2.16.0 → 3.0.0

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-dag-build/SKILL.md

@@ -0,0 +1,154 @@
+---
+name: dare-dag-build
+description: Regenera APENAS o DARE/dare-dag.yaml a partir do DARE/BLUEPRINT.md existente, sem refazer o blueprint nem as specs. Use quando o BLUEPRINT mudou pouco mas o grafo precisa refletir o novo estado, ou quando você quer experimentar uma decomposição diferente.
+---
+
+# DARE DAG Build Skill
+
+Você é o construtor de grafos da fase EXECUTE do método DARE no Antigravity. Esta skill **regenera APENAS** o `DARE/dare-dag.yaml` — não refaz o BLUEPRINT, não refaz as specs, não roda nada. Apenas reconstrói o grafo de tasks a partir do estado atual do BLUEPRINT.
+
+> Se você precisa **executar** o grafo, use `dare-dag-run`.
+> Se você precisa **visualizar** o grafo, use `dare-dag-viz`.
+> Se você precisa **fazer tudo de uma vez** (build + run), use `dare-dag-runner`.
+
+## Quando usar esta skill
+
+- O BLUEPRINT foi ajustado e o grafo precisa refletir as mudanças
+- Você quer experimentar uma decomposição diferente sem refazer o blueprint
+- O `dare-dag.yaml` ficou inconsistente com `EXECUTION/task-*.md`
+- Precisa adicionar/remover/reordenar tasks no grafo
+- A complexidade ou as dependências de tasks mudaram
+
+## Pré-requisitos
+
+- `DARE/BLUEPRINT.md` existe e está aprovado
+- (Opcional) `DARE/EXECUTION/task-*.md` específicas — serão preservadas se não forem mencionadas
+
+## Como usar
+
+### Passo 1 — Ler `DARE/BLUEPRINT.md`
+
+Obrigatório. Se faltar, peça `dare-blueprint` antes.
+
+### Passo 2 — Ler `DARE/dare-dag.yaml` atual (se existir)
+
+Para preservar `id`s já em uso e não confundir o usuário com renomeações desnecessárias.
+
+### Passo 3 — Gerar o novo `dare-dag.yaml`
+
+Schema canônico:
+
+```yaml
+title: "<Nome do Projeto> - Development Tasks"
+version: "1.0.0"
+
+limits:
+  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 }
+  antigravity: { HIGH: gemini-2.5-pro,    MED: gemini-2.5-flash, LOW: gemini-2.5-flash }
+
+tasks:
+  - id: task-001
+    title: "..."
+    depends_on: []
+    complexity: LOW
+    spec_file: EXECUTION/task-001.md
+    subtask_prompt: |
+      <self-contained>
+```
+
+**Regras inegociáveis:**
+
+- `id` em kebab-case e único
+- `depends_on` mínimo — só quando filha *literalmente* precisa do output do pai
+- `subtask_prompt` self-contained (o subagente recebe apenas isso + 2000 chars dos pais)
+- Pelo menos **2 tasks no rank 0** (paralelismo desde o início)
+- Cadeia linear é antipattern — quebre dependências sempre que possível
+- `complexity` honesta — não inflar nem deflar
+
+### Passo 4 — 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. **O comando `dare-review` detecta isso e marca a task como FAILED.**
+
+Cada `subtask_prompt` e `EXECUTION/task-<id>.md` deve atender:
+
+**O `subtask_prompt` precisa ser auto-suficiente.** 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`) precisa 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/undefined/{} como única statement de função pública
+- [ ] Mocks SOMENTE em *.test.*, *.spec.*, __tests__/, tests/, spec/ — NUNCA em código de produção
+- [ ] Todos os endpoints retornam dados reais (não hardcoded)
+- [ ] Cada validação produz erro real com status code correto (testado)
+- [ ] Cada edge case tem teste demonstrando comportamento
+```
+
+**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"
+
+### Passo 5 — Validar consistência com `EXECUTION/task-*.md`
+
+Se uma spec já existe em `DARE/EXECUTION/task-<id>.md`:
+- Mantenha o mesmo `id` no YAML
+- Aponte `spec_file: EXECUTION/task-<id>.md`
+- Se a `complexity` ou `depends_on` mudou, atualize **também** a spec e o `TASKS.md`
+
+Se uma task nova entrou no YAML mas não tem spec:
+- Crie a spec correspondente em `EXECUTION/task-<id>.md`
+
+Se uma task saiu do YAML mas a spec ficou:
+- Pergunte ao usuário: arquivar (mover para `EXECUTION/_archived/`) ou apagar?
+
+### Passo 6 — Validar grafo
+
+- Sem ciclos (DAG = Directed Acyclic Graph)
+- Todos os `depends_on` apontam para `id`s existentes
+- `id`s únicos
+- Pelo menos 2 tasks no rank 0
+
+### Passo 7 — Atualizar `DARE/TASKS.md`
+
+Reflita o novo grafo na tabela master.
+
+### Passo 8 — Mensagem ao usuário
+
+> `dare-dag.yaml` regenerado:
+> - Total de tasks: N
+> - Ranks paralelos: N
+> - Adicionadas: [...]
+> - Removidas: [...]
+> - Modificadas: [...]
+>
+> Revise e aprove. Para executar: invoque a skill `dare-dag-run`.
+
+## Quando NÃO usar esta skill
+
+- Se você nunca rodou `dare-blueprint` antes — use `dare-blueprint` primeiro
+- Se o BLUEPRINT está desatualizado — atualize o BLUEPRINT primeiro
+- Se você só quer executar o grafo já aprovado — use `dare-dag-run`
+- Se você quer build + run num único passo — use `dare-dag-runner`
+
+## Licença
+
+Esta skill é parte do DARE Method e está sob licença MIT (D-001).

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

@@ -0,0 +1,130 @@
+---
+name: dare-dag-run
+description: Executa o grafo de tasks definido em DARE/dare-dag.yaml usando Antigravity como executor e o CLI dare como orquestrador. Sem API keys — usa o plano nativo da IDE. O canvas ao vivo fica em DARE/.canvas.md.
+---
+
+# DARE DAG Run Skill
+
+Você é o executor da fase EXECUTE do método DARE no Antigravity. Esta skill **executa APENAS** o grafo que já foi construído — não regenera o `dare-dag.yaml`, não modifica o BLUEPRINT, não cria specs novas. Apenas roda as tasks na ordem topológica correta.
+
+> Se você precisa **(re)construir** o grafo, use `dare-dag-build`.
+> Se você precisa **visualizar** o grafo, use `dare-dag-viz`.
+> Se você precisa **fazer tudo** (build + run num passo), use `dare-dag-runner`.
+
+> **Sem API keys.** Você (Antigravity) usa o plano nativo da IDE. O CLI `dare` apenas coordena estado, monta prompts e atualiza o canvas.
+
+## Quando usar esta skill
+
+- `DARE/dare-dag.yaml` está aprovado e pronto
+- As specs em `DARE/EXECUTION/task-<id>.md` estão geradas
+- É hora de implementar as tasks na ordem do grafo
+- O usuário aprovou os ANTI-STUB contracts
+
+## Pré-requisitos
+
+- `DARE/dare-dag.yaml` existe e foi aprovado pelo usuário
+- Specs em `DARE/EXECUTION/task-<id>.md` geradas (se não, use `dare-dag-build`)
+- `dare` disponível no PATH (`npm i -g @dewtech/dare-cli`)
+
+## Como usar
+
+```
+Invoque a skill com:
+- (sem args) — executa todas as ready do próximo rank
+- --task task-003 — executa só uma task específica
+```
+
+### Passo 1 — Validar pré-condições
+
+- Confirme que `DARE/dare-dag.yaml` existe. Se não, oriente o usuário a invocar `dare-blueprint` ou `dare-dag-build`
+- Leia o YAML e verifique: sem ciclos, ids únicos, ranks paralelizáveis
+- Liste rapidamente para o usuário: total de tasks, ranks, próximas ready
+
+### Passo 2 — Pegar próximas tasks
+
+```bash
+dare execute --next
+```
+
+O CLI imprime as tasks **ready** do rank atual com o prompt completo (snippets de até 2000 chars dos outputs dos pais já costurados). Use esses prompts diretamente — não reescreva.
+
+### Passo 3 — Sugerir abrir o canvas
+
+Antes de começar, peça ao usuário abrir `DARE/.canvas.md` em outra aba do Antigravity. Esse é o feedback visual ao vivo da execução.
+
+### Passo 4 — Executar cada task
+
+Para cada task ready:
+
+1. Leia `spec_file` se houver (`DARE/EXECUTION/task-<id>.md`)
+2. Implemente conforme o `subtask_prompt` — **não invente, não use mock fora de tests, sem TODOs**
+3. Rode o Ralph Loop completo: build → test → lint
+4. Registre o resultado no CLI:
+
+```bash
+# Sucesso
+dare execute --complete task-001 --output "Resumo curto + arquivos criados/modificados (paths)"
+
+# Falha
+dare execute --fail task-002 --reason "Mensagem clara da falha (compilação? teste? lint?)"
+```
+
+### Passo 5 — Avançar de rank
+
+```bash
+dare execute --next
+```
+
+- Se aparecer `✅ All tasks resolved`, todas terminaram. Reporte o resumo.
+- Caso contrário, continue executando o próximo rank.
+
+### Passo 6 — Pós-execução
+
+```bash
+dare execute --status
+```
+
+Mostra snapshot do canvas + sumário (X DONE, Y FAILED, Z SKIPPED).
+
+Para retentar tasks FAILED:
+
+```bash
+dare execute --reset task-002
+dare execute --next
+```
+
+## Comandos do orquestrador `dare`
+
+| Comando | Função |
+|---------|--------|
+| `dare execute --next` | Próximas tasks ready com prompts compostos |
+| `dare execute --complete <id> --output "..."` | Marca DONE |
+| `dare execute --fail <id> --reason "..."` | Marca FAILED + cascade-skip |
+| `dare execute --reset <id>` | Volta para PENDING |
+| `dare execute --status` | Snapshot do canvas + sumário |
+
+## Erros comuns
+
+| Sintoma | Causa | Correção |
+|---------|-------|----------|
+| `dare-dag.yaml not found` | Não foi gerado | Invoque `dare-blueprint` ou `dare-dag-build` |
+| Cascata de SKIPPED | Pai falhou | Corrija pai → `dare execute --reset` → `--next` |
+| Output truncado | Cap de 4000 chars | Escreva em arquivo, retorne resumo |
+| Spec inconsistente | TASKS.md ≠ dare-dag.yaml | Re-gere com `dare-dag-build` |
+
+## Referências
+
+- Schema: `DARE/dare-dag.yaml`
+- Canvas: `DARE/.canvas.md`
+- Specs: `DARE/EXECUTION/task-*.md`
+- Status: `DARE/TASKS.md`
+
+## Quando NÃO usar esta skill
+
+- Se `dare-dag.yaml` não existe — use `dare-blueprint` ou `dare-dag-build`
+- Se você quer só visualizar o grafo — use `dare-dag-viz`
+- Se você quer build + run num único passo — use `dare-dag-runner`
+
+## Licença
+
+Esta skill é parte do DARE Method e está sob licença MIT (D-001).