@dewtech/dare-cli 3.3.0 → 3.4.0

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

@@ -1,131 +1,131 @@
-# /dare-ax
-
-Audita ou bootstrapa um projeto DARE com foco em **Agent Experience (AX)** — os sinais estruturados que agentes de código (Claude Code, Cursor, Antigravity) precisam para trabalhar sem refactor desnecessário.
-
-## Como usar
-
-```
-/dare-ax                          # audita projeto atual
-/dare-ax init                     # cria llms.txt + .env.example + ajustes mínimos
-/dare-ax openapi                  # valida ou gera openapi.json
-/dare-ax cli                      # adiciona --json em comandos CLI faltantes
-```
-
-## Os três planos AX
-
-### 1. Discovery — agente acha o que precisa
-
-- `llms.txt` na raiz com descrição, comandos, endpoints
-- `README.md` com bootstrap em 5 minutos
-- Estrutura de pastas previsível (`src/`, `tests/`, `docs/`, `DARE/`)
-
-### 2. Usage — agente consegue operar
-
-- `openapi.json` em `/openapi.json` (HTTP)
-- Flag `--json` em todos os CLIs
-- `Dockerfile` + `docker-compose.yml` validados
-- `.env.example` versionado
-
-### 3. Defense — agente não quebra produção
-
-- Rate limit (rack-attack, express-rate-limit, tower-governor, slowapi)
-- Validação de input (FormRequests, Pydantic, Zod, serde+validator)
-- Secrets só via env
-- `llms.txt` sem credenciais (scan no CI)
-
-## Métricas obrigatórias
-
-| ID | Métrica | Como verificar |
-|---|---|---|
-| M-01 | `llms.txt` existe e é válido (sem secrets, seções obrigatórias) | grep + parse |
-| M-02 | `openapi.json` ou `public/openapi.json` existe | `test -f` |
-| M-03 | CLI suporta `--json` | `cli --help \| grep '\-\-json'` |
-| M-04 | Rate limit configurado | grep pelo middleware da stack |
-
-Falha em CI se M-01 ou M-04 falharem em produção.
-
-## O que fazer
-
-### Passo 1: Auditar o projeto
-
-Confira na ordem:
-1. Existe `llms.txt`? Está atualizado?
-2. Existe `openapi.json` se o projeto expõe HTTP?
-3. Todos os CLIs aceitam `--json`?
-4. Existe rate limit em endpoints autenticados públicos?
-5. `.env.example` está versionado sem valores reais?
-
-### Passo 2: Gerar `llms.txt` se faltar
-
-Use este template — preencha apenas com comandos e endpoints que **existem de verdade**:
-
-```
-# <nome-do-projeto>
-
-> <descrição em 1-2 frases>
-
-## Stack
-- <linguagem + framework>
-- <banco>
-- <cache/fila>
-
-## Bootstrap
-- `make setup`
-- `make dev`
-- `make test`
-
-## Endpoints
-- `GET /healthz`
-- `GET /openapi.json`
-- `POST /api/login`
-
-## Docs
-- DARE/DESIGN.md
-- DARE/BLUEPRINT.md
-- docs/RUNBOOK.md
-```
-
-### Passo 3: Validar / gerar OpenAPI
-
-- **Node/NestJS** — `@nestjs/swagger`
-- **FastAPI** — automático em `/openapi.json`
-- **Rails** — `grape-swagger` ou `rswag`
-- **Rust/Axum** — `utoipa` + `utoipa-swagger-ui`
-- **Laravel** — `darkaonline/l5-swagger`
-
-### Passo 4: Adicionar `--json` no CLI
-
-Para cada comando:
-- Imprime JSON puro em stdout (sem cores ANSI, sem prompt)
-- Exit code 0 em sucesso, ≠ 0 em erro
-- Schema documentado no `llms.txt`
-
-### Passo 5: Configurar rate limit
-
-Adicione middleware específico da stack para todos os endpoints públicos. Padrão recomendado:
-- Login: 5 req / 15 min por IP + por usuário
-- API geral: 100 req / min por usuário autenticado
-
-## Antipatterns a evitar
-
-| AP | Por que evitar |
-|---|---|
-| Docs fora do código | Divergem |
-| OpenAPI à mão | Desatualiza |
-| CLI sem `--json` | Parsing regex frágil |
-| Rate limit só em dev | Produção vira target |
-| `llms.txt` com secrets | Credencial exposta |
-| CORS `*` em prod | Origem qualquer |
-
-## Saída esperada
-
-Reporte numerado dos 4 checks (M-01 a M-04). Para cada falha, mostre:
-- O que falta
-- Como corrigir (com comando concreto da stack)
-- Quem deve aprovar antes do CI travar release
-
-$ARGUMENTS
-
----
-
-Skill MIT — parte do DARE Method.
+# /dare-ax
+
+Audita ou bootstrapa um projeto DARE com foco em **Agent Experience (AX)** — os sinais estruturados que agentes de código (Claude Code, Cursor, Antigravity) precisam para trabalhar sem refactor desnecessário.
+
+## Como usar
+
+```
+/dare-ax                          # audita projeto atual
+/dare-ax init                     # cria llms.txt + .env.example + ajustes mínimos
+/dare-ax openapi                  # valida ou gera openapi.json
+/dare-ax cli                      # adiciona --json em comandos CLI faltantes
+```
+
+## Os três planos AX
+
+### 1. Discovery — agente acha o que precisa
+
+- `llms.txt` na raiz com descrição, comandos, endpoints
+- `README.md` com bootstrap em 5 minutos
+- Estrutura de pastas previsível (`src/`, `tests/`, `docs/`, `DARE/`)
+
+### 2. Usage — agente consegue operar
+
+- `openapi.json` em `/openapi.json` (HTTP)
+- Flag `--json` em todos os CLIs
+- `Dockerfile` + `docker-compose.yml` validados
+- `.env.example` versionado
+
+### 3. Defense — agente não quebra produção
+
+- Rate limit (rack-attack, express-rate-limit, tower-governor, slowapi)
+- Validação de input (FormRequests, Pydantic, Zod, serde+validator)
+- Secrets só via env
+- `llms.txt` sem credenciais (scan no CI)
+
+## Métricas obrigatórias
+
+| ID | Métrica | Como verificar |
+|---|---|---|
+| M-01 | `llms.txt` existe e é válido (sem secrets, seções obrigatórias) | grep + parse |
+| M-02 | `openapi.json` ou `public/openapi.json` existe | `test -f` |
+| M-03 | CLI suporta `--json` | `cli --help \| grep '\-\-json'` |
+| M-04 | Rate limit configurado | grep pelo middleware da stack |
+
+Falha em CI se M-01 ou M-04 falharem em produção.
+
+## O que fazer
+
+### Passo 1: Auditar o projeto
+
+Confira na ordem:
+1. Existe `llms.txt`? Está atualizado?
+2. Existe `openapi.json` se o projeto expõe HTTP?
+3. Todos os CLIs aceitam `--json`?
+4. Existe rate limit em endpoints autenticados públicos?
+5. `.env.example` está versionado sem valores reais?
+
+### Passo 2: Gerar `llms.txt` se faltar
+
+Use este template — preencha apenas com comandos e endpoints que **existem de verdade**:
+
+```
+# <nome-do-projeto>
+
+> <descrição em 1-2 frases>
+
+## Stack
+- <linguagem + framework>
+- <banco>
+- <cache/fila>
+
+## Bootstrap
+- `make setup`
+- `make dev`
+- `make test`
+
+## Endpoints
+- `GET /healthz`
+- `GET /openapi.json`
+- `POST /api/login`
+
+## Docs
+- DARE/DESIGN.md
+- DARE/BLUEPRINT.md
+- docs/RUNBOOK.md
+```
+
+### Passo 3: Validar / gerar OpenAPI
+
+- **Node/NestJS** — `@nestjs/swagger`
+- **FastAPI** — automático em `/openapi.json`
+- **Rails** — `grape-swagger` ou `rswag`
+- **Rust/Axum** — `utoipa` + `utoipa-swagger-ui`
+- **Laravel** — `darkaonline/l5-swagger`
+
+### Passo 4: Adicionar `--json` no CLI
+
+Para cada comando:
+- Imprime JSON puro em stdout (sem cores ANSI, sem prompt)
+- Exit code 0 em sucesso, ≠ 0 em erro
+- Schema documentado no `llms.txt`
+
+### Passo 5: Configurar rate limit
+
+Adicione middleware específico da stack para todos os endpoints públicos. Padrão recomendado:
+- Login: 5 req / 15 min por IP + por usuário
+- API geral: 100 req / min por usuário autenticado
+
+## Antipatterns a evitar
+
+| AP | Por que evitar |
+|---|---|
+| Docs fora do código | Divergem |
+| OpenAPI à mão | Desatualiza |
+| CLI sem `--json` | Parsing regex frágil |
+| Rate limit só em dev | Produção vira target |
+| `llms.txt` com secrets | Credencial exposta |
+| CORS `*` em prod | Origem qualquer |
+
+## Saída esperada
+
+Reporte numerado dos 4 checks (M-01 a M-04). Para cada falha, mostre:
+- O que falta
+- Como corrigir (com comando concreto da stack)
+- Quem deve aprovar antes do CI travar release
+
+$ARGUMENTS
+
+---
+
+Skill MIT — parte do DARE Method.

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

@@ -1,18 +1,18 @@
-# /dare-bench
-
-Roda o harness determinístico de fixtures de verificação (`dare bench`) — mede Fix·Rate e solve-rate contra patches versionados.
-
-> Este comando expõe o CLI `dare bench` na IDE.
-
-## Como rodar
-
-```bash
-dare bench --suite fixtures/bench --json
-dare bench --suite fixtures/bench --baseline bench-baseline.json --fail-on-regression 3
-```
-
-## O que fazer
-
-1. Rode `dare bench` com `--json` para relatório estruturado.
-2. Compare com `--baseline` em CI; exit 1 = regressão > limiar pp.
-3. Exit 2 = suite inválida/ausente.
+# /dare-bench
+
+Roda o harness determinístico de fixtures de verificação (`dare bench`) — mede Fix·Rate e solve-rate contra patches versionados.
+
+> Este comando expõe o CLI `dare bench` na IDE.
+
+## Como rodar
+
+```bash
+dare bench --suite fixtures/bench --json
+dare bench --suite fixtures/bench --baseline bench-baseline.json --fail-on-regression 3
+```
+
+## O que fazer
+
+1. Rode `dare bench` com `--json` para relatório estruturado.
+2. Compare com `--baseline` em CI; exit 1 = regressão > limiar pp.
+3. Exit 2 = suite inválida/ausente.

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

@@ -1,134 +1,134 @@
-# /dare-blueprint
-
-Gera **somente** `DARE/BLUEPRINT.md` a partir do `DARE/DESIGN.md`.
-
-> Tasks, DAG e specs de execução são geradas depois com `/dare-tasks`, após aprovação humana do Blueprint.
-
-## Como usar
-
-```
-/dare-blueprint
-/dare-blueprint --stack node-nestjs+react
-```
-
-## O que fazer
-
-### 1. Ler `DARE/DESIGN.md`
-
-Obrigatório. Se não existir, peça para rodar `/dare-design` primeiro.
-
-Extraia e use durante todo o comando:
-- Stack técnica (linguagem, framework, versões)
-- Requisitos funcionais priorizados (RF-*)
-- Requisitos de segurança (RS-*)
-- Integrações externas confirmadas
-- Restrições e escopo
-
-### 2. Gerar `DARE/BLUEPRINT.md`
-
-Siga o template `templates/BLUEPRINT-template.md`. Seções obrigatórias:
-
-**2.1 Visão Geral da Arquitetura**
-- Diagrama Mermaid da arquitetura
-- Tabela de decisões arquiteturais com justificativa (não apenas "escolha X")
-
-**2.2 Stack Técnica Definida** — versões fixas, não ranges
-
-**2.3 Estrutura de Pastas** — árvore completa dos arquivos que serão criados
-
-**2.4 Modelo de Dados** — entidades, campos tipados, relacionamentos, índices necessários
-
-**2.5 Contratos de API** — tabela completa: método, rota, auth, request body, response, status codes
-
-**2.6 Plano de Execução (Fases)** — cada fase com:
-- Nome e objetivo
-- **Critério de DONE** — comportamento verificável e testável (não "código feito")
-- Lista de entregáveis concretos
-
-  > **Fase 1 é sempre containerização** (Dockerfile + docker-compose + healthcheck)
-  > **Fase N-1 é sempre auditoria de segurança e dependências**
-
-**2.7 Validation Gates por Stack**
-
-| Stack | Build | Test | Lint/Audit |
-|-------|-------|------|------------|
-| Rust/Axum | `cargo build` | `cargo test --workspace` | `cargo clippy && cargo audit` |
-| Node/NestJS | `npm run build` | `npm test` | `npx eslint src && npm audit --audit-level=high` |
-| Python/FastAPI | verificar imports | `pytest` | `ruff check . && pip-audit` |
-| PHP/Laravel | `php artisan config:cache` | `php artisan test` | `./vendor/bin/phpstan && composer audit` |
-| Go | `go build ./...` | `go test ./...` | `golangci-lint run` |
-
-**2.8 Controles de Segurança** — checklist com todos os RS-* do DESIGN mapeados para fases específicas
-
-**2.9 Estratégia de Testes** — unitários + integração + segurança (auditoria de deps) + E2E se frontend
-
-**2.10 Estratégia de Deploy** — por ambiente com branch, trigger e infra
-
-**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:
-
-_"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."_
-
-**Não gere** `DARE/TASKS.md`, `DARE/dare-dag.yaml` nem arquivos em `DARE/EXECUTION/`.
-Esses artefatos são responsabilidade exclusiva do `/dare-tasks`.
-
-$ARGUMENTS
+# /dare-blueprint
+
+Gera **somente** `DARE/BLUEPRINT.md` a partir do `DARE/DESIGN.md`.
+
+> Tasks, DAG e specs de execução são geradas depois com `/dare-tasks`, após aprovação humana do Blueprint.
+
+## Como usar
+
+```
+/dare-blueprint
+/dare-blueprint --stack node-nestjs+react
+```
+
+## O que fazer
+
+### 1. Ler `DARE/DESIGN.md`
+
+Obrigatório. Se não existir, peça para rodar `/dare-design` primeiro.
+
+Extraia e use durante todo o comando:
+- Stack técnica (linguagem, framework, versões)
+- Requisitos funcionais priorizados (RF-*)
+- Requisitos de segurança (RS-*)
+- Integrações externas confirmadas
+- Restrições e escopo
+
+### 2. Gerar `DARE/BLUEPRINT.md`
+
+Siga o template `templates/BLUEPRINT-template.md`. Seções obrigatórias:
+
+**2.1 Visão Geral da Arquitetura**
+- Diagrama Mermaid da arquitetura
+- Tabela de decisões arquiteturais com justificativa (não apenas "escolha X")
+
+**2.2 Stack Técnica Definida** — versões fixas, não ranges
+
+**2.3 Estrutura de Pastas** — árvore completa dos arquivos que serão criados
+
+**2.4 Modelo de Dados** — entidades, campos tipados, relacionamentos, índices necessários
+
+**2.5 Contratos de API** — tabela completa: método, rota, auth, request body, response, status codes
+
+**2.6 Plano de Execução (Fases)** — cada fase com:
+- Nome e objetivo
+- **Critério de DONE** — comportamento verificável e testável (não "código feito")
+- Lista de entregáveis concretos
+
+  > **Fase 1 é sempre containerização** (Dockerfile + docker-compose + healthcheck)
+  > **Fase N-1 é sempre auditoria de segurança e dependências**
+
+**2.7 Validation Gates por Stack**
+
+| Stack | Build | Test | Lint/Audit |
+|-------|-------|------|------------|
+| Rust/Axum | `cargo build` | `cargo test --workspace` | `cargo clippy && cargo audit` |
+| Node/NestJS | `npm run build` | `npm test` | `npx eslint src && npm audit --audit-level=high` |
+| Python/FastAPI | verificar imports | `pytest` | `ruff check . && pip-audit` |
+| PHP/Laravel | `php artisan config:cache` | `php artisan test` | `./vendor/bin/phpstan && composer audit` |
+| Go | `go build ./...` | `go test ./...` | `golangci-lint run` |
+
+**2.8 Controles de Segurança** — checklist com todos os RS-* do DESIGN mapeados para fases específicas
+
+**2.9 Estratégia de Testes** — unitários + integração + segurança (auditoria de deps) + E2E se frontend
+
+**2.10 Estratégia de Deploy** — por ambiente com branch, trigger e infra
+
+**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:
+
+_"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."_
+
+**Não gere** `DARE/TASKS.md`, `DARE/dare-dag.yaml` nem arquivos em `DARE/EXECUTION/`.
+Esses artefatos são responsabilidade exclusiva do `/dare-tasks`.
+
+$ARGUMENTS

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

@@ -1,27 +1,27 @@
-# /dare-bootstrap
-
-Executa o scaffolder oficial da stack registrada em `dare.config.json` para materializar o esqueleto do framework no projeto atual.
-
-> Este comando expõe o CLI `dare bootstrap` na IDE. O agente pode **rodar o comando no terminal** e interpretar a saída.
-
-## Quando usar
-
-- Logo após `dare init`, para gerar o esqueleto real do framework.
-- Quando `dare.config.json` existe mas os artefatos do framework ainda não foram gerados.
-
-## Como rodar
-
-```bash
-dare bootstrap
-dare bootstrap --force   # roda mesmo se já houver artefatos (pode sobrescrever)
-```
-
-## O que fazer
-
-1. Confirme que existe `dare.config.json` com a stack definida.
-2. Rode `dare bootstrap` (use `--force` apenas se o usuário aceitar sobrescrever arquivos existentes).
-3. Verifique a saída: arquivos gerados e próximos passos sugeridos pelo CLI.
-
-## Comandos relacionados
-
-`/dare-init` · `/dare-design`
+# /dare-bootstrap
+
+Executa o scaffolder oficial da stack registrada em `dare.config.json` para materializar o esqueleto do framework no projeto atual.
+
+> Este comando expõe o CLI `dare bootstrap` na IDE. O agente pode **rodar o comando no terminal** e interpretar a saída.
+
+## Quando usar
+
+- Logo após `dare init`, para gerar o esqueleto real do framework.
+- Quando `dare.config.json` existe mas os artefatos do framework ainda não foram gerados.
+
+## Como rodar
+
+```bash
+dare bootstrap
+dare bootstrap --force   # roda mesmo se já houver artefatos (pode sobrescrever)
+```
+
+## O que fazer
+
+1. Confirme que existe `dare.config.json` com a stack definida.
+2. Rode `dare bootstrap` (use `--force` apenas se o usuário aceitar sobrescrever arquivos existentes).
+3. Verifique a saída: arquivos gerados e próximos passos sugeridos pelo CLI.
+
+## Comandos relacionados
+
+`/dare-init` · `/dare-design`