@dewtech/dare-cli 3.3.0 → 3.4.0

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

@@ -1,221 +1,221 @@
----
-description: Como construir e executar grafos de tasks (DAG) do método DARE com paralelismo lógico via dare-dag.yaml. O Cursor é o executor; o CLI dare é orquestrador.
-globs: DARE/dare-dag.yaml,DARE/EXECUTION/**,DARE/.canvas.md
-alwaysApply: false
----
-
-# Skill: DAG Task Runner
-
-## Quando usar
-
-- O `BLUEPRINT.md` foi aprovado e você precisa decompor em tasks executáveis
-- O usuário pediu para começar a execução do DAG
-- Existe `DARE/dare-dag.yaml` e você precisa entender, executar ou modificar
-- Aparece o canvas `DARE/.canvas.md` durante uma execução
-
-## Quem executa o quê
-
-> **Você (Cursor) é o executor. O CLI `dare` é orquestrador.**
-
-- A IDE em que você roda já está autenticada na conta do usuário
-- Você lê o `dare-dag.yaml` e as specs em `DARE/EXECUTION/task-*.md`
-- Você executa cada task — escreve código, roda testes, faz lint
-- Depois de cada task, você chama o CLI para registrar o resultado:
-  - `dare execute --complete <task-id> --output "<resumo>"`
-  - `dare execute --fail <task-id> --reason "<mensagem>"`
-- O CLI atualiza o canvas e popula o `dare-graph` automaticamente
-
-**Não há API key. Não há custo extra de tokens. Você usa o plano da IDE.**
-
-## O que é o DAG do DARE
-
-`DARE/dare-dag.yaml` é o **plano de execução**: um grafo direcionado acíclico
-em que cada nó é uma task atômica e as arestas são `depends_on`. O CLI ordena
-topologicamente (Kahn's algorithm) e indica em que ordem você deve executar.
-Tasks no mesmo rank podem rodar em paralelo (logicamente — você decide se
-literalmente fan-out ou roda uma após a outra).
-
-```
-rank 0:  task-001    task-002      ←  podem rodar juntas (sem depends_on)
-rank 1:  task-003 (deps: 001, 002) ←  só após rank 0
-rank 2:  task-004 (deps: 003)
-```
-
-## Schema canônico do `dare-dag.yaml`
-
-```yaml
-title: "<Nome do projeto> - Development Tasks"
-version: "1.0.0"
-
-limits:
-  parent_context_chars: 2000   # snippet de cada output de pai injetado no filho
-  task_output_chars: 4000      # cap do output capturado por task
-  timeout_seconds: 600         # apenas referência; quem aborta é você
-
-# Mapeamento complexity → modelo (referencial — você usa o modelo da sua IDE)
-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: "Setup project structure"
-    depends_on: []
-    complexity: LOW
-    spec_file: EXECUTION/task-001.md
-    subtask_prompt: |
-      <prompt completamente self-contained>
-```
-
-## Loop de execução
-
-```
-1. dare execute --next
-   ↓ imprime prompts das tasks ready (rank atual)
-2. Para cada prompt:
-     - leia spec_file se houver
-     - implemente
-3. dare execute --complete <id> --output "<resumo + arquivos tocados>"
-     ↓ 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
-dare execute --next                                # próximas tasks ready (rank atual)
-dare execute --complete task-001 --output "..."    # marca DONE
-dare execute --fail task-002 --reason "..."        # marca FAILED + cascade-skip
-dare execute --reset task-002                      # volta para PENDING (retry)
-dare execute --status                              # snapshot do canvas
-```
-
-## Regras inegociáveis ao construir o DAG
-
-### 1. `id` em kebab-case e único
-`task-001`, `auth-jwt`, `db-migrations`. Sem espaços nem maiúsculas.
-
-### 2. `depends_on` mínimo — maximize paralelismo
-Só adicione dependência quando a task filha **literalmente não pode começar**
-sem o output da pai (arquivo, schema, decisão exportada).
-
-| Cenário | Dep? |
-|---------|------|
-| B precisa do arquivo que A criou | sim |
-| B precisa de uma decisão tomada em A | sim |
-| B faz coisa similar a A mas independente | não |
-| Pesquisa/leitura sem efeito colateral | não — fan out wide |
-| Testes do módulo X | sim — depende da implementação |
-| Docs do módulo X | sim — depende da implementação |
-
-Cadeia linear `001 → 002 → 003 → ...` é antipattern. Reanalise.
-
-### 3. `complexity` é referência (não custo real para você)
-| Nível | Quando usar |
-|-------|-------------|
-| `LOW`  | Setup, scaffolding, docs simples, leitura/pesquisa |
-| `MED`  | Implementação direta, refactors, testes unitários |
-| `HIGH` | Lógica de negócio crítica, segurança, integrações |
-
-Como você usa o plano da IDE, `complexity` virou principalmente um sinal para
-você priorizar atenção/cuidado, não para escolher modelo.
-
-### 4. `subtask_prompt` totalmente self-contained
-Sua sessão futura recebe o prompt + snippets de até 2000 chars dos outputs
-dos pais (via `dare execute --next`). Não vale "como combinamos antes".
-Tudo o que precisa estar no prompt ou virá pelos pais.
-
-### 5. Output cap de 4000 chars
-Se uma task gera muito, escreva em arquivo (permanece no FS) e faça o
-`--output` do `dare execute --complete` ser um resumo curto + caminhos dos
-arquivos criados.
-
-### 6. Cada task tem spec em `EXECUTION/task-<id>.md`
-Spec detalhada com: objetivo, arquivos a criar/modificar, validation gates,
-testes esperados. O `subtask_prompt` referencia `spec_file` para você ler na
-hora de executar.
-
-## Geração: o que o `/generate-tasks` deve produzir
-
-Sempre os **três artefatos juntos**:
-
-1. **`DARE/TASKS.md`** — tabela master para humanos
-2. **`DARE/dare-dag.yaml`** — grafo executável
-3. **`DARE/EXECUTION/task-<id>.md`** — uma spec por task
-
-Os três precisam estar consistentes (mesmos `id`s, mesmos `depends_on`,
-mesma `complexity`). Inconsistência aqui quebra a execução.
-
-## Canvas ao vivo (`DARE/.canvas.md`)
-
-O CLI reescreve `DARE/.canvas.md` a cada `dare execute --complete/--fail`:
-
-```
-| ID       | Title              | Status        | Duration | Tokens |
-|----------|--------------------|---------------|----------|--------|
-| task-001 | Setup structure    | ✅ DONE       | 1240ms   | 850    |
-| task-002 | DB schema          | 🔄 RUNNING    | -        | -      |
-| task-003 | Core endpoints     | ⏳ PENDING    | -        | -      |
-```
-
-Status: `PENDING` ⏳ · `RUNNING` 🔄 · `DONE` ✅ · `FAILED` ❌ · `SKIPPED` ⏭️
-
-`SKIPPED` é automático quando uma dependência falha — você não precisa fazer
-nada; o CLI cuida do cascade.
-
-## Erros comuns ao construir DAG
-
-| Erro | Sintoma | Como corrigir |
-|------|---------|---------------|
-| Ciclo em `depends_on` | `Circular dependency detected: <id>` | Reveja, retire a aresta cíclica |
-| `id` duplicado | Comportamento indefinido | Renomeie |
-| `depends_on` aponta para `id` inexistente | `Task not found: <id>` | Corrija nome |
-| 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
-- [ ] Cada `subtask_prompt` é executável sem contexto adicional
-- [ ] Tasks de teste/doc dependem da implementação correspondente
-- [ ] `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
+---
+description: Como construir e executar grafos de tasks (DAG) do método DARE com paralelismo lógico via dare-dag.yaml. O Cursor é o executor; o CLI dare é orquestrador.
+globs: DARE/dare-dag.yaml,DARE/EXECUTION/**,DARE/.canvas.md
+alwaysApply: false
+---
+
+# Skill: DAG Task Runner
+
+## Quando usar
+
+- O `BLUEPRINT.md` foi aprovado e você precisa decompor em tasks executáveis
+- O usuário pediu para começar a execução do DAG
+- Existe `DARE/dare-dag.yaml` e você precisa entender, executar ou modificar
+- Aparece o canvas `DARE/.canvas.md` durante uma execução
+
+## Quem executa o quê
+
+> **Você (Cursor) é o executor. O CLI `dare` é orquestrador.**
+
+- A IDE em que você roda já está autenticada na conta do usuário
+- Você lê o `dare-dag.yaml` e as specs em `DARE/EXECUTION/task-*.md`
+- Você executa cada task — escreve código, roda testes, faz lint
+- Depois de cada task, você chama o CLI para registrar o resultado:
+  - `dare execute --complete <task-id> --output "<resumo>"`
+  - `dare execute --fail <task-id> --reason "<mensagem>"`
+- O CLI atualiza o canvas e popula o `dare-graph` automaticamente
+
+**Não há API key. Não há custo extra de tokens. Você usa o plano da IDE.**
+
+## O que é o DAG do DARE
+
+`DARE/dare-dag.yaml` é o **plano de execução**: um grafo direcionado acíclico
+em que cada nó é uma task atômica e as arestas são `depends_on`. O CLI ordena
+topologicamente (Kahn's algorithm) e indica em que ordem você deve executar.
+Tasks no mesmo rank podem rodar em paralelo (logicamente — você decide se
+literalmente fan-out ou roda uma após a outra).
+
+```
+rank 0:  task-001    task-002      ←  podem rodar juntas (sem depends_on)
+rank 1:  task-003 (deps: 001, 002) ←  só após rank 0
+rank 2:  task-004 (deps: 003)
+```
+
+## Schema canônico do `dare-dag.yaml`
+
+```yaml
+title: "<Nome do projeto> - Development Tasks"
+version: "1.0.0"
+
+limits:
+  parent_context_chars: 2000   # snippet de cada output de pai injetado no filho
+  task_output_chars: 4000      # cap do output capturado por task
+  timeout_seconds: 600         # apenas referência; quem aborta é você
+
+# Mapeamento complexity → modelo (referencial — você usa o modelo da sua IDE)
+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: "Setup project structure"
+    depends_on: []
+    complexity: LOW
+    spec_file: EXECUTION/task-001.md
+    subtask_prompt: |
+      <prompt completamente self-contained>
+```
+
+## Loop de execução
+
+```
+1. dare execute --next
+   ↓ imprime prompts das tasks ready (rank atual)
+2. Para cada prompt:
+     - leia spec_file se houver
+     - implemente
+3. dare execute --complete <id> --output "<resumo + arquivos tocados>"
+     ↓ 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
+dare execute --next                                # próximas tasks ready (rank atual)
+dare execute --complete task-001 --output "..."    # marca DONE
+dare execute --fail task-002 --reason "..."        # marca FAILED + cascade-skip
+dare execute --reset task-002                      # volta para PENDING (retry)
+dare execute --status                              # snapshot do canvas
+```
+
+## Regras inegociáveis ao construir o DAG
+
+### 1. `id` em kebab-case e único
+`task-001`, `auth-jwt`, `db-migrations`. Sem espaços nem maiúsculas.
+
+### 2. `depends_on` mínimo — maximize paralelismo
+Só adicione dependência quando a task filha **literalmente não pode começar**
+sem o output da pai (arquivo, schema, decisão exportada).
+
+| Cenário | Dep? |
+|---------|------|
+| B precisa do arquivo que A criou | sim |
+| B precisa de uma decisão tomada em A | sim |
+| B faz coisa similar a A mas independente | não |
+| Pesquisa/leitura sem efeito colateral | não — fan out wide |
+| Testes do módulo X | sim — depende da implementação |
+| Docs do módulo X | sim — depende da implementação |
+
+Cadeia linear `001 → 002 → 003 → ...` é antipattern. Reanalise.
+
+### 3. `complexity` é referência (não custo real para você)
+| Nível | Quando usar |
+|-------|-------------|
+| `LOW`  | Setup, scaffolding, docs simples, leitura/pesquisa |
+| `MED`  | Implementação direta, refactors, testes unitários |
+| `HIGH` | Lógica de negócio crítica, segurança, integrações |
+
+Como você usa o plano da IDE, `complexity` virou principalmente um sinal para
+você priorizar atenção/cuidado, não para escolher modelo.
+
+### 4. `subtask_prompt` totalmente self-contained
+Sua sessão futura recebe o prompt + snippets de até 2000 chars dos outputs
+dos pais (via `dare execute --next`). Não vale "como combinamos antes".
+Tudo o que precisa estar no prompt ou virá pelos pais.
+
+### 5. Output cap de 4000 chars
+Se uma task gera muito, escreva em arquivo (permanece no FS) e faça o
+`--output` do `dare execute --complete` ser um resumo curto + caminhos dos
+arquivos criados.
+
+### 6. Cada task tem spec em `EXECUTION/task-<id>.md`
+Spec detalhada com: objetivo, arquivos a criar/modificar, validation gates,
+testes esperados. O `subtask_prompt` referencia `spec_file` para você ler na
+hora de executar.
+
+## Geração: o que o `/generate-tasks` deve produzir
+
+Sempre os **três artefatos juntos**:
+
+1. **`DARE/TASKS.md`** — tabela master para humanos
+2. **`DARE/dare-dag.yaml`** — grafo executável
+3. **`DARE/EXECUTION/task-<id>.md`** — uma spec por task
+
+Os três precisam estar consistentes (mesmos `id`s, mesmos `depends_on`,
+mesma `complexity`). Inconsistência aqui quebra a execução.
+
+## Canvas ao vivo (`DARE/.canvas.md`)
+
+O CLI reescreve `DARE/.canvas.md` a cada `dare execute --complete/--fail`:
+
+```
+| ID       | Title              | Status        | Duration | Tokens |
+|----------|--------------------|---------------|----------|--------|
+| task-001 | Setup structure    | ✅ DONE       | 1240ms   | 850    |
+| task-002 | DB schema          | 🔄 RUNNING    | -        | -      |
+| task-003 | Core endpoints     | ⏳ PENDING    | -        | -      |
+```
+
+Status: `PENDING` ⏳ · `RUNNING` 🔄 · `DONE` ✅ · `FAILED` ❌ · `SKIPPED` ⏭️
+
+`SKIPPED` é automático quando uma dependência falha — você não precisa fazer
+nada; o CLI cuida do cascade.
+
+## Erros comuns ao construir DAG
+
+| Erro | Sintoma | Como corrigir |
+|------|---------|---------------|
+| Ciclo em `depends_on` | `Circular dependency detected: <id>` | Reveja, retire a aresta cíclica |
+| `id` duplicado | Comportamento indefinido | Renomeie |
+| `depends_on` aponta para `id` inexistente | `Task not found: <id>` | Corrija nome |
+| 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
+- [ ] Cada `subtask_prompt` é executável sem contexto adicional
+- [ ] Tasks de teste/doc dependem da implementação correspondente
+- [ ] `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

package/templates/ide/cursor/.cursor/rules/skill-dna.mdc

@@ -1,63 +1,63 @@
----
-description: Camada semântica da extração de DNA do projeto. Roda depois do comando `dare dna` e transforma os fatos de convenção em regras acionáveis no DARE/PROJECT-DNA.md, para o agente seguir o padrão da casa em projetos legados.
-globs: DARE/PROJECT-DNA.md,DARE/dna-facts.json
-alwaysApply: false
----
-
-# Skill: DNA — Convenções do Projeto (brownfield)
-
-Camada **semântica** da extração de DNA. Roda **depois** do comando `dare dna`, que já varreu o código
-e extraiu os fatos de convenção. Sua função é **transformar fatos em regras acionáveis** — o "como esse
-codebase faz as coisas" que uma nova feature deve respeitar.
-
-> Pré-requisito: rodar `dare dna` antes (gera `DARE/PROJECT-DNA.md` e `DARE/dna-facts.json`).
-> Se não existirem, peça para rodar `dare dna` primeiro.
-
-## Quando usar
-
-- Projeto **legado** que vai adotar o DARE para novas features, sem reescrever o existente.
-- Acabou de rodar `dare dna` e o `PROJECT-DNA.md` tem seções `<!-- AGENT -->` em aberto.
-
-## O que fazer
-
-### 1. Carregar os fatos (não re-varrer tudo)
-- Leia `DARE/dna-facts.json` — fonte determinística (tooling, naming, camadas, testes, libs, commits).
-- Abra **2-5 arquivos representativos por camada** (controller, service, model, teste) para inferir o
-  que o CLI não detecta (tratamento de erro, validação, estilo de teste).
-
-### 2. Preencher `DARE/PROJECT-DNA.md`
-Substitua cada `<!-- AGENT: ... -->`:
-- **Convenções de Nomenclatura** — confirme o estilo + exceções.
-- **Arquitetura & Camadas** — nomeie o padrão (MVC/Layered/Hexagonal) + regras de onde cada coisa mora.
-- **Padrões de Teste** — onde ficam, naming, assertions reais, mocks/fixtures.
-- **Tratamento de Erros & Validação** — como erros são tratados e inputs validados (exemplos reais).
-- **Regras de Ouro** — o que SEMPRE e NUNCA fazer neste codebase.
-- **⚠️ Incertezas** — convenções ambíguas que o humano precisa decidir.
-
-**Não toque** nos fatos determinísticos do CLI (tooling, tabela de naming, libs).
-
-### 3. Apresentar ao usuário
-Resumo: arquitetura nomeada, regras de ouro, inconsistências. O `PROJECT-DNA.md` vira referência para
-`skill-feature-design` e `skill-execute` respeitarem o legado.
-
-## Regras de ouro
-
-1. **Descritivo, não aspiracional** — como o código É, não como deveria ser.
-2. **Exemplos reais** — cite arquivos/trechos do projeto.
-3. **Sinalize inconsistência** — não invente um padrão único onde o legado mistura.
-4. **Não re-varra** — os fatos já estão em `dna-facts.json`.
-5. **Preserve o determinístico** — não reescreva tooling/naming/libs do CLI.
-
-## Antipatterns
-
-| AP | Antipattern | Por quê |
-|---|---|---|
-| AP-01 | Documentar o padrão "ideal" em vez do real | Código gerado sai fora do estilo do legado |
-| AP-02 | Forçar padrão único onde o legado é inconsistente | Esconde a realidade |
-| AP-03 | Reescrever os fatos determinísticos do CLI | Quebra a fonte de verdade |
-| AP-04 | Regras vagas ("siga boas práticas") | Inúteis — o valor está no específico |
-| AP-05 | Ignorar os testes existentes | Nova feature nasce inconsistente |
-
----
-
-Skill MIT — parte do DARE Method. DNA do projeto (brownfield). Pareia com o comando `dare dna`.
+---
+description: Camada semântica da extração de DNA do projeto. Roda depois do comando `dare dna` e transforma os fatos de convenção em regras acionáveis no DARE/PROJECT-DNA.md, para o agente seguir o padrão da casa em projetos legados.
+globs: DARE/PROJECT-DNA.md,DARE/dna-facts.json
+alwaysApply: false
+---
+
+# Skill: DNA — Convenções do Projeto (brownfield)
+
+Camada **semântica** da extração de DNA. Roda **depois** do comando `dare dna`, que já varreu o código
+e extraiu os fatos de convenção. Sua função é **transformar fatos em regras acionáveis** — o "como esse
+codebase faz as coisas" que uma nova feature deve respeitar.
+
+> Pré-requisito: rodar `dare dna` antes (gera `DARE/PROJECT-DNA.md` e `DARE/dna-facts.json`).
+> Se não existirem, peça para rodar `dare dna` primeiro.
+
+## Quando usar
+
+- Projeto **legado** que vai adotar o DARE para novas features, sem reescrever o existente.
+- Acabou de rodar `dare dna` e o `PROJECT-DNA.md` tem seções `<!-- AGENT -->` em aberto.
+
+## O que fazer
+
+### 1. Carregar os fatos (não re-varrer tudo)
+- Leia `DARE/dna-facts.json` — fonte determinística (tooling, naming, camadas, testes, libs, commits).
+- Abra **2-5 arquivos representativos por camada** (controller, service, model, teste) para inferir o
+  que o CLI não detecta (tratamento de erro, validação, estilo de teste).
+
+### 2. Preencher `DARE/PROJECT-DNA.md`
+Substitua cada `<!-- AGENT: ... -->`:
+- **Convenções de Nomenclatura** — confirme o estilo + exceções.
+- **Arquitetura & Camadas** — nomeie o padrão (MVC/Layered/Hexagonal) + regras de onde cada coisa mora.
+- **Padrões de Teste** — onde ficam, naming, assertions reais, mocks/fixtures.
+- **Tratamento de Erros & Validação** — como erros são tratados e inputs validados (exemplos reais).
+- **Regras de Ouro** — o que SEMPRE e NUNCA fazer neste codebase.
+- **⚠️ Incertezas** — convenções ambíguas que o humano precisa decidir.
+
+**Não toque** nos fatos determinísticos do CLI (tooling, tabela de naming, libs).
+
+### 3. Apresentar ao usuário
+Resumo: arquitetura nomeada, regras de ouro, inconsistências. O `PROJECT-DNA.md` vira referência para
+`skill-feature-design` e `skill-execute` respeitarem o legado.
+
+## Regras de ouro
+
+1. **Descritivo, não aspiracional** — como o código É, não como deveria ser.
+2. **Exemplos reais** — cite arquivos/trechos do projeto.
+3. **Sinalize inconsistência** — não invente um padrão único onde o legado mistura.
+4. **Não re-varra** — os fatos já estão em `dna-facts.json`.
+5. **Preserve o determinístico** — não reescreva tooling/naming/libs do CLI.
+
+## Antipatterns
+
+| AP | Antipattern | Por quê |
+|---|---|---|
+| AP-01 | Documentar o padrão "ideal" em vez do real | Código gerado sai fora do estilo do legado |
+| AP-02 | Forçar padrão único onde o legado é inconsistente | Esconde a realidade |
+| AP-03 | Reescrever os fatos determinísticos do CLI | Quebra a fonte de verdade |
+| AP-04 | Regras vagas ("siga boas práticas") | Inúteis — o valor está no específico |
+| AP-05 | Ignorar os testes existentes | Nova feature nasce inconsistente |
+
+---
+
+Skill MIT — parte do DARE Method. DNA do projeto (brownfield). Pareia com o comando `dare dna`.

package/templates/ide/cursor/.cursor/rules/skill-docker.mdc

@@ -1,33 +1,33 @@
----
-description: Padrões Globais para Containerização com Docker e Docker Compose
-globs: Dockerfile*, docker-compose*.yml, .dockerignore
----
-# Regras Globais do Projeto (Docker e Containerização)
-
-Você é um engenheiro DevOps Especialista focado em segurança, performance e melhores práticas para criação de containers Docker e orquestração com Docker Compose.
-
-## Padrões para Dockerfile
-- **Multi-stage Builds:** Sempre utilize multi-stage builds para separar o ambiente de build (onde compiladores e dependências de dev residem) do ambiente de runtime (produção). Isso reduz drasticamente o tamanho final da imagem.
-- **Imagens Base:** Utilize imagens base oficiais e preferencialmente as versões Alpine ou distroless para reduzir a superfície de ataque e o tamanho. Especifique tags exatas (ex: `php:8.3-fpm-alpine` em vez de `php:latest`).
-- **Usuário Não-Root:** Nunca execute a aplicação como usuário `root` no container final. Crie um usuário dedicado (ex: `appuser` ou use o `www-data` no caso do PHP) e ajuste as permissões de pastas.
-- **Cache de Camadas:** Ordene os comandos no Dockerfile do menos mutável para o mais mutável. Copie arquivos de dependência (como `composer.json`, `package.json`, `requirements.txt`, `go.mod`) e instale dependências ANTES de copiar o código fonte da aplicação.
-- **Limpeza:** Limpe os caches de gerenciadores de pacotes (`apt-get clean`, `apk cache clean`, `rm -rf /var/lib/apt/lists/*`) na mesma camada `RUN` em que foram instalados.
-- **ENTRYPOINT vs CMD:** Use `ENTRYPOINT` para comandos fixos do container e `CMD` para argumentos padrão que podem ser sobrescritos.
-
-## Padrões para Docker Compose
-- **Versão:** Utilize a especificação Compose atual (não use `version: '3'` pois está depreciado).
-- **Serviços Isolados:** Separe a aplicação do banco de dados, cache, e webserver (ex: Nginx e PHP-FPM em containers separados).
-- **Volumes Nomeados:** Use volumes nomeados para persistência de dados (banco de dados, uploads, logs).
-- **Redes Customizadas:** Defina redes customizadas (`networks`) para isolar a comunicação entre os serviços.
-- **Variáveis de Ambiente:** Utilize arquivos `.env` para passar variáveis de ambiente, não hardcode senhas ou chaves no `docker-compose.yml`.
-- **Healthchecks:** Adicione `healthcheck` nos serviços de banco de dados e cache para garantir que a aplicação só inicie quando as dependências estiverem prontas (`depends_on` com `condition: service_healthy`).
-
-## Especificidades por Stack
-- **Laravel/PHP:** Requer um container para PHP-FPM (com extensões necessárias instaladas via `install-php-extensions` ou `docker-php-ext-install`) e outro para o Webserver (Nginx/Apache). O diretório de trabalho padrão deve ser `/var/www/html`. Ajuste permissões para as pastas `storage` e `bootstrap/cache`.
-- **Python (FastAPI/Flask):** Use `python:3.11-slim`. Não execute como root. Instale dependências sem cache (`pip install --no-cache-dir`). Exponha a porta correta (geralmente 8000 ou 5000).
-- **Go:** O estágio de build deve usar `golang:1.22-alpine` para compilar um binário estático. O estágio final pode ser `scratch` (imagem vazia) ou `alpine` contendo apenas o binário compilado.
-- **Vue.js/Frontend:** O estágio de build usa Node.js para gerar os arquivos estáticos (`npm run build`). O estágio final usa Nginx (`nginx:alpine`) para servir a pasta `dist`.
-
-## Segurança
-- Não copie arquivos desnecessários. Crie sempre um `.dockerignore` bem configurado (ignorando `.git`, `node_modules`, `vendor`, `.env`).
-- Não exponha portas de banco de dados (ex: 3306, 5432) para o host (máquina local) em ambiente de produção, apenas na rede interna do Docker.
+---
+description: Padrões Globais para Containerização com Docker e Docker Compose
+globs: Dockerfile*, docker-compose*.yml, .dockerignore
+---
+# Regras Globais do Projeto (Docker e Containerização)
+
+Você é um engenheiro DevOps Especialista focado em segurança, performance e melhores práticas para criação de containers Docker e orquestração com Docker Compose.
+
+## Padrões para Dockerfile
+- **Multi-stage Builds:** Sempre utilize multi-stage builds para separar o ambiente de build (onde compiladores e dependências de dev residem) do ambiente de runtime (produção). Isso reduz drasticamente o tamanho final da imagem.
+- **Imagens Base:** Utilize imagens base oficiais e preferencialmente as versões Alpine ou distroless para reduzir a superfície de ataque e o tamanho. Especifique tags exatas (ex: `php:8.3-fpm-alpine` em vez de `php:latest`).
+- **Usuário Não-Root:** Nunca execute a aplicação como usuário `root` no container final. Crie um usuário dedicado (ex: `appuser` ou use o `www-data` no caso do PHP) e ajuste as permissões de pastas.
+- **Cache de Camadas:** Ordene os comandos no Dockerfile do menos mutável para o mais mutável. Copie arquivos de dependência (como `composer.json`, `package.json`, `requirements.txt`, `go.mod`) e instale dependências ANTES de copiar o código fonte da aplicação.
+- **Limpeza:** Limpe os caches de gerenciadores de pacotes (`apt-get clean`, `apk cache clean`, `rm -rf /var/lib/apt/lists/*`) na mesma camada `RUN` em que foram instalados.
+- **ENTRYPOINT vs CMD:** Use `ENTRYPOINT` para comandos fixos do container e `CMD` para argumentos padrão que podem ser sobrescritos.
+
+## Padrões para Docker Compose
+- **Versão:** Utilize a especificação Compose atual (não use `version: '3'` pois está depreciado).
+- **Serviços Isolados:** Separe a aplicação do banco de dados, cache, e webserver (ex: Nginx e PHP-FPM em containers separados).
+- **Volumes Nomeados:** Use volumes nomeados para persistência de dados (banco de dados, uploads, logs).
+- **Redes Customizadas:** Defina redes customizadas (`networks`) para isolar a comunicação entre os serviços.
+- **Variáveis de Ambiente:** Utilize arquivos `.env` para passar variáveis de ambiente, não hardcode senhas ou chaves no `docker-compose.yml`.
+- **Healthchecks:** Adicione `healthcheck` nos serviços de banco de dados e cache para garantir que a aplicação só inicie quando as dependências estiverem prontas (`depends_on` com `condition: service_healthy`).
+
+## Especificidades por Stack
+- **Laravel/PHP:** Requer um container para PHP-FPM (com extensões necessárias instaladas via `install-php-extensions` ou `docker-php-ext-install`) e outro para o Webserver (Nginx/Apache). O diretório de trabalho padrão deve ser `/var/www/html`. Ajuste permissões para as pastas `storage` e `bootstrap/cache`.
+- **Python (FastAPI/Flask):** Use `python:3.11-slim`. Não execute como root. Instale dependências sem cache (`pip install --no-cache-dir`). Exponha a porta correta (geralmente 8000 ou 5000).
+- **Go:** O estágio de build deve usar `golang:1.22-alpine` para compilar um binário estático. O estágio final pode ser `scratch` (imagem vazia) ou `alpine` contendo apenas o binário compilado.
+- **Vue.js/Frontend:** O estágio de build usa Node.js para gerar os arquivos estáticos (`npm run build`). O estágio final usa Nginx (`nginx:alpine`) para servir a pasta `dist`.
+
+## Segurança
+- Não copie arquivos desnecessários. Crie sempre um `.dockerignore` bem configurado (ignorando `.git`, `node_modules`, `vendor`, `.env`).
+- Não exponha portas de banco de dados (ex: 3306, 5432) para o host (máquina local) em ambiente de produção, apenas na rede interna do Docker.