@dewtech/dare-cli 2.13.0 → 2.14.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -261,7 +261,7 @@ dare design "Build a REST API for user authentication with JWT"
261
261
 
262
262
  ### `dare blueprint`
263
263
 
264
- Generate `DARE/BLUEPRINT.md`, `dare-dag.yaml` and `TASKS.md` from `DESIGN.md`.
264
+ Generate `DARE/BLUEPRINT.md` from `DESIGN.md`. Stops here — requires human review and approval before tasks are created.
265
265
 
266
266
  ```bash
267
267
  dare blueprint
@@ -269,6 +269,16 @@ dare blueprint
269
269
 
270
270
  ---
271
271
 
272
+ ### `dare tasks`
273
+
274
+ Generate `DARE/TASKS.md`, `DARE/dare-dag.yaml` and all `DARE/EXECUTION/task-*.md` specs from an approved `BLUEPRINT.md`. Run this only after reviewing and approving the blueprint.
275
+
276
+ ```bash
277
+ dare tasks
278
+ ```
279
+
280
+ ---
281
+
272
282
  ### `dare execute`
273
283
 
274
284
  Orchestrate DAG execution. **The IDE is the executor** (Cursor / Antigravity
@@ -314,7 +324,7 @@ guide the IDE agent through this loop.
314
324
  #### Stack-specific skills
315
325
 
316
326
  `dare init` also ships skills focused on architectural decisions for
317
- specific stacks. As of v2.13.0:
327
+ specific stacks. As of v2.14.0:
318
328
 
319
329
  - **`skill-rust-workspace.mdc`** (Cursor) /
320
330
  **`dare-rust-workspace/SKILL.md`** (Antigravity) /
@@ -406,7 +416,7 @@ The Mermaid output groups tasks into rank subgraphs and colors nodes by
406
416
  status (`PENDING` / `RUNNING` / `DONE` / `FAILED` / `SKIPPED`), so you can
407
417
  **see the execution plan before running any task**.
408
418
 
409
- > `dare blueprint` writes `DARE/dag-graph.mmd` automatically — open it in
419
+ > `dare tasks` writes `DARE/dag-graph.mmd` automatically — open it in
410
420
  > your editor with a Mermaid preview to see the static graph immediately.
411
421
 
412
422
  ### `dare graph`
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@dewtech/dare-cli",
3
- "version": "2.13.0",
3
+ "version": "2.14.0",
4
4
  "description": "DARE Framework - CLI, GraphRAG engine, MCP server and shared types in a single package",
5
5
  "type": "module",
6
6
  "main": "./dist/index.js",
@@ -1,174 +1,78 @@
1
- # /dare-blueprint
2
-
3
- Gera os 5 artefatos a partir do `DARE/DESIGN.md`:
4
-
5
- 1. `DARE/BLUEPRINT.md` arquitetura técnica detalhada
6
- 2. `DARE/TASKS.md` — visão humana das tasks
7
- 3. `DARE/dare-dag.yaml` — grafo executável pelo CLI
8
- 4. `DARE/EXECUTION/task-<id>.md` — spec detalhada por task
9
- 5. `DARE/dag-graph.mmd` — visualização Mermaid do DAG
10
-
11
- ## Como usar
12
-
13
- ```
14
- /dare-blueprint
15
- /dare-blueprint --stack node-nestjs+react
16
- ```
17
-
18
- ## O que fazer
19
-
20
- ### 1. Ler `DARE/DESIGN.md`
21
-
22
- Obrigatório. Se não existir, peça para rodar `/dare-design` primeiro.
23
-
24
- Extraia e memorize para uso neste comando:
25
- - Stack técnica (linguagem, framework, versões)
26
- - Requisitos funcionais priorizados (RF-*)
27
- - Requisitos de segurança (RS-*)
28
- - Integrações externas confirmadas
29
- - Restrições e escopo
30
-
31
- ### 2. Gerar `DARE/BLUEPRINT.md`
32
-
33
- Siga o template `templates/BLUEPRINT-template.md`. Seções obrigatórias:
34
-
35
- **2.1 Visão Geral da Arquitetura**
36
- - Diagrama Mermaid da arquitetura
37
- - Tabela de decisões arquiteturais com justificativa (não apenas "escolha X")
38
-
39
- **2.2 Stack Técnica Definida** — versões fixas, não ranges
40
-
41
- **2.3 Estrutura de Pastas** — árvore completa dos arquivos que serão criados
42
-
43
- **2.4 Modelo de Dados** — entidades, campos tipados, relacionamentos, índices necessários
44
-
45
- **2.5 Contratos de API** — tabela completa: método, rota, auth, request body, response, status codes
46
-
47
- **2.6 Plano de Execução (Fases)** — cada fase com:
48
- - Nome e objetivo
49
- - **Critério de DONE** comportamento verificável e testável (não "código feito")
50
- - Lista de entregáveis concretos
51
-
52
- > **Fase 1 é sempre containerização** (Dockerfile + docker-compose + healthcheck)
53
- > **Fase N-1 é sempre auditoria de segurança e dependências**
54
-
55
- **2.7 Validation Gates por Stack**
56
-
57
- | Stack | Build | Test | Lint/Audit |
58
- |-------|-------|------|------------|
59
- | Rust/Axum | `cargo build` | `cargo test --workspace` | `cargo clippy && cargo audit` |
60
- | Node/NestJS | `npm run build` | `npm test` | `npx eslint src && npm audit --audit-level=high` |
61
- | Python/FastAPI | verificar imports | `pytest` | `ruff check . && pip-audit` |
62
- | PHP/Laravel | `php artisan config:cache` | `php artisan test` | `./vendor/bin/phpstan && composer audit` |
63
- | Go | `go build ./...` | `go test ./...` | `golangci-lint run` |
64
-
65
- **2.8 Controles de Segurança** — checklist com todos os RS-* do DESIGN mapeados para tasks específicas
66
-
67
- **2.9 Estratégia de Testes** — unitários + integração + segurança (auditoria de deps) + E2E se frontend
68
-
69
- **2.10 Estratégia de Deploy** por ambiente com branch, trigger e infra
70
-
71
- ### 3. Gerar `DARE/dare-dag.yaml` (grafo executável)
72
-
73
- Schema canônico:
74
-
75
- ```yaml
76
- title: "<Nome do Projeto> - Development Tasks"
77
- version: "1.0.0"
78
-
79
- limits:
80
- parent_context_chars: 2000
81
- task_output_chars: 4000
82
- timeout_seconds: 600
83
-
84
- models:
85
- cursor: { HIGH: gpt-5.3-codex, MED: composer-2, LOW: auto-low }
86
- claude: { HIGH: claude-sonnet-4-6, MED: claude-haiku-4-5, LOW: claude-haiku-4-5 }
87
- antigravity: { HIGH: gemini-2.5-pro, MED: gemini-2.5-flash, LOW: gemini-2.5-flash }
88
-
89
- tasks:
90
- - id: task-001
91
- title: "Containerização — Dockerfile + docker-compose"
92
- depends_on: []
93
- complexity: LOW
94
- spec_file: EXECUTION/task-001.md
95
- subtask_prompt: |
96
- <prompt completamente self-contained>
97
- ```
98
-
99
- **Regras inegociáveis:**
100
-
101
- - `id` em kebab-case e único
102
- - `depends_on` **mínimo** — só quando a task filha literalmente não pode começar sem o output da pai
103
- - `subtask_prompt` totalmente self-contained — não use "siga o padrão da task-001"
104
- - Pelo menos 2 tasks no rank 0 (`depends_on: []`) para haver paralelismo real
105
- - Cadeia linear (`001→002→003→...`) é antipattern — reanalise o grafo
106
- - `complexity: HIGH` apenas para lógica de segurança crítica, algoritmos complexos ou integrações externas arriscadas
107
- - **task-001 = containerização** sempre
108
- - **task-N-1 ou task-N = auditoria de segurança + dependências** (sem CVE HIGH/CRITICAL)
109
- - **NÃO crie task "Ralph Loop final" / "QA final"** — o Ralph Loop roda em CADA `--complete`
110
- - **NÃO crie task "Refactoring geral"** — refactoring faz parte de cada task
111
- - Testes com assertions reais — `assertTrue(true)` quebra o gate e a task vai para FAILED
112
-
113
- ### 4. Gerar `DARE/TASKS.md` (visão humana)
114
-
115
- ```markdown
116
- # Tasks: <Nome do Projeto>
117
-
118
- ## Visão Geral
119
- - Total de Tasks: N
120
- - Ranks paralelos: N
121
-
122
- ## Tabela de Status
123
-
124
- | ID | Título | Status | Depends On | Complexity |
125
- |----------|---------------------------|-------------|------------------|------------|
126
- | task-001 | Containerização | ⏳ PENDING | — | LOW |
127
- | task-002 | DB migrations | ⏳ PENDING | — | MED |
128
- | task-003 | Auth endpoints | ⏳ PENDING | task-001, 002 | HIGH |
129
- ```
130
-
131
- ### 5. Gerar `DARE/EXECUTION/task-<id>.md` (uma por task)
132
-
133
- Para CADA task, use o template `templates/TASK-SPEC-template.md`:
134
- - Objetivo verificável (não uma ação, mas um estado observável)
135
- - Arquivos a criar/modificar (tabela)
136
- - Implementação passo a passo
137
- - **Considerações de segurança** (seção obrigatória mesmo para tasks de infra)
138
- - **Validation Gates** específicos da stack (build + test + lint + audit se nova dep)
139
- - Critérios de DONE explícitos
140
-
141
- ### 6. Validar consistência dos 5 artefatos
142
-
143
- - [ ] Mesmos `id`s em `TASKS.md`, `dare-dag.yaml` e `EXECUTION/task-*.md`
144
- - [ ] Mesmas `depends_on` nos três artefatos
145
- - [ ] Mesma `complexity` nos três artefatos
146
- - [ ] Sem ciclos no DAG
147
- - [ ] Pelo menos 2 tasks no rank 0
148
- - [ ] task-001 é containerização
149
- - [ ] Existe task de auditoria de segurança/dependências
150
- - [ ] Cada `subtask_prompt` é executável sem contexto adicional
151
-
152
- ### 7. Regenerar visualização do DAG
153
-
154
- ```bash
155
- dare dag viz -o DARE/dag-graph.mmd
156
- ```
157
-
158
- ### 8. Aguardar aprovação humana
159
-
160
- **Não execute nenhuma task** até o usuário revisar e aprovar os 5 artefatos.
161
-
162
- ## Próximos passos
163
-
164
- Após aprovação:
165
-
166
- ```bash
167
- dare execute --parallel --runner claude
168
- dare execute --runner claude # sequencial (debug)
169
- dare execute --task task-003 --runner claude # task única
170
- ```
171
-
172
- Ou slash commands: `/dare-dag-run` · `/dare-execute task-001` · `/dare-tasks`
173
-
174
- $ARGUMENTS
1
+ # /dare-blueprint
2
+
3
+ Gera **somente** `DARE/BLUEPRINT.md` a partir do `DARE/DESIGN.md`.
4
+
5
+ > Tasks, DAG e specs de execução são geradas depois com `/dare-tasks`, após aprovação humana do Blueprint.
6
+
7
+ ## Como usar
8
+
9
+ ```
10
+ /dare-blueprint
11
+ /dare-blueprint --stack node-nestjs+react
12
+ ```
13
+
14
+ ## O que fazer
15
+
16
+ ### 1. Ler `DARE/DESIGN.md`
17
+
18
+ Obrigatório. Se não existir, peça para rodar `/dare-design` primeiro.
19
+
20
+ Extraia e use durante todo o comando:
21
+ - Stack técnica (linguagem, framework, versões)
22
+ - Requisitos funcionais priorizados (RF-*)
23
+ - Requisitos de segurança (RS-*)
24
+ - Integrações externas confirmadas
25
+ - Restrições e escopo
26
+
27
+ ### 2. Gerar `DARE/BLUEPRINT.md`
28
+
29
+ Siga o template `templates/BLUEPRINT-template.md`. Seções obrigatórias:
30
+
31
+ **2.1 Visão Geral da Arquitetura**
32
+ - Diagrama Mermaid da arquitetura
33
+ - Tabela de decisões arquiteturais com justificativa (não apenas "escolha X")
34
+
35
+ **2.2 Stack Técnica Definida** — versões fixas, não ranges
36
+
37
+ **2.3 Estrutura de Pastas** árvore completa dos arquivos que serão criados
38
+
39
+ **2.4 Modelo de Dados** — entidades, campos tipados, relacionamentos, índices necessários
40
+
41
+ **2.5 Contratos de API** — tabela completa: método, rota, auth, request body, response, status codes
42
+
43
+ **2.6 Plano de Execução (Fases)** — cada fase com:
44
+ - Nome e objetivo
45
+ - **Critério de DONE** — comportamento verificável e testável (não "código feito")
46
+ - Lista de entregáveis concretos
47
+
48
+ > **Fase 1 é sempre containerização** (Dockerfile + docker-compose + healthcheck)
49
+ > **Fase N-1 é sempre auditoria de segurança e dependências**
50
+
51
+ **2.7 Validation Gates por Stack**
52
+
53
+ | Stack | Build | Test | Lint/Audit |
54
+ |-------|-------|------|------------|
55
+ | Rust/Axum | `cargo build` | `cargo test --workspace` | `cargo clippy && cargo audit` |
56
+ | Node/NestJS | `npm run build` | `npm test` | `npx eslint src && npm audit --audit-level=high` |
57
+ | Python/FastAPI | verificar imports | `pytest` | `ruff check . && pip-audit` |
58
+ | PHP/Laravel | `php artisan config:cache` | `php artisan test` | `./vendor/bin/phpstan && composer audit` |
59
+ | Go | `go build ./...` | `go test ./...` | `golangci-lint run` |
60
+
61
+ **2.8 Controles de Segurança** checklist com todos os RS-* do DESIGN mapeados para fases específicas
62
+
63
+ **2.9 Estratégia de Testes** unitários + integração + segurança (auditoria de deps) + E2E se frontend
64
+
65
+ **2.10 Estratégia de Deploy** — por ambiente com branch, trigger e infra
66
+
67
+ **2.11 Checklist de Aprovação** — checkboxes para o usuário revisar antes de prosseguir
68
+
69
+ ### 3. Salvar e aguardar aprovação humana
70
+
71
+ Salve `DARE/BLUEPRINT.md` e informe:
72
+
73
+ _"Blueprint gerado. Revise a arquitetura, os contratos de API e os critérios de DONE de cada fase — especialmente as tasks de complexidade HIGH. Quando aprovado, rode `/dare-tasks` para gerar o DAG e as specs de execução."_
74
+
75
+ **Não gere** `DARE/TASKS.md`, `DARE/dare-dag.yaml` nem arquivos em `DARE/EXECUTION/`.
76
+ Esses artefatos são responsabilidade exclusiva do `/dare-tasks`.
77
+
78
+ $ARGUMENTS
@@ -1,51 +1,41 @@
1
- # Comando: /generate-blueprint
2
-
3
- ## Descrição
4
- Avança o DARE para a fase Architect: lê `DARE/DESIGN.md` aprovado e gera os 5 artefatos de arquitetura.
5
-
6
- ## Instruções para o Cursor Composer
7
-
8
- 1. **Leia `DARE/DESIGN.md`** obrigatório. Se não existir, peça `/generate-design` primeiro. Extraia: stack, RF-*, RNF-*, RS-*, integrações, restrições.
9
-
10
- 2. **Leia o template:** `templates/BLUEPRINT-template.md`siga a estrutura fielmente.
11
-
12
- 3. **Gere `DARE/BLUEPRINT.md`** com seções obrigatórias:
13
-
14
- - **Visão Geral da Arquitetura** — diagrama Mermaid + tabela de decisões com justificativa
15
- - **Stack Técnica Definida** — versões fixas (não ranges)
16
- - **Estrutura de Pastas** — árvore completa dos arquivos a criar
17
- - **Modelo de Dados** — entidades, campos tipados, relacionamentos, índices
18
- - **Contratos de API** — método, rota, auth, request/response, status codes
19
- - **Plano de Execução (Fases)** — cada fase com critério de DONE verificável:
20
- - **Fase 1 = containerização** (Dockerfile + docker-compose + healthcheck) sempre
21
- - **Fase N-1 = auditoria de segurança + dependências** sempre
22
- - **Validation Gates por stack:**
23
- | Stack | Build | Test | Lint/Audit |
24
- |-------|-------|------|------------|
25
- | Rust | `cargo build` | `cargo test --workspace` | `cargo clippy && cargo audit` |
26
- | Node | `npm run build` | `npm test` | `npx eslint src && npm audit --audit-level=high` |
27
- | Python | verificar imports | `pytest` | `ruff check . && pip-audit` |
28
- | PHP | `php artisan config:cache` | `php artisan test` | `./vendor/bin/phpstan && composer audit` |
29
- | Go | `go build ./...` | `go test ./...` | `golangci-lint run` |
30
- - **Controles de Segurança** checklist mapeando cada RS-* do DESIGN para tasks específicas
31
- - **Estratégia de Testes** unitários + integração + auditoria de deps + E2E
32
- - **Estratégia de Deploy** — por ambiente
33
-
34
- 4. **Gere `DARE/dare-dag.yaml`** com regras:
35
- - `id` kebab-case único; `depends_on` mínimo necessário
36
- - Pelo menos 2 tasks no rank 0 (paralelismo real)
37
- - task-001 = containerização; task final = auditoria de segurança
38
- - Sem task "Ralph Loop final" ou "QA geral" — corre em cada `--complete`
39
- - `subtask_prompt` totalmente self-contained
40
-
41
- 5. **Gere `DARE/TASKS.md`** (tabela de status visual)
42
-
43
- 6. **Gere `DARE/EXECUTION/task-<id>.md`** para cada task usando `templates/TASK-SPEC-template.md`:
44
- - Objetivo verificável (estado, não ação)
45
- - Arquivos a criar/modificar (tabela)
46
- - Seção "Considerações de Segurança" obrigatória
47
- - Validation gates específicos da stack (build + test + lint + audit se nova dep)
48
-
49
- 7. **Valide consistência** dos 5 artefatos (IDs, depends_on, complexity iguais nos 3)
50
-
51
- 8. **Salve e informe:** _"Blueprint gerado com [N] tasks em [K] ranks paralelos. Revise especialmente: [lista de tasks HIGH complexity]. Quando aprovado, execute `dare execute --parallel`."_
1
+ # Comando: /generate-blueprint
2
+
3
+ ## Descrição
4
+ Avança o DARE para a fase Architect: lê `DARE/DESIGN.md` aprovado e gera **somente** `DARE/BLUEPRINT.md`.
5
+
6
+ > As tasks, DAG e specs de execução são geradas depois com `/generate-tasks`, após você revisar e aprovar o Blueprint.
7
+
8
+ ## Instruções para o Cursor Composer
9
+
10
+ 1. **Leia `DARE/DESIGN.md`**obrigatório. Se não existir, peça `/generate-design` primeiro. Extraia: stack, RF-*, RNF-*, RS-*, integrações, restrições, escopo.
11
+
12
+ 2. **Leia o template:** `templates/BLUEPRINT-template.md` siga a estrutura fielmente.
13
+
14
+ 3. **Gere `DARE/BLUEPRINT.md`** com seções obrigatórias:
15
+
16
+ - **Visão Geral da Arquitetura** — diagrama Mermaid + tabela de decisões com justificativa
17
+ - **Stack Técnica Definida** — versões fixas (não ranges)
18
+ - **Estrutura de Pastas** — árvore completa dos arquivos a criar
19
+ - **Modelo de Dados** — entidades, campos tipados, relacionamentos, índices
20
+ - **Contratos de API** método, rota, auth, request/response, status codes
21
+ - **Plano de Execução (Fases)** cada fase com critério de DONE verificável:
22
+ - Fase 1 = containerização (Dockerfile + docker-compose + healthcheck) — sempre
23
+ - Fase N-1 = auditoria de segurança + dependências — sempre
24
+ - **Validation Gates por stack:**
25
+ | Stack | Build | Test | Lint/Audit |
26
+ |-------|-------|------|------------|
27
+ | Rust | `cargo build` | `cargo test --workspace` | `cargo clippy && cargo audit` |
28
+ | Node | `npm run build` | `npm test` | `npx eslint src && npm audit --audit-level=high` |
29
+ | Python | verificar imports | `pytest` | `ruff check . && pip-audit` |
30
+ | PHP | `php artisan config:cache` | `php artisan test` | `./vendor/bin/phpstan && composer audit` |
31
+ | Go | `go build ./...` | `go test ./...` | `golangci-lint run` |
32
+ - **Controles de Segurança** — checklist mapeando cada RS-* do DESIGN para fases específicas
33
+ - **Estratégia de Testes** — unitários + integração + auditoria de deps + E2E
34
+ - **Estratégia de Deploy** — por ambiente
35
+ - **Checklist de Aprovação** checkboxes para revisão humana
36
+
37
+ 4. **Salve `DARE/BLUEPRINT.md`** e informe:
38
+
39
+ _"Blueprint gerado. Revise a arquitetura, os contratos de API e os critérios de DONE de cada fase. Quando aprovado, execute `/generate-tasks` para gerar o DAG e as specs de execução."_
40
+
41
+ **Não gere** `TASKS.md`, `dare-dag.yaml` nem arquivos em `EXECUTION/` — isso é responsabilidade do `/generate-tasks`.