@dewtech/dare-cli 2.7.0 → 2.10.0

package/templates/ide/claude/.claude/commands/dare-rust-leptos.md

@@ -0,0 +1,269 @@
+# /dare-rust-leptos
+
+Guia de desenvolvimento Leptos para projetos DARE. Cobre decisão de variante, idioms obrigatórios, antipatterns, tipos compartilhados e templates de tasks.
+
+## Como usar
+
+```
+/dare-rust-leptos                    ← decide variante + configura workspace
+/dare-rust-leptos --csr              ← guia específico para CSR + trunk
+/dare-rust-leptos --fullstack        ← guia específico para SSR + cargo-leptos
+/dare-rust-leptos --shared-types     ← padrão cfg_attr para tipos server + WASM
+```
+
+---
+
+## 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 (CDN) | ⚠️ binário Axum |
+| Server functions (`#[server]`) | ❌ não existe | ✅ |
+
+**Regra de ouro:**
+- Se o projeto vive atrás de login e SEO não importa → **CSR**
+- Se precisa de SEO, carregamento inicial rápido, ou server functions → **Fullstack**
+- Se já tem `rust-axum` como backend 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 sempre `cargo test --workspace`.
+> ⚠️ Não use `trunk` para fullstack nem `cargo leptos` para CSR — ferramentas erradas para o target errado.
+
+---
+
+## 3. Idioms obrigatórios Leptos 0.7
+
+### Estado reativo
+```rust
+// ✅ Fine-grained signals — só re-renderiza o que usa o signal
+let (count, set_count) = signal(0);
+let doubled = move || count.get() * 2;  // derived (memo inline)
+
+// Para estado complexo ou compartilhado entre componentes:
+let count = RwSignal::new(0);  // read + write em um só
+```
+
+### Dados assíncronos
+```rust
+// ✅ Resource — fetch declarativo, integra com Suspense
+let user = Resource::new(|| user_id(), |id| async move { fetch_user(id).await });
+
+// ✅ Suspense — loading state automático
+view! {
+    <Suspense fallback=|| view! { <p>"Loading..."</p> }>
+        {move || user.get().map(|u| view! { <p>{u.name}</p> })}
+    </Suspense>
+}
+
+// ❌ Nunca — Effect que faz fetch (re-executa em todo render)
+Effect::new(move |_| { spawn_local(async { fetch_user(id).await }); });
+```
+
+### Mutações
+```rust
+// ✅ Action — para submits, forms, operações que mudam estado
+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>
+}
+```
+
+### Renderização condicional e listas
+```rust
+// ✅ Show — condicional com lazy evaluation
+view! {
+    <Show when=move || logged_in.get() fallback=|| view! { <Login/> }>
+        <Dashboard/>
+    </Show>
+}
+
+// ✅ For — lista reativa com key para reconciliação eficiente
+view! {
+    <For
+        each=move || items.get()
+        key=|item| item.id
+        children=move |item| view! { <ItemRow item=item/> }
+    />
+}
+```
+
+### Server functions (fullstack only)
+```rust
+// ✅ #[server] macro — compila para HTTP call no client, fn real no server
+#[server(SaveUser, "/api")]
+pub async fn save_user(name: String) -> Result<User, ServerFnError> {
+    // Este código só roda no server (feature = "ssr")
+    let user = db::create_user(name).await?;
+    Ok(user)
+}
+
+// No componente — usa como Action normal
+let save = ServerAction::<SaveUser>::new();
+```
+
+---
+
+## 4. Tipos compartilhados server + WASM
+
+Tipos que precisam existir tanto no server (SQLx, Axum) quanto no client (WASM) usam `cfg_attr`:
+
+```rust
+// crates/<projeto>-domain/src/lib.rs  (ou src/models.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 do crate domain:**
+```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"]
+```
+
+> O crate domain é compilado duas vezes: uma para x86 (server, com sqlx) e uma para wasm32 (client, sem sqlx). O `cfg_attr` garante que `sqlx::FromRow` só aparece na compilação server.
+
+---
+
+## 5. Configuração workspace misto (WASM + nativo)
+
+Quando o workspace tem crates Leptos/WASM **e** crates nativos (ex: `napi-rs`, `aya`, Axum):
+
+```toml
+# .cargo/config.toml na raiz do workspace
+# NÃO definir [build] target global aqui.
+# Cada crate define seu próprio target via features e cargo-leptos/trunk.
+```
+
+```toml
+# Cargo.toml do workspace
+[workspace]
+resolver = "2"
+members = [
+  "crates/ars-core",      # lib nativa (x86)
+  "crates/ars-server",    # bin nativo — Axum
+  "crates/ars-web",       # bin+lib WASM — Leptos
+  "crates/ars-cli",       # bin nativo
+]
+# crates napi-rs ficam em workspace separado ou excluídos do members padrão
+```
+
+```toml
+# crates/ars-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**: adicionar `[build] target = "wasm32-unknown-unknown"` no `.cargo/config.toml` raiz quebra todos os crates nativos. `cargo leptos` e `trunk` gerenciam o target WASM internamente — não interfira.
+
+---
+
+## 6. Antipatterns a evitar
+
+| Antipattern | Por quê | Alternativa |
+|---|---|---|
+| `wasm_bindgen` direto | Bypassa abstrações do Leptos, código frágil | Use APIs do Leptos (`web_sys` via feature quando necessário) |
+| `panic!` em componentes | Derruba o app inteiro sem `ErrorBoundary` | `Result<_, ServerFnError>` + `ErrorBoundary` |
+| `Effect` que faz fetch | Re-executa a cada render, difícil de cancelar | `Resource::new()` |
+| `tokio::spawn` no client | `tokio` não existe no WASM | `spawn_local()` (wasm) ou só em server functions |
+| `std::thread` no client | Não existe no WASM | Leptos signals para paralelismo reativo |
+| `cargo leptos test` | Não existe — comando inválido | `cargo test --workspace` |
+| `[build] target` global | Quebra crates nativos no workspace misto | Sem target global; cargo-leptos gerencia internamente |
+
+---
+
+## 7. Templates de tasks DARE para Leptos
+
+Cole no `DARE/dare-dag.yaml` após gerar o blueprint:
+
+```yaml
+# Task 1 — Workspace + AppShell + Router
+- id: leptos-001
+  title: "Workspace, AppShell e Router base"
+  description: |
+    Configurar Cargo workspace com resolver = "2".
+    Criar App component com leptos_router::Router.
+    Criar layout base (header, main, footer).
+    Rota "/" → HomePage component.
+    Ralph Loop: cargo leptos build --release + cargo test --workspace + cargo clippy
+  depends_on: []
+
+# Task 2 — Form com Action + server function
+- id: leptos-002
+  title: "Form com Action e validação server-side"
+  description: |
+    Criar #[server] fn para processar o form.
+    Criar componente com ActionForm ou Action manual.
+    Validar input no server (retorna ServerFnError em caso de erro).
+    Exibir pending state com Action::pending() signal.
+    Ralph Loop: cargo leptos build --release + cargo test --workspace
+  depends_on: [leptos-001]
+
+# Task 3 — Lista paginada com Resource + Suspense
+- id: leptos-003
+  title: "Lista paginada com Resource, Suspense e error handling"
+  description: |
+    Criar Resource que recebe página como signal de parâmetro.
+    Envolver em Suspense com fallback de loading.
+    Usar ErrorBoundary para erros de fetch.
+    Adicionar paginação com For component e key por ID.
+    Ralph Loop: cargo leptos build --release + cargo test --workspace
+  depends_on: [leptos-001]
+```
+
+---
+
+## 8. O que fazer agora
+
+1. **Leia `DARE/DESIGN.md`** para entender quais componentes e server functions são necessários
+2. **Rode `cargo leptos watch`** (fullstack) ou **`trunk serve`** (CSR) para confirmar que o scaffold compila
+3. **Gere `DARE/BLUEPRINT.md`** com `/dare-blueprint` — inclua:
+   - Tabela de componentes (nome, props, signals usados)
+   - Lista de server functions com assinatura
+   - Tipos compartilhados no crate domain
+4. **Use `/dare-rust-workspace`** se precisar decidir estrutura multi-crate
+
+$ARGUMENTS

package/templates/ide/claude/.claude/commands/dare-rust-workspace.md

@@ -0,0 +1,209 @@
+# /dare-rust-workspace
+
+Decisão e migração de Cargo workspace multi-crate para projetos Rust/Axum.
+Cobre dois cenários:
+
+- **Cenário A — Design/Blueprint:** decidir desde o início se o projeto
+  nasce single-crate ou workspace.
+- **Cenário B — Migração:** propor plano de PRs incrementais para
+  transformar um projeto single-crate maduro em workspace.
+
+## Como usar
+
+```
+/dare-rust-workspace                # análise contextual (lê BLUEPRINT/src/)
+/dare-rust-workspace --design       # foco em decisão para projeto novo
+/dare-rust-workspace --migrate      # foco em plano de migração
+```
+
+## O que fazer
+
+### 1) Detectar o cenário
+
+- Se existe `DARE/BLUEPRINT.md` mas o `src/` ainda não existe ou tem < 5
+  arquivos → Cenário A (decisão)
+- Se `src/` tem > 30 arquivos `.rs` ou múltiplas subpastas top-level →
+  Cenário B (migração)
+- Caso intermediário (15–30 arquivos) → mostrar os critérios e perguntar
+  ao usuário
+
+### 2) Cenário A — Decisão na fase Design/Blueprint
+
+Aplique os critérios:
+
+**Comece single-crate quando TODOS forem verdadeiros:**
+- Apenas 1 binário (HTTP server)
+- < 30 arquivos `.rs` esperados
+- 1–2 sistemas externos (DB; ou DB + cache)
+- Equipe ≤ 2 devs
+- Sem deploy independente para subcomponentes
+
+**Comece workspace quando QUALQUER for verdadeiro:**
+- ≥ 2 binários previstos (API + worker; API + admin)
+- ≥ 3 sistemas externos (PG + Redis + Rabbit + Qdrant + Neo4j…)
+- Deploy independente desejado (workers em pods separados)
+- Fronteiras arquiteturais críticas (domain puro; SDK publicável)
+- Equipe ≥ 3 devs em paralelo
+
+**Layout recomendado para workspace** (use `<p>` como prefixo do projeto):
+
+```
+projeto/
+├── Cargo.toml                    # workspace root
+├── crates/
+│   ├── <p>-domain/    (lib)      # entities puras
+│   ├── <p>-config/    (lib)
+│   ├── <p>-db/        (lib)
+│   ├── <p>-cache/     (lib)
+│   ├── <p>-queue/     (lib)
+│   ├── <p>-services/  (lib)      # business logic
+│   ├── <p>-integrators/ (lib)    # clientes externos
+│   ├── <p>-api/       (bin+lib)  # HTTP server
+│   ├── <p>-worker-<X>/ (bin)     # 1 binário por worker
+│   └── <p>-e2e/       (tests)
+└── xtask/                        # scripts em Rust
+```
+
+**`Cargo.toml` raiz:**
+```toml
+[workspace]
+resolver = "2"
+members = ["crates/<p>-domain", "crates/<p>-services", "crates/<p>-api", ...]
+
+[workspace.package]
+version = "0.1.0"
+edition = "2021"
+rust-version = "1.80"
+
+[workspace.dependencies]
+tokio = { version = "1.40", features = ["full"] }
+axum = { version = "0.7", features = ["macros"] }
+sqlx = { version = "0.8", features = ["runtime-tokio", "postgres", "uuid", "chrono", "migrate"] }
+serde = { version = "1.0", features = ["derive"] }
+thiserror = "1.0"
+anyhow = "1.0"
+tracing = "0.1"
+uuid = { version = "1.10", features = ["v4", "serde"] }
+chrono = { version = "0.4", features = ["serde"] }
+
+[profile.release]
+opt-level = 3
+lto = "thin"
+codegen-units = 1
+strip = true
+```
+
+Cada crate filho usa `<dep> = { workspace = true }` para herdar versão.
+
+**Diagrama no BLUEPRINT.md (Mermaid):**
+```mermaid
+graph TD
+    api[<p>-api]
+    worker[<p>-worker-flow]
+    services[<p>-services]
+    domain[<p>-domain]
+    db[<p>-db]
+    api --> services
+    worker --> services
+    services --> db
+    services --> domain
+    db --> domain
+```
+
+Regra de seta: domain no fundo (ninguém depende para baixo), services no
+meio (depende de domain/db, nunca de api), binários no topo.
+
+### 3) Cenário B — Plano de migração em 4 PRs
+
+Migração **nunca é big-bang**. Cada PR passa build/test/clippy no fim e é
+deployável.
+
+**PR 1 — Workers** (mais isolados, menor risco):
+```
+src/workers/  →  crates/<p>-worker-<X>/
+                 ├── Cargo.toml
+                 └── src/main.rs
+```
+- Cada `tokio::spawn(worker_x)` do `main.rs` da API vira binário próprio.
+- API para de spawn workers; workers sobem como processo independente.
+- `docker-compose.yml` ganha service novo por worker.
+- Em k8s: Deployment próprio com scaling independente.
+
+**PR 2 — Integrators** (clientes externos):
+```
+src/integrators/{llm, neo4j, qdrant}.rs  →  crates/<p>-integrators/src/lib.rs
+```
+- Tudo que fala com mundo externo (LLM, Stripe, Meta, DB externo) vira lib.
+- API e workers importam via `path = "../<p>-integrators"`.
+- Crate é folha do grafo — NÃO depende de domain/services.
+
+**PR 3 — Domain** (entidades puras):
+```
+src/models/      \
+src/dto/          →  crates/<p>-domain/src/lib.rs
+src/error.rs     /
+```
+- `<p>-domain` tem deps **mínimas**: `serde`, `uuid`, `chrono`, `thiserror`.
+- Nada de axum, sqlx, redis. Build do domain falha se alguém tentar.
+- Outros crates passam a usar `<p>-domain` em vez de `crate::models::`.
+
+**PR 4 — API e workspace root:**
+```
+Cargo.toml raiz   →  [workspace] puro
+src/ (resto)      →  crates/<p>-api/src/
+```
+- `Cargo.toml` raiz só com `[workspace]` + `[workspace.package]` +
+  `[workspace.dependencies]` + `[profile.*]`.
+- API vai pra `crates/<p>-api/`.
+- Todas as deps centralizadas no root.
+
+### 4) Validação após cada PR
+
+```bash
+cargo build --workspace --all-targets
+cargo test --workspace
+cargo clippy --workspace --all-targets -- -D warnings
+```
+
+Mais smoke E2E do projeto. Se algum falhar, PR está incompleto.
+
+### 5) Tradução de imports
+
+| Antes (single-crate) | Depois (workspace) |
+|----------------------|--------------------|
+| `use crate::models::User;` | `use <p>_domain::User;` |
+| `use crate::services::auth::login;` | `use <p>_services::auth::login;` |
+| `use crate::integrators::llm::Gemini;` | `use <p>_integrators::llm::Gemini;` |
+| `use crate::handlers::health::router;` | *fica igual — mesmo crate* |
+
+Hifens (Cargo) viram underlines (Rust idents).
+
+### 6) Antipatterns para alertar o usuário
+
+| Antipattern | Por quê |
+|-------------|---------|
+| Big-bang (1 PR mexe em tudo) | Impossível revisar/reverter |
+| Crate `common`/`shared`/`utils` | Vira lixeira; viola SRP |
+| Crate por arquivo | 50 crates de 100 linhas → parar build |
+| Refactor + migração no mesmo PR | Bug fica escondido |
+| Mover testes em PR separado | Crate sem test = bug em standby |
+| Esquecer atualizar `xtask`/CI | Pipeline quebra |
+
+### 7) Quando NÃO migrar
+
+- Projeto < 30 arquivos, 1 binário, 1 dev
+- Sprint crítico em curso (migração é refactor estrutural)
+- Sem sinais reais de dor (build < 5s, sem conflitos)
+
+## Saída esperada
+
+Para Cenário A: atualizar `DARE/BLUEPRINT.md` com a estrutura de crates
+(diagrama + tabela de responsabilidades + `Cargo.toml` workspace).
+
+Para Cenário B: gerar arquivo `DARE/MIGRATION-PLAN.md` com:
+- Sintomas detectados (linhas de código, arquivos, etc.)
+- 4 PRs em ordem com diff de pastas
+- Critério de aceite por PR
+- Estimativa de esforço
+
+$ARGUMENTS

package/templates/ide/claude/CLAUDE.md

@@ -12,7 +12,7 @@ Você é o Claude Code, assistente de desenvolvimento seguindo o método DARE:
 - Atualize o status em `DARE/TASKS.md` ao concluir cada task
 - Nunca pule o Ralph Loop (build → test → lint) antes de marcar uma task como DONE
 - Aprovação humana obrigatória antes de merge para a branch principal
-- Use os slash commands `/dare-design`, `/dare-blueprint`, `/dare-execute`, `/dare-tasks`
+- Use os slash commands `/dare-design`, `/dare-blueprint`, `/dare-execute`, `/dare-tasks`, `/dare-rust-leptos`, `/dare-rust-workspace`
 
 ## Estrutura do Projeto
 ```
@@ -78,6 +78,15 @@ dare execute --parallel     # executa tasks em paralelo respeitando depends_on
 - Pinia para state management
 - Ralph Loop: `npm run build && npm test && npx eslint src`
 
+### Leptos (Rust → WASM) — v2.10+
+- Dois modos: `rust-leptos` (SSR + Axum, cargo-leptos) e `rust-leptos-csr` (WASM puro, trunk)
+- `#[component]` macro, signals reativos, `Resource` para async, `Action` para mutações
+- **Nunca** usar `cargo leptos test` — use `cargo test --workspace`
+- **Nunca** definir `[build] target` global no `.cargo/config.toml` (quebra workspace misto)
+- Ralph Loop fullstack: `cargo leptos build --release && cargo test --workspace && cargo clippy --all-features -- -D warnings`
+- Ralph Loop CSR: `trunk build --release && cargo test --workspace && cargo clippy --all-features -- -D warnings`
+- Use `/dare-rust-leptos` para guia completo de idioms, tipos compartilhados e tasks
+
 ## Knowledge Graph (GraphRAG)
 
 O projeto mantém um grafo de conhecimento em `dare-graph.yml`: