@dewtech/dare-cli 2.16.0 → 3.0.0

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

@@ -0,0 +1,114 @@
+---
+name: dare-refine
+description: Analisa complexidade de uma task DARE e, quando alta, quebra em sub-tasks menores. Use após gerar o DAG (para tasks HIGH/CRITICAL), quando o dev pedir refinamento manual, ou quando o escopo mudou e uma task ficou grande. Combina heurística determinística (CLI) com decisão semântica do agente.
+---
+
+# DARE Refine Skill
+
+Você é o refinador de tasks do método DARE. Seu papel é garantir que cada task caiba em uma conversa única do agente — sem ficar tão grande que o agente "invente" stubs/mocks pra completar.
+
+## Quando usar
+
+- Após `dare-tasks` gerar o DAG, para cada task com complexity HIGH no `dare-dag.yaml`
+- Quando o dev pede: "refine task-034"
+- Quando o BLUEPRINT mudou e uma task ficou grande demais
+
+## Camada determinística vs semântica
+
+O CLI `dare refine <id>` já mede sinais objetivos: # arquivos, # funções, # testes, # dependências, keywords pesadas. Esta skill faz a camada semântica — você lê o conteúdo da spec e decide se faz sentido quebrar.
+
+## Como executar
+
+### Passo 1: Rodar a heurística determinística
+
+```bash
+dare refine <task-id> --split --format json > .dare/refine-<task-id>.json
+```
+
+JSON traz:
+- `report.score`, `report.level`
+- `report.signals` — explica a pontuação
+- `report.recommendsSplit` — true se HIGH/CRITICAL
+- `proposal.subtasks` — quebra inicial coarse
+
+### Passo 2: Decidir se quebra
+
+**Quebrar quando:**
+- `recommendsSplit: true` (HIGH/CRITICAL)
+- Mais de 6 arquivos
+- Mistura responsabilidades (modelo + controller + teste + migration)
+- Inclui refactor + feature juntos
+- Keyword "pesada" + score MED+
+
+**Manter inteira quando:**
+- LOW ou MED baixo
+- Mesmo módulo
+- Cabe em uma conversa (15–60 min)
+
+### Passo 3: Eixos de split
+
+| Eixo | Quando |
+|---|---|
+| **Por camada** | Modelo / Controller / Service / Test separados |
+| **Por endpoint** | 4 endpoints → 4 sub-tasks |
+| **Por feature** | Auth = register + login → split por verbo |
+| **Refactor + feature** | "1. refactor" + "2. feature em cima" |
+| **Migration + código** | "1. migration" + "2. código novo" |
+
+Cada sub-task:
+- `subtask_prompt` auto-suficiente (Anti-Stub Contract!)
+- Spec própria em `DARE/EXECUTION/<sub-id>.md`
+- `depends_on` mínimo mas correto
+- Complexity honesta — se sub ainda for HIGH, quebrar de novo
+
+### Passo 4: Verdito
+
+`.dare/refine-verdict-<task-id>.json`:
+
+```json
+{
+  "manageable": false,
+  "reasons": ["Score 18 (HIGH) — 7 endpoints + migration", "Mistura refactor com features novas"],
+  "proposedSubtasks": [
+    {
+      "id": "task-034a",
+      "title": "Refactor UserService",
+      "files": ["src/services/UserService.ts", "tests/services/UserService.test.ts"],
+      "rationale": "Refactor isolado antes da feature",
+      "estimatedLevel": "MED"
+    }
+  ]
+}
+```
+
+Manuseável:
+
+```json
+{
+  "manageable": true,
+  "reasons": ["Score 7 (MED), 4 arquivos mesmo módulo"]
+}
+```
+
+### Passo 5: Aplicar o split
+
+1. Editar `DARE/dare-dag.yaml` substituindo a task pelas sub-tasks
+2. Criar specs em `DARE/EXECUTION/<sub-id>.md` (template + Anti-Stub Contract)
+3. Atualizar `DARE/TASKS.md` (visão humana)
+4. Regenerar Mermaid: `dare dag viz -o DARE/dag-graph.mmd`
+5. Marcar task original como SPLIT (preservar histórico)
+
+### Passo 6: Mensagem
+
+Manuseável:
+> ✅ Task bem-dimensionada (score X, level Y). Sem split.
+
+Quebrada:
+> 🪓 Task quebrada em N sub-tasks: [lista]. Revise com `dare validate` e `dare dag viz`.
+
+## Regras inegociáveis
+
+- Não quebrar tasks LOW
+- Não inventar dependências falsas
+- Cada sub-task testável independentemente
+- Anti-Stub Contract aplica em cada sub-task

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

@@ -0,0 +1,108 @@
+---
+name: dare-reverse
+description: Camada semântica da engenharia reversa (Fase 0 / brownfield). Roda depois do comando `dare reverse` e preenche as inferências — propósito, domínio, responsabilidades e diagramas de fluxo — nos artefatos DARE/IDEIA.md e DARE/REVERSE/module-*.md.
+---
+
+# DARE Reverse Skill — Engenharia Reversa (Fase 0)
+
+Você é o agente da **Fase 0 (brownfield)** do método DARE no Antigravity. Esta skill é a
+**camada semântica** da engenharia reversa: roda **depois** do comando `dare reverse`, que já
+varreu o código e gerou os esqueletos determinísticos. Sua função é **preencher as inferências**
+que o CLI não faz: propósito, domínio, responsabilidades e os **diagramas de fluxo**
+("como a coisa funciona").
+
+> Pré-requisito: o comando `dare reverse` precisa ter rodado antes (gera `DARE/IDEIA.md`,
+> `DARE/REVERSE/module-*.md` e `DARE/REVERSE/reverse-facts.json`). Se não existirem, peça ao
+> usuário para rodar `dare reverse` primeiro.
+
+## Quando usar esta skill
+
+- O usuário quer entender / documentar um projeto **legado** antes de adotar o DARE.
+- Acabou de rodar `dare reverse` e os artefatos têm seções `<!-- AGENT: ... -->` em aberto.
+- O objetivo é gerar uma **pré-arquitetura** (`IDEIA.md`) que depois vira `DESIGN.md`.
+
+## Marcação de confiança (obrigatória)
+
+Ao preencher cada `<!-- AGENT -->`, marque **cada afirmação** com seu nível de confiança + evidência:
+
+- `- 🟢 <claim>. ` + `` `arquivo:linha` `` — **CONFIRMED**: evidência direta no código.
+- `- 🟡 <claim>. ` + `` `arquivo:linha` `` — **INFERRED**: padrão/dedução; pode estar errado.
+- `- 🔴 <claim>. → ver gaps.md` — **GAP**: não determinável pelo código.
+
+Regra: só 🟢 com evidência direta; na dúvida, 🟡; sem base, 🔴 (registre em `gaps.md`). Os fatos
+estruturais (caminho, LOC, deps) já vêm pré-marcados 🟢 pelo CLI — **não os altere**.
+
+## Passo a passo
+
+### 1. Carregar os fatos (não re-varrer tudo)
+
+- Leia `DARE/REVERSE/reverse-facts.json` — fonte de fatos determinística (stack, módulos, LOC,
+  grafo de dependências). **Confie nela** para o inventário; não reconte arquivos.
+- Por módulo, abra **2-5 arquivos representativos** (entrypoints, controllers, services, models)
+  — o suficiente para inferir responsabilidade e fluxo. Não leia o módulo inteiro.
+
+### 2. Preencher `DARE/IDEIA.md`
+
+Substitua cada bloco `<!-- AGENT: ... -->`:
+
+- **Propósito Inferido** — 2-4 frases: o que o software faz e por quê.
+- **Domínio & Conceitos** — entidades de negócio + glossário.
+- **Modelo de Dados (reconstruído)** — entidades, campos-chave, relacionamentos.
+- **Superfície de API** — endpoints inferidos de rotas/controllers.
+- **Fluxo do Sistema** — um `flowchart TD` Mermaid do caminho principal de request/dados
+  atravessando os módulos.
+- **⚠️ Incertezas / Gaps** — o que NÃO deu pra inferir + perguntas objetivas para o humano.
+
+**Não toque** no Mapa de Módulos nem na tabela (determinísticos, gerados pelo CLI).
+
+### 3. Preencher cada `DARE/REVERSE/module-*.md`
+
+- **Responsabilidade** — papel do módulo no sistema (1-3 frases).
+- **Superfície Pública** — o que expõe (funções/classes/endpoints/tipos exportados).
+- **Como Funciona (fluxo)** — um `sequenceDiagram` Mermaid do fluxo típico
+  (entrypoint → service → repository → DB/externo).
+- **Dependências & Acoplamento** — comente o acoplamento e riscos (circular, hotspot HIGH).
+
+### 4. Apresentar ao usuário
+
+Resumo: propósito inferido, nº de módulos, principais incertezas. Reforce que o `IDEIA.md` é um
+**rascunho a validar** antes de promover a DESIGN com `dare design`.
+
+## Passo final — Gaps, Questions e Reviewer
+
+1. **`gaps.md`** — consolide os 🔴 classificados por severidade (crítico/moderado/cosmético/fora-escopo) + tratamento.
+2. **`questions.md`** — perguntas objetivas ao humano.
+3. **Reviewer** — releia os arquivos-chave e rebaixe claims sem evidência (🟢→🟡 ou 🟡→🔴).
+4. **Rode `dare reverse --report`** — gera `confidence-report.md` + `traceability/code-spec-matrix.md` (índice determinístico).
+
+## Modo `--deep` (Fase 3)
+
+Se `dare reverse --deep` foi usado, complete os artefatos extras em `DARE/REVERSE/`:
+- **`erd.md`** — entidades extraídas pelo CLI (🟢); complete relações não-explícitas (🟡).
+- **`domain-rules.md`** — regras de negócio (validações, invariantes, cálculos), 🟢/🟡/🔴.
+- **`state-machines.md`** — `stateDiagram-v2` por entidade/fluxo (estados/transições reais).
+- **`permissions.md`** — papéis, recursos e regras de autorização.
+- **`c4/c4-context.md`** e **`c4/c4-container.md`** — atores/externos e containers (component = mapa de módulos).
+
+## Regras de ouro
+
+1. **Não invente** — fluxo não-claro vira 🔴 (gap), não chute.
+2. **Fidelidade ao código real** — descreva o que o código faz, não o que deveria fazer.
+3. **Diagramas enxutos** — legibilidade acima de exaustividade.
+4. **Não re-varra** — os fatos já estão em `reverse-facts.json`.
+5. **Preserve o determinístico** — nunca edite o Mapa de Módulos/tabela/grafo do CLI.
+
+## Antipatterns
+
+| AP | Antipattern | Por quê |
+|---|---|---|
+| AP-01 | Inventar endpoints/entidades inexistentes | Polui a pré-arquitetura com ficção |
+| AP-02 | Reescrever a tabela de módulos do CLI | Quebra a fonte determinística |
+| AP-03 | `sequenceDiagram` gigante e ilegível | Anula o propósito do diagrama |
+| AP-04 | Pular a seção de Incertezas | Remove o ponto de validação humana |
+| AP-05 | Ler o projeto inteiro arquivo a arquivo | Desperdiça contexto; os fatos já estão no JSON |
+| AP-06 | Marcar tudo 🟢 sem evidência `file:line` | Infla a confiança e engana o humano |
+
+---
+
+Skill MIT — parte do DARE Method. Fase 0 (brownfield). Pareia com o comando `dare reverse`.

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

@@ -0,0 +1,111 @@
+---
+name: dare-review
+description: Audita uma task DARE implementada — cruza a spec com o código real para detectar stubs, mocks fora de testes, funções vazias, TODOs e validar critério-a-critério se a implementação satisfaz o que a spec prometeu. Use antes de marcar uma task como DONE, ou quando o dev pedir revisão manual. Combina análise estática (via CLI) com verdito semântico (você).
+---
+
+# DARE Review Skill
+
+Você é o auditor de qualidade do método DARE. Seu papel é verificar se uma task implementada **realmente** entrega o que a spec promete — sem stubs, sem mocks em produção, sem funções vazias, sem TODOs pendentes.
+
+## Quando usar esta skill
+
+- Antes de marcar uma task como DONE (gate obrigatório no Definition of Done)
+- Quando `dare review <id>` estático passa mas precisa validação semântica
+- Quando o dev pede revisão manual: "revise a task-034"
+
+## Camada estática vs semântica
+
+O CLI `dare review <id>` já faz a camada **estática**: regex sobre os arquivos detecta TODO/FIXME/stubs/mocks/funções vazias. Esta skill faz a camada **semântica**: critério-a-critério da spec contra a implementação real.
+
+## Como executar
+
+### Passo 1: Rodar a camada estática
+
+```bash
+dare review <task-id> --format json > .dare/review-static-<task-id>.json
+```
+
+Leia o JSON. Se houver erros estáticos, reporte-os primeiro. Geralmente não vale prosseguir com semântica se a estática falhou.
+
+### Passo 2: Carregar contexto
+
+- `DARE/EXECUTION/<task-id>.md` — spec da task
+- Cada arquivo listado na seção 3 ("ARQUIVOS A CRIAR / MODIFICAR")
+- `DARE/BLUEPRINT.md` — contratos de API / modelos
+
+### Passo 3: Auditoria critério-a-critério
+
+Para **cada** item das seções abaixo, marque ✅ / ❌ com evidência (arquivo + linha):
+
+#### 3.1 Objetivo (seção 1 da spec)
+A implementação atinge o estado observável prometido? Encontre evidência concreta.
+
+#### 3.2 Arquivos (seção 3)
+- Todos existem com conteúdo descrito?
+- Arquivos extras suspeitos?
+
+#### 3.3 Implementação (seção 4)
+- Cada passo numerado foi executado?
+- Assinaturas exatas correspondem?
+- Validações têm regras concretas (não "valida email" — a regex específica)?
+
+#### 3.4 Testes (seção 4 — subitem testes)
+- Cada teste listado existe?
+- Tem assertions reais (não `assertTrue(true)`)?
+- Edge cases enumerados cobertos?
+
+#### 3.5 Segurança (seção 5)
+- Input validation conforme spec?
+- Não há secrets/tokens hardcoded?
+- SQL/Command injection mitigado?
+
+#### 3.6 Anti-Stub (seção 7)
+A camada estática já checou. Só anote se encontrar algo que regex não pegaria (ex.: dados hardcoded disfarçados).
+
+### Passo 4: Emitir verdito semântico
+
+Salve em `.dare/review-semantic-<task-id>.json`:
+
+```json
+{
+  "passed": true,
+  "unmetCriteria": [],
+  "notes": "Resumo de 1-3 frases"
+}
+```
+
+Falha:
+
+```json
+{
+  "passed": false,
+  "unmetCriteria": [
+    "Seção 4.3: validação de senha sem regex de força",
+    "Seção 4.4: teste de 'email duplicado' não existe"
+  ],
+  "notes": "2 critérios não atendidos em src/auth/register.ts"
+}
+```
+
+### Passo 5: Rodar o review fundido
+
+```bash
+dare review <task-id> --from-agent .dare/review-semantic-<task-id>.json
+```
+
+Exit code 0 = pode ir para DONE; 1 = não pode.
+
+### Passo 6: Mensagem final
+
+Se passou:
+> ✅ Task aprovada. Marque DONE: `dare execute --complete <task-id>`
+
+Se falhou:
+> ❌ Task não passou. Itens a corrigir: [lista]. Re-rode após corrigir.
+
+## Regras inegociáveis
+
+- **Não invente** que algo está implementado se não viu o código no disco
+- **Não aceite** mocks/stubs em código de produção mesmo que façam testes passar
+- **Mocks são OK** dentro de `*.test.*`, `*.spec.*`, `__tests__/`, `tests/`, `spec/`
+- **Evidência concreta:** sempre cite arquivo + linha para suas conclusões

package/templates/ide/antigravity/.agents/skills/dare-rust-leptos/SKILL.md

@@ -0,0 +1,263 @@
+---
+name: dare-rust-leptos
+description: Guia DARE para desenvolvimento Leptos (Rust + WASM) — decisão CSR vs Fullstack, idioms 0.7, antipatterns, tipos compartilhados server+WASM com cfg_attr, workspace misto WASM+nativo, templates de tasks.
+---
+
+# DARE Rust/Leptos Skill
+
+Você é um especialista em Leptos 0.7+ (framework reativo Rust → WASM). Seu papel é orientar a decisão de variante (CSR vs Fullstack), aplicar idioms obrigatórios, evitar antipatterns clássicos e estruturar tipos compartilhados entre server e WASM.
+
+## Quando usar
+
+- Projeto novo Leptos sendo iniciado
+- Decisão CSR vs Fullstack precisa ser tomada
+- Workspace misto (Leptos + Axum + napi-rs) com problemas de target
+- Tipos compartilhados quebrando entre server e WASM
+- Effect/Resource/Action sendo mal usados
+
+## 1. Decisão de variante: CSR vs Fullstack
+
+| Critério | CSR (trunk) | Fullstack (cargo-leptos) |
+|---|---|---|
+| SEO necessário | ❌ | ✅ |
+| Time-to-interactive crítico | ❌ | ✅ |
+| Dashboard interno / admin | ✅ | ✅ |
+| Backend Axum existente | indiferente | ✅ integração direta |
+| Simplicidade de deploy | ✅ arquivos estáticos | ⚠️ binário Axum |
+| Server functions (`#[server]`) | ❌ não existe | ✅ |
+
+**Regra de ouro:**
+- Atrás de login e SEO não importa → **CSR**
+- Precisa SEO, carregamento inicial rápido, ou server functions → **Fullstack**
+- Já tem Axum no monorepo → **Fullstack** (workspace unificado)
+
+## 2. Ferramentas — nunca misturar
+
+| Variante | Build | Dev server | Test |
+|---|---|---|---|
+| CSR | `trunk build --release` | `trunk serve` | `cargo test --workspace` |
+| Fullstack | `cargo leptos build --release` | `cargo leptos watch` | `cargo test --workspace` |
+
+> `cargo leptos test` **não existe**. Use `cargo test --workspace`.
+> Não use `trunk` para fullstack nem `cargo leptos` para CSR.
+
+## 3. Idioms obrigatórios Leptos 0.7
+
+### Estado reativo
+
+```rust
+// Signals — só re-renderiza o que usa
+let (count, set_count) = signal(0);
+let doubled = move || count.get() * 2;  // derived (memo inline)
+
+// Para estado compartilhado:
+let count = RwSignal::new(0);
+```
+
+### Dados assíncronos
+
+```rust
+// ✅ Resource — declarativo, integra com Suspense
+let user = Resource::new(|| user_id(), |id| async move { fetch_user(id).await });
+
+view! {
+    <Suspense fallback=|| view! { <p>"Loading..."</p> }>
+        {move || user.get().map(|u| view! { <p>{u.name}</p> })}
+    </Suspense>
+}
+
+// ❌ Effect que faz fetch (re-executa em todo render)
+```
+
+### Mutações
+
+```rust
+// ✅ Action — submits, forms, operações
+let save = Action::new(|input: &String| {
+    let input = input.clone();
+    async move { api::save(input).await }
+});
+
+view! {
+    <button on:click=move |_| save.dispatch("hello".to_string())>"Save"</button>
+    <Show when=move || save.pending().get()><p>"Saving..."</p></Show>
+}
+```
+
+### Listas e condicionais
+
+```rust
+view! {
+    <Show when=move || logged_in.get() fallback=|| view! { <Login/> }>
+        <Dashboard/>
+    </Show>
+
+    <For
+        each=move || items.get()
+        key=|item| item.id
+        children=move |item| view! { <ItemRow item=item/> }
+    />
+}
+```
+
+### Server functions (fullstack only)
+
+```rust
+#[server(SaveUser, "/api")]
+pub async fn save_user(name: String) -> Result<User, ServerFnError> {
+    // Só roda no server (feature = "ssr")
+    db::create_user(name).await.map_err(Into::into)
+}
+
+// No componente
+let save = ServerAction::<SaveUser>::new();
+```
+
+## 4. Tipos compartilhados server + WASM
+
+```rust
+// crates/<projeto>-domain/src/lib.rs
+use serde::{Deserialize, Serialize};
+
+#[cfg_attr(feature = "ssr", derive(sqlx::FromRow))]  // só no server
+#[derive(Clone, Debug, Serialize, Deserialize)]      // server + WASM
+pub struct SecurityEvent {
+    pub id: uuid::Uuid,
+    pub attack_type: String,
+    pub risk_score: f32,
+    pub blocked: bool,
+}
+```
+
+`Cargo.toml`:
+
+```toml
+[dependencies]
+serde = { version = "1.0", features = ["derive"] }
+uuid = { version = "1.10", features = ["v4", "serde"] }
+
+[dependencies.sqlx]
+version = "0.8"
+features = ["postgres", "runtime-tokio", "uuid"]
+optional = true
+
+[features]
+ssr = ["dep:sqlx"]
+```
+
+## 5. Workspace misto (WASM + nativo)
+
+```toml
+# Cargo.toml do workspace
+[workspace]
+resolver = "2"
+members = [
+  "crates/<p>-core",       # lib nativa (x86)
+  "crates/<p>-server",     # bin nativo — Axum
+  "crates/<p>-web",        # bin+lib WASM — Leptos
+  "crates/<p>-cli",        # bin nativo
+]
+```
+
+```toml
+# crates/<p>-web/Cargo.toml — features separam server de WASM
+[features]
+default = []
+hydrate = ["leptos/hydrate"]
+ssr = ["dep:axum", "dep:leptos_axum", "dep:tokio", "leptos/ssr"]
+```
+
+> **Antipattern crítico:** `[build] target = "wasm32-unknown-unknown"` no `.cargo/config.toml` raiz quebra todos os crates nativos. `cargo leptos` gerencia o target WASM internamente — não interfira.
+
+## 6. Antipatterns
+
+| Antipattern | Por quê | Alternativa |
+|---|---|---|
+| `wasm_bindgen` direto | Bypassa abstrações Leptos, frágil | APIs do Leptos (`web_sys` via feature) |
+| `panic!` em componentes | Derruba o app sem `ErrorBoundary` | `Result<_, ServerFnError>` + `ErrorBoundary` |
+| `Effect` que faz fetch | Re-executa a cada render | `Resource::new()` |
+| `tokio::spawn` no client | `tokio` não existe no WASM | `spawn_local()` ou server function |
+| `std::thread` no client | Não existe no WASM | Signals para paralelismo reativo |
+| `cargo leptos test` | Comando inválido | `cargo test --workspace` |
+| `[build] target` global | Quebra crates nativos | Sem target global; cargo-leptos gerencia |
+
+## 7. Templates de tasks DARE
+
+Cole no `DARE/dare-dag.yaml` após blueprint:
+
+```yaml
+- id: leptos-001
+  title: "Workspace, AppShell e Router base"
+  description: |
+    Cargo workspace com resolver = "2".
+    App component com leptos_router::Router.
+    Layout base (header, main, footer). Rota "/" → HomePage.
+    Ralph Loop: cargo leptos build --release + cargo test --workspace + cargo clippy
+  depends_on: []
+
+- id: leptos-002
+  title: "Form com Action + server function"
+  description: |
+    #[server] fn para processar o form.
+    ActionForm ou Action manual.
+    Validar input no server (ServerFnError em erro).
+    Pending state com Action::pending().
+  depends_on: [leptos-001]
+
+- id: leptos-003
+  title: "Lista paginada com Resource + Suspense"
+  description: |
+    Resource recebendo página como signal.
+    Envolver em Suspense com fallback loading.
+    ErrorBoundary para erros de fetch.
+    Paginação com For + key por ID.
+  depends_on: [leptos-001]
+```
+
+## 8. Stack canônica
+
+| Camada | Cliente (WASM) | Server (Fullstack) |
+|---|---|---|
+| Framework | Leptos 0.7+ | Leptos 0.7 + leptos_axum |
+| Roteamento | leptos_router | (compartilhado) |
+| Estado server | Resource + Server Functions | sqlx + Axum |
+| Estilo | Tailwind | — |
+| Build | cargo-leptos / trunk | cargo-leptos |
+
+## Como aplicar
+
+### Passo 1: Decidir variante
+
+Use a tabela em §1. Documente decisão no DESIGN.md.
+
+### Passo 2: Setup workspace
+
+Aplique `dare-rust-workspace` para layout multi-crate. `<p>-domain` em separado para tipos compartilhados.
+
+### Passo 3: Implementar componentes seguindo idioms §3
+
+Resource para fetch, Action para mutação, Show/For para condicional/lista.
+
+### Passo 4: Server functions (fullstack)
+
+`#[server]` para qualquer comunicação client→server. Validação no server, ServerFnError em erro.
+
+### Passo 5: Ralph Loop validation
+
+```bash
+cargo leptos build --release        # fullstack
+# ou
+trunk build --release               # CSR
+cargo test --workspace
+cargo clippy --workspace --all-targets -- -D warnings
+```
+
+## Dicas
+
+- **Combine** com `dare-rust-workspace` para decisão de layout
+- **Para SSR**, use `leptos_axum` (não axum direto)
+- **Hidratação** — sempre `view!` em ambos lados, server gera HTML inicial
+
+---
+
+Esta skill é parte do DARE Method e está sob licença MIT.