@dewtech/dare-cli 2.4.1 → 2.6.0

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

@@ -81,12 +81,20 @@ tasks:
 2. Para cada prompt:
      - leia spec_file se houver
      - implemente
-     - rode build/test/lint (Ralph Loop)
 3. dare execute --complete <id> --output "<resumo + arquivos tocados>"
-   (ou --fail <id> --reason "..." se falhou)
+     ↓ o CLI roda o RALPH LOOP automático (build → test → lint)
+     ↓ se passar: task vira DONE
+     ↓ se falhar: task vira FAILED com stderr capturado; corrija e retente
 4. Volte ao passo 1 até não haver mais tasks ready
 ```
 
+> **Ralph Loop é AUTOMÁTICO e OBRIGATÓRIO.** Você NÃO roda build/test/lint
+> manualmente — o `dare execute --complete` faz isso. Se algum gate falhar,
+> a task NÃO vai para DONE; vai para FAILED. Corrija e retente.
+>
+> **Não existe flag para pular o Ralph Loop.** Toda task passa pelos 3 gates
+> da stack do projeto.
+
 Comandos úteis:
 
 ```bash
@@ -164,6 +172,23 @@ O CLI reescreve a cada `--complete`/`--fail`:
 | Tudo em rank 0 | Adicione deps reais quando há contenção |
 | Cadeia linear | Reveja se as deps são necessárias |
 
+## Antipatterns que você NÃO deve criar
+
+- ❌ Task **"Ralph Loop final"** / **"Hardening"** / **"QA"** — gate é por task
+- ❌ Tests com `assertTrue(true)` — o gate `test` roda de verdade
+- ❌ "Setup project structure" antes de containerizar o app
+
+## Ordem recomendada das primeiras tasks
+
+1. **Containerize app** (Dockerfile + docker-compose + healthcheck)
+2. **Database schema** (migrations + factories)
+3. **Core endpoints / componentes**
+4. **Auth / autorização**
+5. **Test suite real** (assertions de verdade)
+
+A task de container/compose pode estar em outra ordem para projetos sem
+DB ou em monorepo já containerizado. Mas quase sempre é uma das primeiras.
+
 ## Checklist antes de aprovar
 
 - [ ] Pelo menos 2 tasks no rank 0
@@ -172,4 +197,7 @@ O CLI reescreve a cada `--complete`/`--fail`:
 - [ ] `complexity` reflete o esforço real
 - [ ] `id` em kebab-case e único
 - [ ] Sem ciclos
+- [ ] **Sem task de "Ralph Loop final"** — gate é por task
+- [ ] **Tests com assertions reais** — placeholder quebra o gate
+- [ ] Container/runtime resolvido cedo
 - [ ] Os 3 artefatos consistentes

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

@@ -71,6 +71,12 @@ tasks:
 - `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
 
 ### 4. Gerar `DARE/TASKS.md` (visão humana)
 

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

@@ -29,6 +29,19 @@ executável pelo CLI) e `EXECUTION/task-<id>.md` (specs detalhadas por task).
   ter tasks específicas ou estar explícitas nas tasks relevantes.
 - Atribua `complexity` a cada task: LOW / MED / HIGH.
 
+#### Regras inegociáveis de ordenação
+
+1. **A primeira task deve preparar o ambiente local** — Dockerfile +
+   `docker-compose.yml` + healthcheck. Sem isso o Ralph Loop não tem onde
+   rodar build/test/lint. Exceção: projeto que já vive em monorepo
+   containerizado.
+2. **Não crie task "Ralph Loop final" / "Hardening final"** — o Ralph Loop
+   roda automático em cada `dare execute --complete`. Não é uma task; é um
+   gate por task.
+3. **Tests devem ter assertions reais** desde a task que os escreve.
+   Placeholders (`assertTrue(true)` etc.) fazem o gate `test` falhar e a
+   task vai para FAILED.
+
 ### 3. Gerar `DARE/TASKS.md` (visão humana)
 
 Tabela com todas as tasks e dependências em formato legível:

package/templates/ide/cursor/.cursor/rules/skill-dag-runner.mdc

@@ -76,12 +76,22 @@ tasks:
 2. Para cada prompt:
      - leia spec_file se houver
      - implemente
-     - rode build/test/lint (Ralph Loop)
 3. dare execute --complete <id> --output "<resumo + arquivos tocados>"
-   (ou --fail <id> --reason "..." se falhou)
+     ↓ o CLI roda o RALPH LOOP automático (build → test → lint)
+     ↓ se passar: task vira DONE
+     ↓ se falhar: task vira FAILED com stderr capturado; corrija e retente
 4. Volte ao passo 1 até não haver mais tasks ready
 ```
 
+> **Ralph Loop é AUTOMÁTICO e OBRIGATÓRIO.** Você NÃO roda build/test/lint
+> manualmente — o `dare execute --complete` faz isso. Se algum gate falhar,
+> a task NÃO vai para DONE; vai para FAILED. Você corrige o código e tenta
+> de novo (`dare execute --complete <id>` outra vez, ou `--reset` antes se
+> precisar zerar histórico).
+>
+> **Não existe flag para pular o Ralph Loop.** Toda task passa pelos 3 gates
+> da stack do projeto.
+
 Comandos úteis:
 
 ```bash
@@ -175,6 +185,28 @@ nada; o CLI cuida do cascade.
 | Tudo em rank 0 | Conflito de escrita no mesmo arquivo | Adicione `depends_on` quando há contenção |
 | Cadeia linear longa | Sem ganho de paralelismo | Reveja se as deps são reais |
 
+## Antipatterns que você NÃO deve criar
+
+- ❌ Task chamada **"Ralph Loop final"**, **"Hardening final"**, **"QA final"**
+  — Ralph Loop roda automaticamente em cada `--complete`. Não é uma task.
+- ❌ Tests com `assertTrue(true)` ou equivalentes — o gate `test` vai rodar
+  de verdade. Placeholder não engana o CLI; só atrasa o ciclo.
+- ❌ "Setup project structure" como primeira task quando o ambiente ainda
+  não foi containerizado — sem container/runtime, o Ralph Loop não roda.
+
+## Ordem recomendada das primeiras tasks
+
+1. **Containerize app** (Dockerfile + docker-compose + healthcheck) — sem
+   isso o Ralph Loop não tem onde rodar
+2. **Database schema** (migrations + factories)
+3. **Core endpoints / componentes**
+4. **Auth / autorização**
+5. **Test suite real** (com assertions de verdade)
+
+A task de container/compose pode estar em **outra ordem** se o projeto já
+vive em um container do monorepo, ou se a stack não precisa de DB. Mas
+quase sempre é uma das primeiras — nunca a última.
+
 ## Checklist antes de aprovar um DAG
 
 - [ ] Pelo menos 2 tasks no rank 0
@@ -183,4 +215,7 @@ nada; o CLI cuida do cascade.
 - [ ] `complexity` reflete o esforço real (não tudo HIGH)
 - [ ] `id` em kebab-case e único
 - [ ] Sem ciclos
+- [ ] **Sem task de "Ralph Loop final"** — Ralph Loop é gate por task
+- [ ] **Tests com assertions reais** — placeholder quebra o gate `test`
+- [ ] Container/runtime resolvido cedo, não na última task
 - [ ] `TASKS.md` + `dare-dag.yaml` + `EXECUTION/task-*.md` consistentes