rsc-universal 0.1.1

package/skills/tasks/evals/cases.yaml

@@ -0,0 +1,75 @@
+skill: tasks
+
+# Prompts that MUST load the `tasks` skill. It owns ONE job in the SDD chain:
+# turn an APPROVED plan into an ordered, independently-verifiable task list —
+# each task with a literal done-check, dependencies, a parallel-safe marker,
+# and a trace back to a spec line — appended into the plan artifact under
+# 02-DOCS/wiki/sdd/plans/<slug>.md. It is NOT plan-writing (plan), NOT the
+# consistency gate (analyze), NOT execution (implement).
+should_trigger:
+  - prompt: "The plan for the billing feature is approved — break it into tasks we can actually execute."
+    why: "Slicing an approved plan into an executable task list is the skill's core and only job."
+
+  - prompt: "Descompón el plan de autenticación en una lista de tareas ordenada, cada una con su comprobación de hecho."
+    why: "Spanish phrasing for an ordered task breakdown where each task carries an explicit done-check — exactly this phase."
+
+  - prompt: "Give each step in the build a done-check so a subagent can run it and prove it's finished."
+    why: "Attaching a runnable done-check to every unit so it's independently verifiable is the defining feature of this skill, phrased without naming it."
+
+  - prompt: "We have the design doc and architecture — now sequence the work and tell me which parts can run in parallel."
+    why: "Ordering tasks by dependency and marking which are parallel-safe ([P]) is owned here; the user names sequencing/parallelism, not the skill."
+
+  - prompt: "Turn the plan into a numbered checklist where every item traces back to a requirement in the spec."
+    why: "Producing numbered, spec-traced tasks (Trace field, no orphan tasks) is precisely this phase's output and discipline."
+
+  - prompt: "Before we start coding, I want a task list off the approved plan with dependencies between tasks spelled out."
+    why: "Pre-implementation breakdown of an approved plan with explicit depends-on edges is the tasks phase; it sits between plan and analyze/implement."
+
+  - prompt: "Slice this implementation plan into the smallest units a coding agent can finish and hand off one at a time."
+    why: "Smallest-verifiable-unit slicing for handoff is the skill's stated method, even though 'tasks' is never said."
+
+# NEAR-MISS prompts that must NOT load `tasks`. Each routes to the genuinely
+# correct sibling. The recurring trap: anything in the SDD chain that is the
+# step BEFORE (plan), the gate AFTER (analyze), or the DOING (implement) — plus
+# stack-specific work that a single task merely delegates to.
+should_not_trigger:
+  - prompt: "We don't have a technical plan yet — design the architecture, interfaces, and testing strategy for the billing feature."
+    route_to: "plan"
+    why: "Writing the plan itself (architecture/interfaces/testing) is the `plan` phase; `tasks` slices a plan that already exists, it does not author one."
+
+  - prompt: "Cross-check the constitution, spec, plan, and task list for contradictions or scope drift before we write any code."
+    route_to: "analyze"
+    why: "The pre-implementation consistency gate over all four artifacts is `analyze`; `tasks` produces the list that analyze audits, it doesn't audit."
+
+  - prompt: "Start executing the task list — write the code for T004 and get its test green."
+    route_to: "implement"
+    why: "Executing tasks and writing runtime code (red → green → refactor) is `implement`; `tasks` writes no code, only the list."
+
+  - prompt: "Write the failing pytest and then the FastAPI route for the POST /login endpoint."
+    route_to: "fastapi"
+    why: "Concrete test+endpoint implementation in a specific stack is owned by the stack skill (fastapi) under implement; tasks only references such a command as a done-check, it doesn't write it."
+
+  - prompt: "Write the Alembic migration that adds the users table with a UNIQUE email constraint."
+    route_to: "postgresdb"
+    why: "Authoring the actual migration/schema is postgresdb's job; a tasks row merely cites 'migration applies clean' as a done-check."
+
+  - prompt: "The intent is fuzzy — there are unresolved edge cases in the spec we need to nail down before planning."
+    route_to: "clarify"
+    why: "Surfacing ambiguities and underspecified areas in the spec is the `clarify` gate; tasks refuses to start until the plan (downstream of clarify) is solid."
+
+# A concrete task the skill should guide, graded WITH vs WITHOUT it loaded.
+# A correct skill-guided answer enforces well-formed rows (runnable done-checks,
+# dependency order, [P] discipline, spec traces), appends to the plan artifact,
+# and hands off to analyze — not a flat unverifiable to-do list.
+capability:
+  - scenario: "An approved plan exists at 02-DOCS/wiki/sdd/plans/auth.md (login + sessions + a users migration, pytest as the testing strategy) and a spec at specs/auth.md. Break it into a task list."
+    must_include:
+      - "Confirms the inputs first: plan, spec, AND constitution must exist; if the plan were missing it would STOP and route to `plan` rather than slice from intent."
+      - "Reads 02-DOCS/wiki/harness/user-profile.md for the accompaniment level and adapts verbosity (L0 table-only … L3 explain the slicing/dependencies)."
+      - "Emits sequential zero-padded stable IDs (T001, T002… — no hyphen, GitHub Spec Kit canon) with the six well-formed fields: ID, a separate [P] marker field after the ID, imperative title, done-check, depends-on, and a trace to a spec section."
+      - "Every done-check is a LITERAL runnable command or checkable observation (e.g. `pytest tests/auth/test_login.py` green; `alembic upgrade head` applies; bad password → 401) — never 'login works'."
+      - "Orders by dependency (migration/schema → data → service → API), so no task precedes what it depends on; marks `[P]` only on file/state-disjoint tasks and defaults to sequential when unsure."
+      - "Uses TDD-shaped slicing: a failing-test task before its implementation task, whose done-check is 'the test that was red is now green'."
+      - "Ensures every task traces to a spec line and cuts/flags any task with no trace as scope creep (route to clarify/specify), rather than inventing scope."
+      - "Appends the table under a `## Tasks` heading INSIDE 02-DOCS/wiki/sdd/plans/auth.md (not a new file) and confirms the plan is indexed in the root CLAUDE.md Knowledge map under sdd/."
+      - "Adds a final closer task gating on all done-checks passing plus `scripts/verify.sh` green, and hands off to `analyze` next (then implement) — not straight to implementation."

package/skills/tauri/SKILL.md

@@ -0,0 +1,224 @@
+---
+name: tauri
+description: "Use when building a lightweight cross-platform desktop (or v2 mobile) app with Tauri — a Rust core plus the OS-native WebView — wiring Rust commands and IPC, streaming data to the frontend, locking down the capabilities/permissions security model, or bundling and auto-updating tiny signed binaries. Triggers: 'build a Tauri app', 'expose a Rust command to my frontend', 'invoke from JS', 'tauri.conf.json', 'capabilities and permissions', 'stream download progress to the WebView', 'my command froze the UI', 'shrink my desktop binary vs Electron', 'set up the Tauri updater', 'crear una app d'escriptori lleugera amb Rust en lloc d'Electron', 'reducir el tamaño del binario de escritorio'. NOT a Chromium+Node desktop app that needs Node APIs in a main process (that is electron)."
+tags: [tauri, desktop, rust, cross-platform, ipc, webview]
+recommends: [rust, electron, react, secure-coding, github-actions]
+origin: risco
+---
+
+# Tauri — Rust core, OS WebView, locked-down IPC, tiny binaries
+
+Tauri builds a desktop (and, since v2, mobile) app from a **Rust core** plus the
+**operating system's own WebView** — not a bundled browser. That is the whole value
+proposition: ~12MB installers and 30-50MB idle RAM, versus Electron's ~180MB installers
+and 150-300MB because it ships Chromium + Node. You write your UI in any web framework,
+expose privileged work as Rust commands, and the WebView talks to Rust over a sandboxed
+IPC bridge.
+
+**Always target v2.** Tauri 2.0 went stable in October 2024; the current line is 2.x
+(2.11.x as of mid-2026). v1 docs use a `tauri > allowlist` config that no longer exists —
+if you see `allowlist`, you are reading the wrong era. v2 also adds iOS/Android targets,
+so the same Rust core can ship to mobile.
+
+This skill owns the **shell**: commands, IPC, the security ACL, the bundler, the updater.
+It does **not** own the Rust language itself (that is the `rust` skill), the web UI inside
+the window (the `react`/`nextjs` skills), or a Chromium+Node shell (`../electron/SKILL.md`).
+
+## Pick your starting shape
+
+| Situation | Do this |
+|-----------|---------|
+| Greenfield app, no UI yet | `npm create tauri-app@latest` — pick your frontend, get `src-tauri/` wired |
+| You already have a web app (Vite/Next/etc.) | `npx @tauri-apps/cli@latest init` inside it; point `build.frontendDist` at your build output |
+| Add mobile to an existing desktop app | `tauri ios init` / `tauri android init`; gate native bits behind `#[cfg(mobile)]` |
+| You see `tauri.conf.json > tauri > allowlist` | You are on v1 — migrate to v2 capabilities before adding anything |
+
+`src-tauri/` is its own Cargo crate: `Cargo.toml`, `tauri.conf.json`, `src/lib.rs`
+(the `run()` entry point), and `capabilities/`. The frontend is a sibling directory the
+bundler reads from `frontendDist`.
+
+## Commands & IPC — the core contract
+
+A command is a Rust function the frontend can call. Each rule below has a one-line *why*.
+
+- **Annotate and register.** `#[tauri::command]` on the fn, then list it in
+  `tauri::generate_handler![...]` inside `invoke_handler`. *Unregistered commands are not a
+  compile error — they fail at runtime when JS calls them.*
+- **Naming crosses the bridge.** JS `invoke('read_config', { filePath })` maps to Rust
+  `read_config(file_path: String)`. *Command names stay snake_case; args auto-map
+  camelCase (JS) ⇄ snake_case (Rust).*
+- **Fallible commands return `Result<T, E>` where `E: Serialize`.** *An `Err` becomes a
+  rejected JS promise; a panic instead crashes the command thread silently.*
+- **Never block the command thread.** Long or I/O work goes in an `async` command or a
+  spawned task. *Commands run on a shared IPC thread pool — a blocking call freezes other
+  IPC, which users see as a frozen UI.*
+- **Share state with `.manage(x)` + `State<'_, T>`.** *If a guard is held across an
+  `.await`, use `tokio::sync::Mutex`, not `std::sync::Mutex` — the std guard is not `Send`
+  and will not compile in an async command.*
+
+```rust
+// src-tauri/src/lib.rs
+use tauri::State;
+use tokio::sync::Mutex;
+
+#[derive(Default)]
+struct AppState { counter: u64 }
+
+#[tauri::command]                                   // registered below or it 404s at runtime
+async fn read_config(file_path: String) -> Result<String, String> {
+    tokio::fs::read_to_string(&file_path)           // async I/O — does not block the IPC pool
+        .await
+        .map_err(|e| e.to_string())                 // Err -> rejected JS promise
+}
+
+#[tauri::command]
+async fn bump(state: State<'_, Mutex<AppState>>) -> Result<u64, String> {
+    let mut s = state.lock().await;                 // tokio Mutex: guard is held across .await
+    s.counter += 1;
+    Ok(s.counter)
+}
+
+#[cfg_attr(mobile, tauri::mobile_entry_point)]      // same core compiles for iOS/Android
+pub fn run() {
+    tauri::Builder::default()
+        .manage(Mutex::new(AppState::default()))
+        .invoke_handler(tauri::generate_handler![read_config, bump])
+        .run(tauri::generate_context!())
+        .expect("error while running tauri application");
+}
+```
+
+```javascript
+// frontend
+import { invoke } from '@tauri-apps/api/core';
+
+const text = await invoke('read_config', { filePath: '/app/config.toml' });
+// throws (rejected promise) if the command returns Err — wrap in try/catch
+```
+
+Bad → Good, the failure people hit most:
+
+```rust
+// Bad: std Mutex held across .await — won't compile in an async command, or you
+// "fix" it by dropping the guard early and create a race.
+async fn save(state: State<'_, std::sync::Mutex<AppState>>) { /* ... */ }
+
+// Good: async-aware lock.
+async fn save(state: State<'_, tokio::sync::Mutex<AppState>>) -> Result<(), String> { Ok(()) }
+```
+
+## Stream vs notify
+
+Two ways to push from Rust to the frontend — pick by ordering needs:
+
+- **`Channel<T>` for ordered streaming.** Download progress, file chunks, an HTTP body.
+  *Messages arrive in send order on one typed channel — the right tool for "report
+  progress as it happens."*
+- **`emit` / `listen` events for fire-and-forget pub/sub.** App-wide notifications, "data
+  refreshed," a tray action. *No ordering or backpressure guarantees; many listeners, no
+  reply.*
+
+```rust
+use tauri::ipc::Channel;
+
+#[derive(Clone, serde::Serialize)]
+struct Progress { downloaded: u64, total: u64 }
+
+#[tauri::command]
+async fn download(url: String, on_progress: Channel<Progress>) -> Result<(), String> {
+    // ... as bytes arrive:
+    on_progress.send(Progress { downloaded: 4096, total: 1_000_000 })
+        .map_err(|e| e.to_string())?;
+    Ok(())
+}
+```
+
+```javascript
+import { Channel, invoke } from '@tauri-apps/api/core';
+
+const onProgress = new Channel();
+onProgress.onmessage = (p) => updateBar(p.downloaded / p.total);
+await invoke('download', { url, onProgress });
+```
+
+## Security — the part people skip
+
+Tauri v2's IPC is an **Access Control List**, default-deny. The chain:
+
+**capabilities** (group windows/webviews) → grant **permissions** (named command sets) →
+**permissions map scopes** (what data/paths a command may touch). **A webview that matches
+no capability has zero IPC access.** This is the opposite of v1's opt-out allowlist —
+you grant exactly what each window needs.
+
+```json
+// src-tauri/capabilities/default.json — grant only what the main window uses
+{
+  "$schema": "../gen/schemas/desktop-schema.json",
+  "identifier": "main-capability",
+  "windows": ["main"],
+  "permissions": [
+    "core:default",
+    {
+      "identifier": "fs:allow-read-text-file",
+      "allow": [{ "path": "$APPCONFIG/*" }]   // scope: app config dir only, nothing else
+    }
+  ]
+}
+```
+
+Three more rules that bite real apps:
+
+- **CSP is only enforced if you set it** in `tauri.conf.json > app > security > csp`.
+  *No CSP = the WebView runs whatever it loads; local scripts are hashed, external ones get
+  a per-load nonce only once a CSP exists.*
+- **Use the isolation pattern when frontend code may be untrusted** (third-party deps,
+  plugins). *It injects a sandboxed iframe that can inspect/modify every IPC message before
+  it reaches Rust; messages are encrypted with SubtleCrypto using a key regenerated each
+  app start.*
+- **Treat the WebView as hostile.** *Anything in the frontend bundle ships to the user —
+  no API keys, tokens, or secrets in JS. Privileged work and secrets stay in Rust.*
+
+Full capabilities/permissions/scope JSON, fs/http scope globs, CSP dev-vs-prod recipes, and
+isolation-pattern setup live in `references/security.md`.
+
+## Bundle & ship
+
+`tauri build` produces native installers per OS — but unsigned binaries trigger
+"unidentified developer" / SmartScreen warnings, so signing is not optional for distribution.
+
+- **macOS:** sign with a Developer ID cert, then **notarize** — Gatekeeper blocks
+  un-notarized apps.
+- **Windows:** Authenticode-sign the `.exe`/MSI/NSIS or SmartScreen warns.
+- **Linux:** AppImage / `.deb` / `.rpm`; no central signing authority, but ship checksums.
+- **Auto-update:** the updater plugin needs a signing keypair (`tauri signer generate`);
+  the private key signs releases, the public key ships in config. *Without it the updater
+  refuses unsigned updates — by design.*
+- **Sidecar:** embed an external binary via `bundle.externalBin` to call it at runtime
+  (e.g. ship a CLI your app shells out to).
+
+Per-OS flags, notarization steps, updater config, sidecar setup, and a CI release matrix
+live in `references/bundling-distribution.md`. The CI runner matrix that *runs* those builds
+across three OSes is the `github-actions` skill's job; this skill defines what to build and sign.
+
+## Anti-patterns
+
+| Anti-pattern | Why it's wrong | Do instead |
+|--------------|----------------|------------|
+| One capability granting broad permissions to all windows | Any XSS gets the full IPC surface | Per-window capability, scoped to the commands that window needs |
+| Permission with no `allow`/scope on `fs`/`http` | Command can touch any path/host | Add an `allow` glob (`$APPCONFIG/*`) and deny the rest |
+| Blocking call (`std::fs`, sync HTTP) in a command | Freezes the IPC pool → frozen UI | `async fn` + `tokio` / spawn the work |
+| `.unwrap()` instead of returning `Result<T, E>` | Panic crashes the command thread silently | Return `Result`, `map_err` to a serializable error |
+| API keys/tokens in the frontend bundle | Ships to every user; trivially extracted | Keep secrets and privileged calls in Rust |
+| No CSP set in config | WebView runs any loaded script | Set `app.security.csp`; isolation pattern if deps are untrusted |
+| Copying a v1 `tauri.conf.json > allowlist` | That key does not exist in v2 | Use `capabilities/*.json` (ACL) |
+| Assuming bundled Chromium | It's the **OS** WebView (WebKit/WebView2) | Test rendering on each OS's engine; avoid Chromium-only CSS/JS |
+
+## Pointers
+
+- `references/security.md` — capabilities/permissions/scope JSON, CSP recipes, isolation setup.
+- `references/bundling-distribution.md` — per-OS signing, updater keypair, sidecar, CI matrix.
+- Siblings: `../electron/SKILL.md` (the Chromium+Node alternative when you need a Node main
+  process), `../secure-coding/SKILL.md` (app-code hardening). The `rust` skill owns the
+  language; `react`/`nextjs` own the frontend UI; `github-actions` owns the release CI matrix.
+- `scripts/verify.sh` — advisory static lint over `src-tauri/` (capabilities present, registered
+  commands exist, no v1 `allowlist`, fallible-looking commands return `Result`).

package/skills/tauri/evals/README.md

@@ -0,0 +1,12 @@
+# Evals — tauri
+
+These cases are a behavioral spec for routing and capability coverage, not a runtime test of
+Tauri itself — nothing here compiles Rust or builds an app. Run them through the repo's eval
+harness: `should_trigger` feeds the skill's `description` + body to the router and asserts it
+selects this skill (including the non-obvious "stream download progress" case, where the right
+answer is a `Channel<T>` and the word "Tauri" never appears); `should_not_trigger` asserts the
+router declines and routes to the named real sibling (electron, expo, rust, react,
+compose-multiplatform); the `capability` scenario prompts the agent and grades the answer against
+the `must_include` rubric (annotated + registered command, `Result<T, E>`, a scoped `fs` glob,
+the default-deny note, and the capability-vs-permission explanation). `scripts/verify.sh` is a
+separate standalone static lint over an `src-tauri/` tree and needs no harness.

package/skills/tauri/evals/cases.yaml

@@ -0,0 +1,46 @@
+skill: tauri
+
+should_trigger:
+  - prompt: "Scaffold a new Tauri 2 desktop app with a React frontend"
+    why: Core greenfield scaffold (create-tauri-app + src-tauri/ wiring) — the starting-shape table this skill owns.
+  - prompt: "Expose a Rust function to my frontend and call it from JS with invoke"
+    why: The commands/IPC contract — #[tauri::command], generate_handler!, camelCase/snake_case mapping.
+  - prompt: "Stream download progress from Rust to the WebView as the bytes come in"
+    why: Non-obvious — the right answer is a Channel<T>, not emit/listen events; the word "Tauri" never appears.
+  - prompt: "Lock down my Tauri app so the frontend can only read its own config directory"
+    why: The capabilities -> permissions -> scoped fs glob ($APPCONFIG) security model.
+  - prompt: "Vull fer una app d'escriptori lleugera amb Rust en lloc d'Electron"
+    why: Catalan phrasing plus the Tauri-vs-Electron boundary (small Rust+OS-WebView shell) this skill is framed around.
+  - prompt: "My Tauri command froze the whole UI while it was reading a big file"
+    why: Symptom phrasing for the blocking-the-IPC-thread anti-pattern; fix is async/spawn.
+  - prompt: "Set up the Tauri updater so my signed releases can auto-update"
+    why: Updater plugin + signing keypair, part of the bundling/distribution surface.
+
+should_not_trigger:
+  - prompt: "Build a desktop app in Electron that uses Node fs in the main process"
+    route_to: electron
+    why: Needs Node APIs in a main process and bundled Chromium — Electron's domain, explicitly the boundary case.
+  - prompt: "Set up an Expo React Native mobile app with the dev client"
+    route_to: expo
+    why: Mobile-first RN stack; Tauri's mobile is a v2 add-on to a desktop web app, not Expo tooling.
+  - prompt: "Explain Rust async lifetimes and why my future isn't Send"
+    route_to: rust
+    why: A language question about async/Send, not the desktop shell, IPC bridge, or bundler.
+  - prompt: "Style my React component grid to fill the desktop window"
+    route_to: react
+    why: Web-UI styling inside the window; the frontend framework, not the Tauri shell.
+  - prompt: "Build a single Kotlin/Compose codebase that runs on Android and desktop"
+    route_to: compose-multiplatform
+    why: Native Kotlin/Compose multiplatform, not a Rust core + web WebView.
+
+capability:
+  - scenario: "Add a `read_config` command that returns Result<String, String>, register it so the frontend can invoke it, restrict the fs scope to the app config directory, and explain the difference between a capability and a permission."
+    must_include:
+      - "#[tauri::command] annotation on the function"
+      - "Result<String, String> return (fallible -> rejected JS promise, no unwrap/panic)"
+      - "Command registered in tauri::generate_handler![...] inside invoke_handler"
+      - "A capabilities/*.json file under src-tauri/capabilities/"
+      - "fs scope glob restricted to the app config dir (e.g. $APPCONFIG/*), not the whole FS"
+      - "Default-deny note: a window with no matching capability has zero IPC access"
+      - "Explains capability = grouping of windows that grants permissions; permission = a named command set whose scope bounds the data it touches"
+      - "Frontend invoke('read_config', { ... }) call with camelCase args"

package/skills/tauri/references/bundling-distribution.md

@@ -0,0 +1,129 @@
+# Tauri v2 bundling & distribution
+
+`tauri build` compiles the Rust core in release mode and produces native installers from
+your `frontendDist`. The recurring trap: unsigned binaries trigger OS warnings
+("unidentified developer", SmartScreen), so signing + (on macOS) notarization is part of
+shipping, not an afterthought.
+
+## Build targets per OS
+
+```bash
+tauri build                      # all configured bundle targets for the host OS
+tauri build --bundles dmg        # macOS: just the .dmg
+tauri build --bundles nsis,msi   # Windows: NSIS installer + MSI
+tauri build --bundles appimage,deb # Linux
+tauri build --target aarch64-apple-darwin   # cross-arch (toolchain must be installed)
+```
+
+You build **on** each target OS (or in CI runners for each); there is no single-host
+cross-build for everything because the bundler uses native tooling.
+
+| OS | Bundle formats | Signing |
+|----|----------------|---------|
+| macOS | `.app`, `.dmg` | Developer ID cert + **notarization** (Gatekeeper) |
+| Windows | NSIS (`-setup.exe`), MSI | Authenticode (SmartScreen) |
+| Linux | AppImage, `.deb`, `.rpm` | No central authority; ship checksums/GPG |
+
+## macOS signing + notarization
+
+1. Set the signing identity in config or env:
+
+```json
+// tauri.conf.json
+{ "bundle": { "macOS": { "signingIdentity": "Developer ID Application: Your Name (TEAMID)" } } }
+```
+
+2. Provide notarization credentials as env vars for `tauri build`:
+
+```bash
+export APPLE_ID="you@example.com"
+export APPLE_PASSWORD="app-specific-password"   # not your Apple ID password
+export APPLE_TEAM_ID="TEAMID"
+tauri build --bundles dmg       # signs, then submits for notarization + staples
+```
+
+Without notarization, Gatekeeper blocks the app on a clean machine even if it's signed.
+
+## Windows Authenticode
+
+```json
+// tauri.conf.json
+{ "bundle": { "windows": {
+  "certificateThumbprint": "AB12...",   // cert installed in the Windows cert store
+  "digestAlgorithm": "sha256",
+  "timestampUrl": "http://timestamp.digicert.com"
+} } }
+```
+
+Cloud/HSM signing (Azure Trusted Signing, etc.) is the modern path for CI where a local
+cert store isn't available.
+
+## Updater plugin
+
+The updater refuses unsigned updates by design — generate a keypair first.
+
+```bash
+tauri signer generate -w ~/.tauri/myapp.key   # prints the PUBLIC key to embed in config
+```
+
+```json
+// tauri.conf.json
+{ "plugins": { "updater": {
+  "pubkey": "<PUBLIC KEY FROM ABOVE>",
+  "endpoints": ["https://releases.example.com/{{target}}/{{arch}}/{{current_version}}"]
+} } }
+```
+
+- The **private** key signs each release (`TAURI_SIGNING_PRIVATE_KEY` in CI); never commit it.
+- The endpoint returns a JSON manifest with the new version, signature, and download URL.
+- Frontend: install `@tauri-apps/plugin-updater`, call `check()` then `downloadAndInstall()`.
+
+## Sidecar (embed an external binary)
+
+Ship and run an external executable alongside your app.
+
+```json
+// tauri.conf.json
+{ "bundle": { "externalBin": ["binaries/my-cli"] } }
+```
+
+Name the file per target triple (`my-cli-x86_64-apple-darwin`, etc.). Grant the
+`shell:allow-execute` permission scoped to that sidecar to invoke it from Rust/JS.
+
+## GitHub Actions release matrix (sketch)
+
+One job per OS, each runs `tauri build` and uploads artifacts. Pair with the
+`github-actions` skill for the CI mechanics.
+
+```yaml
+jobs:
+  build:
+    strategy:
+      matrix:
+        include:
+          - { platform: macos-latest,   args: '--target aarch64-apple-darwin' }
+          - { platform: macos-latest,   args: '--target x86_64-apple-darwin' }
+          - { platform: ubuntu-22.04,   args: '' }
+          - { platform: windows-latest, args: '' }
+    runs-on: ${{ matrix.platform }}
+    steps:
+      - uses: actions/checkout@v4
+      - uses: dtolnay/rust-toolchain@stable
+      - run: npm ci && npm run tauri build -- ${{ matrix.args }}
+        env:
+          TAURI_SIGNING_PRIVATE_KEY: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY }}
+          APPLE_ID: ${{ secrets.APPLE_ID }}
+          APPLE_PASSWORD: ${{ secrets.APPLE_PASSWORD }}
+          APPLE_TEAM_ID: ${{ secrets.APPLE_TEAM_ID }}
+```
+
+On Linux runners install the WebKitGTK system deps before building (the Tauri docs list the
+exact apt packages for your Ubuntu version).
+
+## Checklist
+
+- [ ] Build per target OS (host or CI runner), not a single cross-build.
+- [ ] macOS signed **and** notarized; Windows Authenticode-signed.
+- [ ] Updater keypair generated; private key only in CI secrets, public key in config.
+- [ ] Sidecar binaries named per target triple + scoped `shell:allow-execute`.
+- [ ] Linux WebKitGTK deps installed in CI.

package/skills/tauri/references/security.md

@@ -0,0 +1,143 @@
+# Tauri v2 security — capabilities, permissions, scopes, CSP, isolation
+
+The IPC bridge is default-deny. Nothing in the frontend can call Rust until a **capability**
+applies to that window and grants the matching **permissions**, and a permission's **scope**
+bounds what data/paths/hosts the command may touch. Get this layer right and an XSS in the
+WebView can only do what you explicitly granted.
+
+## The chain
+
+```text
+capability  ──applies to──▶  one or more windows/webviews
+    │
+    └─grants─▶  permissions  ──each maps──▶  scope (paths, hosts, …)
+```
+
+A webview matching **no** capability has **zero** IPC access. There is no global allow.
+
+## Capability file anatomy
+
+Files live in `src-tauri/capabilities/*.json` and are merged at build time.
+
+```json
+{
+  "$schema": "../gen/schemas/desktop-schema.json",
+  "identifier": "main-capability",
+  "description": "What the main window is allowed to do.",
+  "windows": ["main"],
+  "permissions": [
+    "core:default",
+    "dialog:allow-open",
+    {
+      "identifier": "fs:allow-read-text-file",
+      "allow": [{ "path": "$APPCONFIG/*" }]
+    }
+  ]
+}
+```
+
+- `identifier` — unique per file.
+- `windows` — glob of window labels this capability binds to (`["main"]`, `["settings-*"]`).
+- `permissions` — either a string id (`plugin:permission-name`, e.g. `fs:allow-read-file`)
+  or an object that **scopes** the permission with `allow` / `deny`.
+- `platforms` (optional) — restrict to `["macOS", "windows", "linux", "iOS", "android"]`.
+
+## Permission identifiers
+
+Format is `plugin:permission`. Conventions:
+
+- `core:default` — the baseline core permission set; safe to keep.
+- `fs:allow-read-text-file`, `fs:allow-write-text-file`, `fs:allow-mkdir`, … — granular.
+- `fs:default` / `http:default` — convenience bundles; **prefer granular** so you only
+  grant the verbs you use.
+- `deny-*` variants exist and win over `allow-*` — use to carve exceptions out of a bundle.
+
+## Scope globs (fs / http)
+
+Scopes restrict the *data* a permission reaches. They take path or URL globs, with
+path variables resolved at runtime.
+
+```json
+// fs: read only inside the app config dir, never the home dir
+{ "identifier": "fs:allow-read-text-file",
+  "allow": [{ "path": "$APPCONFIG/*" }],
+  "deny":  [{ "path": "$HOME/.ssh/*" }] }
+```
+
+Common path variables: `$APPCONFIG`, `$APPDATA`, `$APPLOCALDATA`, `$APPCACHE`, `$APPLOG`,
+`$HOME`, `$DOCUMENT`, `$DOWNLOAD`, `$RESOURCE`, `$TEMP`. Prefer the `$APP*` set — they
+resolve under the app's own sandbox dir.
+
+```json
+// http: only your API, nothing else
+{ "identifier": "http:default",
+  "allow": [{ "url": "https://api.example.com/*" }] }
+```
+
+`deny` always overrides `allow`. A permission with neither is effectively "any" — always
+add an `allow`.
+
+## Per-window privilege separation
+
+Split capabilities so a low-trust window can't reach high-trust commands. Give the main UI
+one capability and an embedded/third-party webview a far narrower one (or none).
+
+```json
+// capabilities/embed.json — a webview showing third-party content gets almost nothing
+{ "identifier": "embed-capability", "windows": ["embed-*"], "permissions": ["core:default"] }
+```
+
+## CSP
+
+CSP is enforced **only if set** in config. Until then the WebView runs whatever it loads.
+
+```json
+// tauri.conf.json — prod: lock to self; Tauri injects nonces/hashes for your assets
+{ "app": { "security": {
+  "csp": "default-src 'self'; img-src 'self' data:; connect-src 'self' https://api.example.com"
+} } }
+```
+
+- Local scripts/styles are **hashed**; external ones get a **per-load nonce** — both only
+  once a CSP string exists.
+- In dev you typically need a looser `connect-src` for the Vite/HMR dev server; keep the
+  strict policy for the production build (`devCsp` vs `csp` if you split them).
+- A `<meta>` CSP tag does not cover the initial document — set CSP in config, not just markup.
+
+## Isolation pattern
+
+Use when frontend code might be untrusted — third-party npm deps, plugins, anything you
+don't fully control. It injects a sandboxed `<iframe>` that intercepts every IPC message
+before it reaches Rust, so you can validate or reject it. Messages are encrypted with the
+browser's SubtleCrypto using an AES key **regenerated on each app start**.
+
+1. Set the pattern in `tauri.conf.json`:
+
+```json
+{ "app": { "security": { "pattern": {
+  "use": "isolation",
+  "options": { "dir": "../dist-isolation" }
+} } } }
+```
+
+2. Provide `dist-isolation/index.html` loading a hook that inspects each message:
+
+```javascript
+// dist-isolation/index.js
+window.__TAURI_ISOLATION_HOOK__ = (payload) => {
+  // inspect / sanitize / reject before it reaches Rust
+  return payload;
+};
+```
+
+Cost: a small per-message crypto overhead. Worth it whenever the frontend supply chain is
+not fully trusted.
+
+## Checklist
+
+- [ ] Every window that calls Rust has a capability; no global allow.
+- [ ] `fs`/`http` permissions carry an `allow` scope; sensitive paths in `deny`.
+- [ ] Granular permissions, not `*:default` bundles, where practical.
+- [ ] CSP set in config for the production build.
+- [ ] Isolation pattern on if frontend deps/plugins are untrusted.
+- [ ] No secrets in the frontend bundle — they live in Rust.