@dewtech/dare-cli 2.16.0 → 3.0.0

package/templates/ide/claude/.claude/commands/dare-llm-integration.md

@@ -0,0 +1,148 @@
+# /dare-llm-integration
+
+Integração segura e eficiente com LLMs (Gemini, Claude, OpenAI, Ollama) em projetos DARE.
+
+## Como usar
+
+```
+/dare-llm-integration                       # audita uso de LLM no projeto
+/dare-llm-integration scaffold              # gera LLMProvider + cache + rate limit
+/dare-llm-integration prompts               # extrai prompts inline para arquivos versionados
+```
+
+## Os 5 pilares
+
+### 1. LLMProvider abstraction
+
+Nunca chame SDK do Gemini/OpenAI direto em Handler ou Service de negócio. Sempre via interface `LLMProvider`.
+
+### 2. Cache TTL
+
+Toda chamada passa por cache. Key = `hash(promptId + input + model)`. TTL default 1h.
+
+### 3. Rate limit via token bucket
+
+Token bucket por provider:
+- Gemini Free: 15 RPM, 1M tokens/dia
+- Claude tier 1: 50 RPM
+- OpenAI tier 1: 500 RPM
+
+### 4. Prompts versionados
+
+Nunca inline em código. Vivem em `prompts/<id>.v<n>.md` com frontmatter (model, temperature, schema).
+
+### 5. Validação via schema
+
+LLM mente — sempre valide output com Zod/Pydantic/serde.
+
+## Métricas obrigatórias
+
+| ID | Métrica |
+|---|---|
+| M-01 | 100% das chamadas LLM via LLMProvider injetado |
+| M-02 | 100% das responses LLM cacheadas |
+| M-03 | 100% das requests com rate limit |
+| M-04 | 100% das respostas validadas contra schema |
+
+## Antipatterns
+
+| AP | Antipattern | Por quê |
+|---|---|---|
+| AP-01 | SDK direto em Handler | impossível mockar/trocar provider |
+| AP-02 | Sem cache | custo explode |
+| AP-03 | Prompt em código | impossível versionar/A-B |
+| AP-04 | User input direto em prompt | prompt injection trivial |
+| AP-05 | Trusting LLM output | LLM mente, schema é defesa |
+
+## Defesa contra prompt injection
+
+```python
+# ❌ Concatenação direta
+system = f"You are an assistant. {user_question}"
+
+# ✅ Separação por delimitador + escape
+messages = [
+    {"role": "system", "content": "You are an assistant. Answer based on the document below."},
+    {"role": "user", "content": f"<document>{escape(doc)}</document>\n<question>{escape(q)}</question>"}
+]
+```
+
+Regras:
+- Use delimitadores (`<document>`, `<question>`)
+- Escape conteúdo do usuário (XML/HTML escape)
+- Detecte "Ignore instructions above"
+- Valide output — fora do schema = sinal de injection
+
+## O que fazer
+
+### Passo 1: Auditar chamadas LLM
+
+```bash
+grep -rn "GoogleGenAI\\|new OpenAI\\|Anthropic(" src/
+```
+
+Toda ocorrência em Handler ou Service de negócio = AP-01.
+
+### Passo 2: Criar `LLMProvider` interface
+
+```typescript
+interface LLMProvider {
+  complete(req: {
+    promptId: string;
+    input: Record<string, unknown>;
+    schema: ZodSchema;
+  }): Promise<unknown>;
+}
+```
+
+### Passo 3: Implementar providers
+
+Comece com o que o projeto usa. Use os exemplos em `packages/skills/dare-llm-integration/providers/`.
+
+### Passo 4: Configurar cache + rate limit
+
+Cache em memória com TTL + token bucket por provider. Implementação pronta em `packages/skills/dare-llm-integration/cache/` e `.../rate_limit/`.
+
+### Passo 5: Extrair prompts inline
+
+Para cada prompt inline encontrado, mova para `prompts/<id>.v1.md` com frontmatter:
+
+```markdown
+---
+id: summarize
+version: 1
+model: gemini-2.0-flash
+temperature: 0.2
+max_tokens: 500
+schema: SummarySchema
+---
+
+# System
+You are a concise summarizer.
+
+# User
+Summarize: <text>{{ text }}</text>
+```
+
+### Passo 6: Adicionar validação no chamador
+
+```typescript
+const raw = await llm.complete({...});
+const parsed = SummarySchema.parse(raw);  // joga LLMOutputInvalidError se falhar
+```
+
+## Saída esperada
+
+Reporte numerado:
+- Quantas chamadas LLM no projeto
+- Quantas via LLMProvider (M-01)
+- Quantas cacheadas (M-02)
+- Quantas com rate limit (M-03)
+- Quantas validadas contra schema (M-04)
+- Lista de prompts inline a extrair
+
+$ARGUMENTS
+
+---
+
+Skill MIT — parte do DARE Method.

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

@@ -0,0 +1,72 @@
+# /dare-migrate
+
+Camada semântica da migração (Fase 2 brownfield). Roda **depois** de `dare migrate`, que já leu os
+artefatos do `reverse`/`dna` e gerou os esqueletos. Sua função é **escrever a estratégia de migração
+e os cenários Gherkin de paridade reais** — o contrato comportamental que garante uma reimplementação
+fiel ao legado.
+
+## Como usar
+
+```
+/dare-migrate
+```
+
+> Pré-requisito: rodar `dare migrate --to <stack>` antes (gera `DARE/MIGRATION/MIGRATION.md`,
+> `migration-facts.json` e `parity/*.feature`). Isso por sua vez exige `dare reverse` já executado.
+
+## Quando usar
+
+- Projeto legado entendido (`reverse` + `dna` feitos) que será **reimplementado** em outra stack.
+- Acabou de rodar `dare migrate` e o `MIGRATION.md`/`.feature` têm seções `<!-- AGENT -->`/`# AGENT`.
+
+## O que fazer
+
+### 1. Carregar contexto (não re-varrer)
+- Leia `DARE/MIGRATION/migration-facts.json` (origem, alvo, módulos, blocking gaps).
+- Leia `DARE/IDEIA.md` + `DARE/REVERSE/module-*.md` (o que cada módulo faz) e `DARE/PROJECT-DNA.md`
+  (convenções). Abra arquivos-chave do legado só o necessário para inferir comportamento.
+
+### 2. Preencher `DARE/MIGRATION/MIGRATION.md`
+- **Decisão de Paradigma** — origem e alvo mudam de paradigma (procedural→OO, monólito→serviços)?
+  Registre decisão + justificativa; se preservado, diga.
+- **Estratégia de Migração** — big-bang vs. **strangler/parallel-run**; ordem dos módulos; feature flags.
+- **Registro de Risco** — para cada **blocking gap** (🔴) pré-listado, escreva o tratamento; some os
+  riscos de regressão/dados/performance + mitigações.
+- **Arquitetura-alvo** — desenhe na stack-alvo, **alinhada ao DNA** (camadas/convenções) quando o
+  paradigma for preservado; senão justifique a nova organização.
+- **Plano de Cutover & Rollback** — passos de corte, validação de paridade (rodar os `.feature`),
+  critério de go/no-go e rollback.
+
+### 3. Escrever os Gherkin de paridade (`parity/<módulo>.feature`)
+- Um `Scenario` por **fluxo observável** do módulo, derivado do **comportamento legado real**
+  (não invente). `Given` estado inicial → `When` ação → `Then` resultado **idêntico ao legado**.
+- Inclua casos de borda e formatação que o legado garante (ex.: arredondamento monetário, máscaras).
+- Esses `.feature` são o **contrato de aceite** da reimplementação na stack-alvo.
+
+### 4. Apresentar ao usuário
+Resumo: decisão de paradigma, estratégia, nº de cenários de paridade, blocking gaps a resolver.
+Reforce que cenários de paridade só valem se vierem do comportamento legado observado.
+
+## Regras de ouro
+
+1. **Paridade primeiro** — o objetivo é não quebrar comportamento; todo fluxo crítico vira `Scenario`.
+2. **Blocking gaps são bloqueantes** — um 🔴 não resolvido é risco de reimplementação; trate ou registre.
+3. **Respeite o DNA** — a arquitetura-alvo segue as convenções da casa quando faz sentido.
+4. **Não invente comportamento** — cenário sem base no legado é fonte de regressão silenciosa.
+5. **Strangler quando possível** — migração incremental com parallel-run reduz risco vs. big-bang.
+
+## Antipatterns
+
+| AP | Antipattern | Por quê |
+|---|---|---|
+| AP-01 | Gherkin genérico sem base no legado | Não garante paridade — vira regressão |
+| AP-02 | Ignorar blocking gaps (🔴) | Reimplementa em cima de incerteza |
+| AP-03 | Big-bang sem necessidade | Maximiza risco e dificulta rollback |
+| AP-04 | Arquitetura-alvo desalinhada do DNA | Código novo vira ilha inconsistente |
+| AP-05 | Reescrever os fatos determinísticos do CLI | Quebra a fonte de verdade |
+
+$ARGUMENTS
+
+---
+
+Skill MIT — parte do DARE Method. Fase 2 (brownfield). Pareia com o comando `dare migrate`.

package/templates/ide/claude/.claude/commands/dare-quality-telemetry.md

@@ -0,0 +1,166 @@
+# /dare-quality-telemetry
+
+Coleta métricas das skills DARE (ax, layered-design, llm-integration, frontend, realtime…), persiste histórico em `tmp/dare_metrics.json` e detecta regressões contra baseline.
+
+## Como usar
+
+```
+/dare-quality-telemetry collect          # roda todos os collectors
+/dare-quality-telemetry baseline         # captura baseline atual
+/dare-quality-telemetry compare          # compara contra baseline (CI)
+/dare-quality-telemetry report           # gera markdown report
+```
+
+## O que faz
+
+1. Roda collectors das skills configuradas em paralelo
+2. Agrega em um snapshot
+3. Persiste em `tmp/dare_metrics.json`
+4. Compara com `tmp/dare_metrics_baseline.json`
+5. Reporta em markdown / JSON
+6. Exit code ≠ 0 se regressão crítica
+
+## Arquitetura
+
+```
+collect.ts
+  ↓ chama em paralelo
+[ax collector] [layered coll.] [llm coll.] [frontend coll.] [realtime coll.]
+  ↓
+Aggregator → snapshot { skill: { M-01: value, ... } }
+  ↓
+tmp/dare_metrics.json + Regression detector
+  ↓
+Reporter → markdown / JSON / GH Actions summary
+```
+
+## Métricas obrigatórias
+
+| ID | Métrica |
+|---|---|
+| M-01 | 100% dos builds incluem coleta (skill instalada = true) |
+| M-02 | 0 regressões passam despercebidas (baseline existe) |
+| M-03 | Histórico mantido em `tmp/dare_metrics.json` |
+| M-04 | Workflow `.github/workflows/dare-metrics.yml` existe |
+
+## Configuração
+
+```yaml
+# dare.config.yml
+telemetry:
+  skills:
+    - dare-ax
+    - dare-layered-design
+    - dare-llm-integration
+    - dare-frontend-design
+    - dare-realtime
+  output: tmp/dare_metrics.json
+  baseline: tmp/dare_metrics_baseline.json
+  fail_on_regression: true
+```
+
+## Schema do snapshot
+
+```json
+{
+  "timestamp": "2026-05-26T10:30:00Z",
+  "commit": "1d4a1417",
+  "branch": "main",
+  "skills": {
+    "dare-ax": {
+      "M-01": { "value": 1.0, "status": "PASS" },
+      "M-04": { "value": 1.0, "status": "PASS" }
+    },
+    "dare-layered-design": {
+      "M-01": { "value": 0.95, "status": "PASS" }
+    }
+  }
+}
+```
+
+## Detecção de regressão
+
+| Mudança | Severidade | Ação |
+|---|---|---|
+| value caiu ≥ 5% | CRITICAL | bloquear PR |
+| value caiu < 5% mas ≥ 1% | WARNING | comentar no PR |
+| value subiu | INFO | celebrar |
+| value igual | NEUTRAL | nenhuma |
+
+## O que fazer
+
+### Passo 1: Instalar
+
+```bash
+pnpm add @dare/quality-telemetry
+```
+
+### Passo 2: Configurar `dare.config.yml`
+
+Listar as skills filhas a rastrear.
+
+### Passo 3: Rodar collect
+
+```bash
+dare metrics collect
+```
+
+### Passo 4: Capturar baseline
+
+```bash
+dare metrics baseline
+```
+
+Geralmente capturado uma vez por release tag, não a cada commit.
+
+### Passo 5: Workflow CI
+
+```yaml
+# .github/workflows/dare-metrics.yml
+name: DARE Metrics
+on: [push, pull_request]
+jobs:
+  metrics:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with: { node-version: '20' }
+      - run: pnpm install
+      - run: pnpm dare metrics collect
+      - run: pnpm dare metrics compare
+      - uses: actions/upload-artifact@v4
+        with:
+          name: dare-metrics
+          path: tmp/dare_metrics*.json
+```
+
+## Antipatterns
+
+| AP | Antipattern | Por quê |
+|---|---|---|
+| AP-01 | Métricas sem baseline | Não detecta regressão |
+| AP-02 | Histórico não versionado | Perde contexto |
+| AP-03 | Coletar mas não bloquear | CI vira teatro |
+| AP-04 | Baseline desatualizado | Regressão real fica invisível |
+
+## Boas práticas
+
+1. **Baseline por release**, não por commit
+2. **Regressão = bloqueio**, não comentário ignorável
+3. **Exportar para Datadog/Grafana** após N coletas
+4. **Collectors paralelos** — skill deve rodar em < 60s
+
+## Saída esperada
+
+Reporte markdown com:
+- Tabela por skill com M-01 a M-04
+- Comparação contra baseline (delta por métrica)
+- Status final: PASS / WARNING / CRITICAL
+- Link para snapshot completo em `tmp/dare_metrics.json`
+
+$ARGUMENTS
+
+---
+
+Skill MIT — parte do DARE Method.

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

@@ -0,0 +1,159 @@
+# /dare-realtime
+
+Comunicação real-time (WebSocket, SSE) DARE-compliant — eventos tipados, subscriptions autorizadas, reconexão com backoff, zero ghost listeners.
+
+## Como usar
+
+```
+/dare-realtime                    # audita uso de WS/SSE no projeto
+/dare-realtime scaffold ws        # gera event registry + subscription manager + reconnect
+/dare-realtime audit ghosts       # detecta listeners sem cleanup
+```
+
+## Os 4 pilares
+
+### 1. Schema validation de eventos
+
+Todo evento WS/SSE tem schema JSON. Server valida antes de emitir, client valida antes de processar.
+
+### 2. Registro central de tipos
+
+Um único `event_registry.ts` lista todos os event types com versão (`.v1`, `.v2`).
+
+### 3. Reconexão com exponential backoff
+
+```typescript
+class ReconnectStrategy {
+  private attempt = 0;
+  next(): number {
+    const base = Math.min(1000 * 2 ** this.attempt, 30_000);
+    return base + Math.random() * 1000; // jitter
+  }
+  reset() { this.attempt = 0; }
+}
+```
+
+### 4. Subscription manager (zero ghost listeners)
+
+Map de subscriptions com cleanup automático on disconnect.
+
+## Métricas obrigatórias
+
+| ID | Métrica |
+|---|---|
+| M-01 | 100% de event types com JSON Schema |
+| M-02 | 100% de subscriptions autorizadas |
+| M-03 | 0 ghost listeners após desconexão |
+| M-04 | Estratégia de reconexão configurada |
+
+## Antipatterns
+
+| AP | Antipattern | Correção |
+|---|---|---|
+| AP-01 | Evento sem schema | Adicionar no registry |
+| AP-02 | `socket.on()` sem cleanup | SubscriptionManager |
+| AP-03 | Reconexão sem backoff | Exponential + jitter |
+| AP-04 | Sem autorização de subscription | `authorize()` antes de `subscribe()` |
+| AP-05 | Broadcast sem filtro | Rooms por tenant |
+| AP-06 | Estado stale após reconectar | Resync via REST/snapshot |
+
+## O que fazer
+
+### Passo 1: Event Registry
+
+```typescript
+export const EventRegistry = {
+  'user.created.v1': { schema: UserCreatedSchema, requires: 'admin' },
+  'message.sent.v1': { schema: MessageSentSchema, requires: 'participant' },
+};
+```
+
+### Passo 2: Subscription Manager
+
+```typescript
+class SubscriptionManager {
+  private subs = new Map<string, Set<string>>();
+
+  subscribe(connId: string, event: string) {
+    if (!this.subs.has(connId)) this.subs.set(connId, new Set());
+    this.subs.get(connId)!.add(event);
+  }
+
+  onDisconnect(connId: string) {
+    this.subs.delete(connId); // cleanup SEMPRE
+  }
+}
+```
+
+### Passo 3: Reconnect com backoff
+
+```typescript
+const strategy = new ReconnectStrategy();
+socket.on('disconnect', () => {
+  setTimeout(() => socket.connect(), strategy.next());
+});
+socket.on('connect', () => {
+  strategy.reset();
+  resyncState(); // buscar eventos perdidos via REST
+});
+```
+
+### Passo 4: Autorização por subscription
+
+```typescript
+socket.on('subscribe', (eventType) => {
+  if (!authorize(socket.user, eventType)) {
+    return socket.emit('error', { code: 'FORBIDDEN' });
+  }
+  subscriptionManager.subscribe(socket.id, eventType);
+});
+```
+
+### Passo 5: Validação no server e client
+
+```typescript
+// Server antes de emitir
+const valid = EventRegistry[eventType].schema.safeParse(payload);
+if (!valid.success) return log.error('invalid event', valid.error);
+io.to(room).emit(eventType, valid.data);
+
+// Client antes de processar
+socket.on(eventType, (payload) => {
+  const valid = EventRegistry[eventType].schema.safeParse(payload);
+  if (!valid.success) return log.warn('invalid event received');
+  handleEvent(valid.data);
+});
+```
+
+## Stack recomendada
+
+| Stack | WebSocket | SSE |
+|---|---|---|
+| Node | `socket.io`, `ws` | `eventsource` + endpoint custom |
+| Rails | Action Cable | Rack streaming |
+| Rust/Axum | `tokio-tungstenite` | `axum::sse::Sse` |
+| FastAPI | `fastapi.WebSocket` | `EventSourceResponse` |
+| Go | `gorilla/websocket` | stdlib `http.Flusher` |
+
+## Boas práticas
+
+1. **SSE para server→client unidirecional** (logs, métricas)
+2. **WS para bidirectional** (chat, colaboração)
+3. **Rooms/channels por tenant** — evita cross-tenant
+4. **Heartbeat ping-pong** — detectar conexão zumbi
+5. **Backpressure** — drop eventos antigos se client lento
+6. **Replay limitado** — últimos N eventos por room para reconexão recente
+
+## Saída esperada
+
+Reporte:
+- Lista de event types e seus schemas (ou falta de)
+- Subscriptions sem autorização
+- Listeners sem cleanup (grep `socket.on` sem `removeListener` ou cleanup)
+- Stack escolhida e configuração de reconnect
+
+$ARGUMENTS
+
+---
+
+Skill MIT — parte do DARE Method.

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

@@ -0,0 +1,145 @@
+# Comando: /dare-refine
+
+## Descrição
+
+Analisa a complexidade de uma task e, quando alta, **quebra em sub-tasks menores** com escopo bem delimitado. Pode ser chamada:
+
+- Automaticamente pela skill `dare-tasks` logo após gerar o DAG (para cada task ≥ MED)
+- Manualmente pelo dev: `/dare-refine task-034`
+- Após mudança de escopo: quando o BLUEPRINT mudou e uma task ficou grande demais
+
+A camada determinística (heurística de complexidade) já é feita pelo CLI: `dare refine <id>`. Este comando adiciona a camada **semântica** — você lê a spec, decide se a quebra é necessária e, se for, produz sub-tasks coerentes.
+
+## Quando rodar
+
+- Logo após `/dare-tasks` para cada task com complexity HIGH no `dare-dag.yaml`
+- Quando o dev pede explicitamente: `/dare-refine task-034`
+- Quando você gerou uma task e ela "te parece grande" mesmo marcada MED — confie no instinto
+
+## Como executar
+
+### 1. Validar argumento
+
+`$ARGUMENTS` deve ter o `task-id`. Se vazio, peça.
+
+### 2. Rodar a camada determinística
+
+```bash
+dare refine $ARGUMENTS --split --format json > .dare/refine-$ARGUMENTS.json
+```
+
+Esse JSON traz:
+- `report.score` e `report.level` (LOW/MED/HIGH/CRITICAL)
+- `report.signals` — explica por que pontuou alto/baixo
+- `report.recommendsSplit` — true se HIGH ou CRITICAL
+- `proposal.subtasks` — quebra inicial baseada em diretórios (chute coarse)
+
+### 3. Decidir se vale quebrar
+
+Critérios para **quebrar**:
+
+- ✅ `recommendsSplit: true` da heurística (HIGH/CRITICAL)
+- ✅ Mais de 6 arquivos a criar/modificar
+- ✅ Mistura responsabilidades fortes (ex.: cria modelo + escreve controller + escreve teste + faz migration — split por camada)
+- ✅ Toca código que outra task ainda não criou (deveria ser depois)
+- ✅ Inclui refactor + feature nova juntos
+- ✅ Tem keyword "pesada" (refactor, migrate, integrate) E score MED+
+
+Critérios para **manter inteira**:
+
+- ✅ Score LOW e até MED
+- ✅ Todos os arquivos pertencem ao mesmo módulo/feature
+- ✅ Cabe em uma conversa única do agente (15–60 min de trabalho efetivo)
+
+### 4. Se decidir quebrar — produzir sub-tasks coerentes
+
+Não use a `proposal.subtasks` da CLI sem revisão — ela agrupa por diretório, o que nem sempre faz sentido semantico. **Reagrupe por responsabilidade**:
+
+| Eixo de split | Quando aplicar |
+|---|---|
+| **Por camada** | Modelo / Controller / Service / Test ficam em tasks separadas se cada um é grande |
+| **Por endpoint** | Task original tinha 4 endpoints REST → 4 sub-tasks de 1 endpoint cada |
+| **Por feature** | Auth tinha "register + login + refresh + logout" → split por verbo |
+| **Refactor + feature** | Quebra em "1. refactor X para preparar terreno" + "2. adiciona feature Y em cima" |
+| **Migration + código** | "1. migration + seeds" + "2. código que usa o novo schema" |
+
+Cada sub-task deve:
+
+- Ter `subtask_prompt` auto-suficiente (assinaturas exatas, validações, edge cases — o Anti-Stub Contract aplica)
+- Ter spec_file própria em `DARE/EXECUTION/<sub-id>.md`
+- Ter `depends_on` mínimo mas correto (sub-tasks da mesma família geralmente dependem em ordem)
+- Ter complexity honesta — se a sub ainda ficar HIGH, quebra de novo
+
+### 5. Emitir verdito + plano
+
+Salve em `.dare/refine-verdict-$ARGUMENTS.json`:
+
+```json
+{
+  "manageable": false,
+  "reasons": [
+    "Score 18 (HIGH) — 7 endpoints + migration + 12 testes no mesmo escopo",
+    "Mistura refactor de service layer com novos endpoints"
+  ],
+  "proposedSubtasks": [
+    {
+      "id": "task-034a",
+      "title": "Refactor UserService para suportar profile_settings",
+      "files": ["src/services/UserService.ts", "tests/services/UserService.test.ts"],
+      "rationale": "Refactor isolado antes da feature — gates passam sem mexer em controllers",
+      "estimatedLevel": "MED"
+    },
+    {
+      "id": "task-034b",
+      "title": "Endpoints GET/PATCH /users/me/profile",
+      "files": ["src/controllers/profile.ts", "tests/controllers/profile.test.ts"],
+      "rationale": "Endpoints novos consumindo o serviço refatorado",
+      "estimatedLevel": "MED"
+    }
+  ]
+}
+```
+
+Se a task **é** manuseável (não precisa quebrar):
+
+```json
+{
+  "manageable": true,
+  "reasons": ["Score 7 (MED), 4 arquivos no mesmo módulo, 6 testes — cabe em uma conversa"]
+}
+```
+
+### 6. Aplicar o split
+
+Se quebrou:
+
+1. **Edite** `DARE/dare-dag.yaml` substituindo a task original pelas sub-tasks
+2. **Crie** as specs novas em `DARE/EXECUTION/<sub-id>.md` (use `templates/TASK-SPEC-template.md` — seguindo o Anti-Stub Contract!)
+3. **Atualize** `DARE/TASKS.md` (visão humana) refletindo a quebra
+4. **Regenere** o Mermaid: `dare dag viz -o DARE/dag-graph.mmd`
+5. **Marque** a task original como SPLIT (não deletar — preservar histórico) ou remover e referenciar no header das sub-tasks
+
+### 7. Mensagem ao usuário
+
+Se manteve inteira:
+> ✅ Task `$ARGUMENTS` está bem-dimensionada (score X, level Y). Sem split necessário.
+
+Se quebrou:
+> 🪓 Task `$ARGUMENTS` quebrada em N sub-task(s):
+> - `<id>a`: <título>
+> - `<id>b`: <título>
+> ...
+>
+> Specs criadas em `DARE/EXECUTION/`. Revise antes de executar:
+> ```bash
+> dare validate                    # verifica DAG
+> dare dag viz                     # confirma grafo
+> dare execute --next              # roda a primeira sub-task pronta
+> ```
+
+## Regras inegociáveis
+
+- **Não quebre tasks LOW** — overhead não vale a pena
+- **Não invente dependências** — sub-tasks da mesma família frequentemente são sequenciais, não falsamente paralelas
+- **Cada sub-task precisa ser independentemente testável** — se você precisa rodar A para testar B, A precisa ser parent de B no DAG
+- **Anti-Stub Contract aplica em cada sub-task** — não relaxa critérios só porque é menor