@damiangilgonzalez/harness 1.3.7

package/skills/tauri/SKILL.md

@@ -0,0 +1,219 @@
+---
+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: Rust commands and IPC, streaming to the frontend, the default-deny capabilities/permissions ACL, bundling and signed auto-updates. NOT a Chromium+Node shell needing 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), a Chromium+Node shell (`../electron/SKILL.md`), or
+app-code hardening beyond the IPC boundary (`../secure-coding/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 |
+
+`scripts/verify.sh` is an advisory static lint over an `src-tauri/` tree that catches several of
+these: 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.