Fix rebase type errors and add TODO date tag

- Await listAvailableEditorTargets() which became async on main
- Wrap sendAgentMessage callback to match Promise<void> return type
- Add TODO(2026-07) date to legacy editor target ids comment

.agents/skills/release-beta/SKILL.md

@@ -1,9 +0,0 @@
----
-name: release-beta
-description: Cut a beta release of Paseo. Use when the user says "release beta", "cut a beta", "ship a beta", "beta release", or "/release-beta".
-user-invocable: true
----
-
-# Release beta
-
-Follow the **Beta flow** and **Beta release** completion checklist in `docs/release.md` end-to-end.

.agents/skills/release-stable/SKILL.md

@@ -1,9 +0,0 @@
----
-name: release-stable
-description: Cut a stable release of Paseo (fresh patch or minor, or promote from beta). Use when the user says "release stable", "ship stable", "promote", "release:patch", "release:minor", "release:promote", or "/release-stable".
-user-invocable: true
----
-
-# Release stable
-
-Follow the applicable flow and the **Stable release (or promotion)** completion checklist in `docs/release.md` end-to-end.

.claude/skills/release-beta

@@ -1 +0,0 @@
-../../.agents/skills/release-beta

.claude/skills/release-stable

@@ -1 +0,0 @@
-../../.agents/skills/release-stable

.dockerignore

@@ -1,41 +0,0 @@
-.git
-.debug.conversations
-.debug
-.dev
-.playwright-mcp
-**/.playwright-mcp
-.paseo
-**/.paseo-provider-history
-.plans
-.tasks
-.valknut
-.claude/settings.local.json
-**/.claude/settings.local.json
-.claude/scheduled_tasks.lock
-.claude/worktrees
-.wrangler
-**/.wrangler
-**/.tanstack
-PLAN.md
-valknut-report.html
-valknut-report.json
-.env*
-**/.env*
-.dev.vars
-**/.dev.vars
-*.pem
-**/*.pem
-**/.secrets
-**/node_modules
-**/dist
-**/build
-**/.cache
-**/.expo
-**/test-results
-**/*.tsbuildinfo
-artifacts
-packages/app/android
-packages/desktop/release
-plan.*.log
-*.log
-CLAUDE.local.md

.github/ISSUE_TEMPLATE/bug-report.yml

@@ -1,123 +0,0 @@
-name: Bug report
-description: Something is broken or doesn't behave the way it should.
-title: "bug: "
-labels: ["bug"]
-body:
-  - type: markdown
-    attributes:
-      value: |
-        Issues are only for bugs. Product discussions go in [GitHub Discussions](https://github.com/getpaseo/paseo/discussions) or `#product` in [Discord](https://discord.gg/jz8T2uahpH) — feature requests opened as issues get closed automatically.
-
-        Before opening, please:
-
-        - search existing issues for the same symptom
-        - try to reproduce on the latest version
-        - if it's a UI bug, capture a screenshot or short video. text descriptions of UI bugs almost always lose detail.
-
-  - type: textarea
-    id: description
-    attributes:
-      label: What's broken
-      description: What happened, and what did you expect to happen instead?
-      placeholder: |
-        I tried to X, expected Y, got Z.
-    validations:
-      required: true
-
-  - type: textarea
-    id: repro
-    attributes:
-      label: Steps to reproduce
-      description: The shortest sequence that triggers the bug. If you can't reproduce on demand, say so.
-      placeholder: |
-        1. Open the desktop app
-        2. Pair a daemon
-        3. Click X
-        4. ...
-    validations:
-      required: true
-
-  - type: dropdown
-    id: surface
-    attributes:
-      label: Where did this happen
-      description: The surface you saw the bug on. Pick the closest match.
-      options:
-        - iOS app
-        - Android app
-        - Web (browser)
-        - Desktop (Electron)
-        - CLI
-        - Daemon
-        - Other
-    validations:
-      required: true
-
-  - type: input
-    id: paseo-version
-    attributes:
-      label: Paseo version
-      description: Settings → About in the app, or `paseo --version` from the CLI.
-      placeholder: "0.1.71"
-    validations:
-      required: true
-
-  - type: input
-    id: os-version
-    attributes:
-      label: OS version
-      description: Only relevant for desktop, CLI, or daemon issues. Skip for mobile or web.
-      placeholder: "macOS 15.2, Windows 11, Ubuntu 24.04"
-
-  - type: dropdown
-    id: provider
-    attributes:
-      label: Agent provider
-      description: If the bug involves a specific agent provider, pick which one.
-      options:
-        - Not relevant
-        - Claude Code
-        - Codex
-        - OpenCode
-        - Custom provider
-
-  - type: textarea
-    id: provider-details
-    attributes:
-      label: Provider configuration
-      description: |
-        If the bug involves an agent, what version are you on and what API are you using? Provider behavior changes a lot across versions and API backends.
-      placeholder: |
-        Claude Code v1.2.3 with Anthropic API
-        Codex CLI v0.5.0 with OpenAI API
-        OpenCode v0.3.1
-        (or paste the relevant section of ~/.paseo/config.json for custom providers)
-
-  - type: textarea
-    id: logs
-    attributes:
-      label: Logs
-      description: |
-        Paste relevant log output. Strongly preferred for crashes and daemon issues.
-
-        - **Daemon log:** `~/.paseo/daemon.log` (override with `$PASEO_HOME`)
-        - **Electron log (macOS):** `~/Library/Logs/Paseo/main.log`
-        - **Electron log (Windows):** `%APPDATA%\Paseo\logs\main.log`
-        - **Electron log (Linux):** `~/.config/Paseo/logs/main.log`
-
-        Paste the **full log around the time of the bug**, not a summary. If you used an AI to investigate, paste the raw log it read, not the AI's interpretation. AI summaries skew the signal and waste my time.
-      render: text
-
-  - type: textarea
-    id: screenshots
-    attributes:
-      label: Screenshots or video
-      description: |
-        **Required for UI bugs.** Drag and drop directly into this field. Short videos beat screenshots for anything involving interaction or animation.
-
-  - type: markdown
-    attributes:
-      value: |
-        ---
-
-        **A note on AI-assisted reports.** Using an agent to gather information (logs, repro steps, version checks) is fine and useful. Using an agent to *diagnose* the bug and then submitting only that diagnosis is not. Agents routinely correlate adjacent log lines as cause-and-effect when they aren't related, and once a report is filtered through an AI summary I lose the signal I need to actually fix the bug. Paste the raw inputs.

.github/ISSUE_TEMPLATE/config.yml

@@ -1,8 +0,0 @@
-blank_issues_enabled: false
-contact_links:
-  - name: Product discussion on Discord
-    url: https://discord.gg/jz8T2uahpH
-    about: Product discussion, including feature requests
-  - name: Product discussion on GitHub
-    url: https://github.com/getpaseo/paseo/discussions
-    about: Product discussion, including feature requests

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,49 +0,0 @@
-<!--
-Please follow this template. The PR template applies whether you opened the PR via the web UI, `gh pr create`, or any other tool.
-
-You MUST read CONTRIBUTING.md before sending a PR.
--->
-
-### Linked issue
-
-Closes #
-
-### Type of change
-
-- [ ] Bug fix
-- [ ] New feature
-- [ ] Enhancement
-- [ ] Refactor
-- [ ] Docs
-
-### Reasoning
-
-<!-- A short description of the reasoning of this change in your own words. What was wrong, and how do you hope this PR fixes it. If you can't explain this briefly, the PR is probably too big. This description must be grounded in real user flows and framed as value provided to Paseo users. -->
-
-### Goals
-
-<!-- A bullet list of what this PR wants to accomplish, include requirements and acceptance criteria. This helps lock down the scope of the PR and prevent expanding scope over the intended goal. -->
-
-### Non-goals
-
-<!-- A bullet list of what this PR does not want to accomplish. Add any intentional trade offs taken. This helps lock down the scope of the PR and prevent expanding scope over the intended goal. -->
-
-### QA
-
-<!--
-This is the section I read most carefully. I need to see that *you* tested this, not that the diff looks plausible.
-
-- For UI changes: a screenshot or short video on every affected platform (mobile, web, desktop). UI claims without visual proof are not enough.
-- For behavior changes: the actual steps you ran, and what you observed.
-- For bug fixes: how you reproduced the bug before, and confirmed it's fixed after.
--->
-
-### Checklist
-
-- [ ] Plugin changes follow the [SDK import boundaries](../docs/plugins.md#sdk-import-boundaries) (if applicable)
-- [ ] One focused change
-- [ ] `npm run typecheck` passes
-- [ ] `npm run lint` passes
-- [ ] `npm run format` passes
-- [ ] QA evidence
-- [ ] Tests added or updated where it made sense

.github/ci-paths.yml

@@ -1,87 +0,0 @@
-# Pull-request checks are routed by the behavior they prove. Package consumers
-# do not inherit their dependencies' test suites; main and manual runs execute
-# every contract regardless of these paths.
-routing:
-  - ".github/ci-paths.yml"
-
-workspace:
-  - ".mise.toml"
-  - ".tool-versions"
-  - "package.json"
-  - "package-lock.json"
-  - "patches/**"
-  - "scripts/**"
-  - "tsconfig.json"
-  - "tsconfig.base.json"
-  - "vitest.config.ts"
-
-ci:
-  - ".github/actions/**"
-  - ".github/workflows/ci.yml"
-
-format:
-  - ".agents/**/*.{cjs,css,html,js,json,jsonc,jsx,md,mjs,ts,tsx,yaml,yml}"
-  - ".github/**/*.{cjs,css,html,js,json,jsonc,jsx,md,mjs,ts,tsx,yaml,yml}"
-  - "**/*.{cjs,css,html,js,json,jsonc,jsx,md,mjs,ts,tsx,yaml,yml}"
-  - "packages/expo-two-way-audio/**"
-
-quality:
-  - "**/*.{cjs,js,json,jsx,mjs,ts,tsx}"
-  - "packages/expo-two-way-audio/**"
-
-hub:
-  - "packages/cli/src/commands/hub/**"
-  - "packages/server/src/server/hub/**"
-
-server:
-  - "plugins/**"
-  - "packages/server/**"
-  - "packages/app/e2e/support/fixtures/recording.*"
-
-desktop:
-  - "packages/desktop/**"
-  - "packages/app/src/desktop/**"
-  - "packages/server/src/server/browser-tools/**"
-  - "packages/app/e2e/support/**"
-  - "packages/app/*config.{cjs,js,ts}"
-  - "packages/app/package.json"
-
-app:
-  - "packages/app/**"
-  - "packages/expo-two-way-audio/**"
-
-sdk:
-  - "packages/plugin/**"
-  - "plugin-examples/**"
-  - "public-docs/plugins/**"
-  - "packages/client/**"
-  - "packages/highlight/**"
-  - "packages/protocol/**"
-
-browser:
-  - "packages/server/src/server/agent/provider-snapshot-manager.ts"
-  - "packages/server/src/server/session/provider/provider-catalog-session.ts"
-  - "packages/client/src/compat/normalize-provider-models.ts"
-  - "packages/protocol/src/client-capabilities.ts"
-  - "packages/server/src/server/agent/provider-registry.ts"
-  - "packages/server/src/server/agent/agent-sdk-types.ts"
-  - "packages/server/src/server/agent/providers/codex-app-server-agent.ts"
-  - "packages/server/src/server/agent/providers/claude/agent.ts"
-  - "packages/server/src/server/agent/plugin-provider.ts"
-  - "packages/server/src/server/plugins/{index,plugin-process,plugin-process-protocol,runtime}.ts"
-  - "packages/server/src/executable-resolution/**"
-  - "packages/plugin/src/server/provider.ts"
-  - "packages/app/src/!(desktop)/**"
-  - "packages/app/e2e/browser/**"
-  - "packages/app/e2e/support/**"
-  - "packages/app/assets/**"
-  - "packages/app/public/**"
-  - "packages/app/index.ts"
-  - "packages/app/*config.{cjs,js,ts}"
-  - "packages/app/package.json"
-
-relay:
-  - "packages/relay/**"
-
-cli:
-  - "packages/cli/**"

.github/workflows/android-apk-release.yml

@@ -20,50 +20,7 @@ env:
   SOURCE_TAG: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.tag || github.ref_name }}
 
 jobs:
-  ensure-release:
-    permissions:
-      contents: write
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          sparse-checkout: scripts
-          ref: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.tag || github.ref }}
-
-      - name: Resolve release tag
-        shell: bash
-        run: node scripts/emit-release-env.mjs --source-tag "$SOURCE_TAG" >> "$GITHUB_ENV"
-
-      - name: Ensure GitHub release exists
-        env:
-          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        shell: bash
-        run: |
-          set -euo pipefail
-
-          if node scripts/github-release.mjs --repo "${{ github.repository }}" --tag "$RELEASE_TAG" >/dev/null 2>&1; then
-            exit 0
-          fi
-
-          release_args=(
-            release create "$RELEASE_TAG"
-            --repo "${{ github.repository }}"
-            --title "Paseo $RELEASE_TAG"
-            --notes ""
-            --draft
-          )
-
-          if [[ "$IS_PRERELEASE" == "true" ]]; then
-            release_args+=(--prerelease)
-          fi
-
-          if ! gh "${release_args[@]}"; then
-            echo "Release creation raced with another workflow; continuing."
-            node scripts/github-release.mjs --repo "${{ github.repository }}" --tag "$RELEASE_TAG" >/dev/null
-          fi
-
   publish-android-apk:
-    needs: [ensure-release]
     permissions:
       contents: write
       packages: read
@@ -79,6 +36,32 @@ jobs:
         shell: bash
         run: node scripts/emit-release-env.mjs --source-tag "$SOURCE_TAG" >> "$GITHUB_ENV"
 
+      - name: Ensure GitHub release exists
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        shell: bash
+        run: |
+          set -euo pipefail
+
+          if gh release view "$RELEASE_TAG" --repo "${{ github.repository }}" >/dev/null 2>&1; then
+            exit 0
+          fi
+
+          release_args=(
+            release create "$RELEASE_TAG"
+            --repo "${{ github.repository }}"
+            --title "Paseo $RELEASE_TAG"
+            --generate-notes
+          )
+
+          if [[ "$IS_PRERELEASE" == "true" ]]; then
+            release_args+=(--prerelease)
+          fi
+
+          if ! gh "${release_args[@]}"; then
+            echo "Release creation raced with another workflow; continuing."
+          fi
+
       - name: Setup Node
         uses: actions/setup-node@v4
         with:
@@ -88,7 +71,7 @@ jobs:
           scope: "@boudra"
 
       - name: Install JS dependencies
-        run: node scripts/npm-retry.mjs ci
+        run: npm ci
         env:
           NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 
@@ -146,5 +129,4 @@ jobs:
         env:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         run: |
-          release_lookup="$(node scripts/github-release.mjs --repo "${{ github.repository }}" --tag "$RELEASE_TAG")"
-          gh release upload "$release_lookup" "${{ steps.artifact.outputs.asset_path }}" --clobber --repo "${{ github.repository }}"
+          gh release upload "$RELEASE_TAG" "${{ steps.artifact.outputs.asset_path }}" --clobber --repo "${{ github.repository }}"

.github/workflows/ci.yml

@@ -1,533 +0,0 @@
-name: CI
-
-on:
-  push:
-    branches: [main]
-  pull_request:
-    branches: [main]
-  merge_group:
-  workflow_dispatch:
-
-concurrency:
-  group: ci-${{ github.workflow }}-${{ github.ref }}
-  cancel-in-progress: ${{ github.event_name == 'pull_request' }}
-
-env:
-  # CI does not use the CUDA execution provider, and the onnxruntime-node
-  # postinstall download from NuGet is large enough to make npm ci flaky.
-  ONNXRUNTIME_NODE_INSTALL: skip
-
-jobs:
-  changes:
-    name: changes
-    runs-on: ubuntu-latest
-    permissions:
-      contents: read
-      pull-requests: read
-    outputs:
-      full: ${{ github.event_name != 'pull_request' || steps.filter.outputs.routing != 'false' || steps.filter.outputs.workspace != 'false' || steps.filter.outputs.ci != 'false' }}
-      format: ${{ steps.filter.outputs.format }}
-      quality: ${{ steps.filter.outputs.quality }}
-      hub: ${{ steps.filter.outputs.hub }}
-      server: ${{ steps.filter.outputs.server }}
-      desktop: ${{ steps.filter.outputs.desktop }}
-      app: ${{ steps.filter.outputs.app }}
-      sdk: ${{ steps.filter.outputs.sdk }}
-      browser: ${{ steps.filter.outputs.browser }}
-      relay: ${{ steps.filter.outputs.relay }}
-      cli: ${{ steps.filter.outputs.cli }}
-    steps:
-      - uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4.4.0
-        with:
-          fetch-depth: 0
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: "22"
-
-      - name: Detect affected CI contracts
-        id: filter
-        uses: dorny/paths-filter@d1c1ffe0248fe513906c8e24db8ea791d46f8590 # v3.0.3
-        with:
-          filters: .github/ci-paths.yml
-
-      - name: Validate CI contracts
-        run: node --test scripts/ci-workflow.test.mjs scripts/daemon-launch-contract.test.mjs scripts/sync-fdroid-changelogs.test.mjs scripts/upload-release-assets.test.mjs
-
-  format:
-    name: format
-    needs: changes
-    if: ${{ !cancelled() && (needs.changes.outputs.full != 'false' || needs.changes.outputs.format != 'false') }}
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: "22"
-          cache: "npm"
-
-      - name: Install dependencies
-        run: node scripts/npm-retry.mjs ci
-
-      - name: Check formatting
-        run: npm run format:check
-
-  lint:
-    name: lint
-    needs: changes
-    if: ${{ !cancelled() && (needs.changes.outputs.full != 'false' || needs.changes.outputs.quality != 'false') }}
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: "22"
-          cache: "npm"
-
-      - name: Install dependencies
-        run: node scripts/npm-retry.mjs ci
-
-      - name: Lint lockfile
-        run: npx --yes lockfile-lint --path package-lock.json --type npm --allowed-hosts npm --validate-https --validate-integrity
-
-      - name: Verify dependency signatures
-        run: npm audit signatures
-
-      - name: Lint
-        run: npm run lint
-
-  typecheck:
-    name: typecheck
-    needs: changes
-    if: ${{ !cancelled() && (needs.changes.outputs.full != 'false' || needs.changes.outputs.quality != 'false') }}
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: "22"
-          cache: "npm"
-
-      - name: Install dependencies
-        run: node scripts/npm-retry.mjs ci
-
-      - name: Build server stack
-        run: npm run build:server
-
-      - name: Verify built-in plugins from built output
-        run: node --test scripts/builtin-plugins-dist.test.mjs
-
-      - name: Typecheck all packages
-        run: npm run typecheck
-
-      - name: Run website tests
-        run: npx vitest run packages/website/src --bail=1
-
-      - name: Install website test browsers
-        run: npx playwright install --with-deps chromium webkit
-
-      - name: Verify website mockups
-        run: npm run test:e2e --workspace=@getpaseo/website
-
-      - name: Verify public package contents
-        run: |
-          npm pack --dry-run --ignore-scripts --workspace=@getpaseo/protocol
-          npm pack --dry-run --ignore-scripts --workspace=@getpaseo/client
-          npm pack --dry-run --ignore-scripts --workspace=@getpaseo/server
-
-  server-tests-ubuntu:
-    name: server-tests (ubuntu-latest)
-    needs: changes
-    if: ${{ !cancelled() && (needs.changes.outputs.full != 'false' || needs.changes.outputs.server != 'false' || needs.changes.outputs.hub != 'false') }}
-    runs-on: ubuntu-latest
-    steps: &server_test_steps
-      - uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: "22"
-          cache: "npm"
-
-      - name: Fetch origin/main (worktree tests)
-        if: ${{ needs.changes.outputs.full != 'false' || needs.changes.outputs.server != 'false' }}
-        run: git fetch --no-tags origin main:refs/remotes/origin/main
-
-      - name: Install dependencies
-        run: node scripts/npm-retry.mjs ci
-
-      - name: Install agent CLIs for provider tests
-        if: ${{ needs.changes.outputs.full != 'false' || needs.changes.outputs.server != 'false' }}
-        run: node scripts/npm-retry.mjs install -g @anthropic-ai/claude-code opencode-ai
-
-      - name: Build server dependencies
-        run: npm run build:server-deps
-
-      - name: Run server tests
-        if: ${{ needs.changes.outputs.full != 'false' || needs.changes.outputs.server != 'false' }}
-        run: npm run test --workspace=@getpaseo/server
-        env:
-          CLAUDE_CODE_OAUTH_TOKEN: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
-          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
-          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
-
-      - name: Run built-in plugin tests
-        if: ${{ needs.changes.outputs.full != 'false' || needs.changes.outputs.server != 'false' }}
-        run: npm run test --workspace=@getpaseo/builtin-plugins
-
-      - name: Run Hub CLI/daemon contract
-        if: ${{ needs.changes.outputs.full == 'false' && needs.changes.outputs.server == 'false' && needs.changes.outputs.hub != 'false' }}
-        run: npm run test:hub-cli-contract --workspace=@getpaseo/server
-
-  server-tests-windows:
-    name: server-tests (windows-latest)
-    needs: changes
-    if: ${{ !cancelled() && (needs.changes.outputs.full != 'false' || needs.changes.outputs.server != 'false' || needs.changes.outputs.hub != 'false') }}
-    runs-on: windows-latest
-    steps: *server_test_steps
-
-  # native-recursive.ts serves darwin and win32, but windows-latest above is the only
-  # runner that exercises it. macOS — the platform the reported watcher bug was on —
-  # otherwise has no server-test coverage. Scoped to the observer/watcher suites to
-  # bound runtime.
-  server-tests-macos:
-    name: server-tests (macos-14, file observation)
-    needs: changes
-    if: ${{ !cancelled() && (needs.changes.outputs.full != 'false' || needs.changes.outputs.server != 'false') }}
-    runs-on: macos-14
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: "22"
-          cache: "npm"
-
-      - name: Install dependencies
-        run: node scripts/npm-retry.mjs ci
-
-      - name: Build server dependencies
-        run: npm run build:server-deps
-
-      - name: Run file observation tests
-        run: |
-          npm run test:unit --workspace=@getpaseo/server -- \
-            src/server/file-observer \
-            src/server/workspace-git-service.observation.test.ts \
-            src/server/workspace-git-service.observation.integration.test.ts \
-            --bail=1
-
-  desktop-tests-ubuntu:
-    name: desktop-tests (ubuntu-latest)
-    needs: changes
-    if: ${{ !cancelled() && (needs.changes.outputs.full != 'false' || needs.changes.outputs.desktop != 'false') }}
-    runs-on: ubuntu-24.04
-    timeout-minutes: 30
-    permissions:
-      contents: read
-    steps: &desktop_test_steps
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: "22"
-          cache: "npm"
-
-      - name: Install dependencies with retry
-        run: node scripts/npm-retry.mjs ci
-
-      - name: Build server stack
-        run: npm run build:server
-
-      - name: Run desktop tests
-        run: npm run test --workspace=@getpaseo/desktop
-
-      - name: Install virtual display
-        if: ${{ runner.os == 'Linux' }}
-        run: sudo apt-get update && sudo apt-get install -y xvfb xauth xdotool
-
-      - name: Install Playwright browser
-        if: ${{ runner.os == 'Linux' }}
-        run: npx playwright install chromium
-
-      - name: Verify Windows daemon process control
-        if: ${{ runner.os == 'Windows' }}
-        run: npx vitest run packages/cli/src/commands/daemon/lifecycle.e2e.test.ts --bail=1 --maxWorkers=1 -t "Windows unbound|managed two-home"
-
-      - name: Run desktop lifecycle E2E (Linux)
-        if: ${{ runner.os == 'Linux' }}
-        run: xvfb-run -a --server-args="-screen 0 1280x800x24" npm run test:e2e:lifecycle --workspace=@getpaseo/desktop
-        env:
-          PASEO_DESKTOP_LIFECYCLE_ARTIFACT_DIR: ${{ runner.temp }}/desktop-lifecycle
-
-      - name: Upload desktop lifecycle screenshots
-        uses: actions/upload-artifact@v4
-        if: ${{ !cancelled() && runner.os == 'Linux' }}
-        with:
-          name: desktop-lifecycle
-          path: ${{ runner.temp }}/desktop-lifecycle
-          if-no-files-found: ignore
-          retention-days: 7
-
-      - name: Run desktop lifecycle E2E (Windows)
-        if: ${{ runner.os == 'Windows' }}
-        run: npm run test:e2e:lifecycle --workspace=@getpaseo/desktop
-
-      - name: Run desktop renderer E2E
-        if: ${{ runner.os == 'Linux' }}
-        run: npm run test:e2e:renderer --workspace=@getpaseo/desktop
-
-      - name: Run desktop browser E2E
-        if: ${{ runner.os == 'Linux' }}
-        run: npm run test:e2e:browser-tabs --workspace=@getpaseo/desktop
-        env:
-          PASEO_DESKTOP_BROWSER_E2E_ARTIFACT_DIR: ${{ runner.temp }}/desktop-browser-e2e
-
-      - name: Upload desktop browser diagnostics
-        uses: actions/upload-artifact@v4
-        if: ${{ failure() && runner.os == 'Linux' }}
-        with:
-          name: desktop-browser-e2e
-          path: ${{ runner.temp }}/desktop-browser-e2e
-          if-no-files-found: ignore
-          retention-days: 7
-
-  desktop-tests-windows:
-    name: desktop-tests (windows-latest)
-    needs: changes
-    if: ${{ !cancelled() && (needs.changes.outputs.full != 'false' || needs.changes.outputs.desktop != 'false') }}
-    runs-on: windows-latest
-    timeout-minutes: 30
-    permissions:
-      contents: read
-    steps: *desktop_test_steps
-
-  app-tests:
-    name: app-tests
-    needs: changes
-    if: ${{ !cancelled() && (needs.changes.outputs.full != 'false' || needs.changes.outputs.app != 'false') }}
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: "22"
-          cache: "npm"
-
-      - name: Install dependencies with retry
-        run: node scripts/npm-retry.mjs ci
-
-      - name: Install Playwright browsers
-        timeout-minutes: 10
-        run: npx playwright install chromium
-
-      - name: Build app dependencies
-        run: npm run build:app-deps
-
-      - name: Run app unit tests
-        run: npm run test --workspace=@getpaseo/app
-
-  sdk-tests:
-    name: sdk-tests
-    needs: changes
-    if: ${{ !cancelled() && (needs.changes.outputs.full != 'false' || needs.changes.outputs.sdk != 'false') }}
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: "22"
-          cache: "npm"
-
-      - name: Install dependencies
-        run: node scripts/npm-retry.mjs ci
-
-      - name: Build client dependencies
-        run: npm run build:relay && npm run build:client
-
-      - name: Build plugin SDK
-        run: npm run build:plugin
-
-      - name: Run plugin SDK tests
-        run: npm run test --workspace=@getpaseo/plugin
-
-      - name: Run protocol tests
-        run: npm run test --workspace=@getpaseo/protocol
-
-      - name: Run client tests
-        run: npm run test --workspace=@getpaseo/client
-
-      - name: Run highlight tests
-        run: npm run test --workspace=@getpaseo/highlight
-
-      - name: Typecheck client examples
-        run: npm run typecheck:examples --workspace=@getpaseo/client
-
-  playwright-1:
-    name: playwright (shard 1/4)
-    needs: changes
-    if: ${{ !cancelled() && (needs.changes.outputs.full != 'false' || needs.changes.outputs.browser != 'false') }}
-    runs-on: ubuntu-latest
-    env:
-      PLAYWRIGHT_SHARD: "1/4"
-      PLAYWRIGHT_ARTIFACT: "1"
-    steps: &playwright_test_steps
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: "22"
-          cache: "npm"
-
-      - name: Install dependencies with retry
-        run: node scripts/npm-retry.mjs ci
-
-      - name: Install Playwright browsers
-        timeout-minutes: 10
-        run: npx playwright install chromium
-
-      - name: Build server stack
-        run: npm run build:server
-
-      - name: Build native app dependency
-        run: npm run build --workspace=@getpaseo/expo-two-way-audio
-
-      - name: Install agent CLIs for provider tests
-        run: node scripts/npm-retry.mjs install -g @anthropic-ai/claude-code @openai/codex@0.105.0 opencode-ai
-
-      - name: Run Playwright E2E tests
-        run: npm run test:e2e --workspace=@getpaseo/app -- --shard=${{ env.PLAYWRIGHT_SHARD }}
-        env:
-          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
-          # Weight file groups by observed duration; raw test counts overload
-          # early agent/Changes specs. Required check names remain unchanged.
-          PWTEST_SHARD_WEIGHTS: "111:172:137:160"
-
-      - name: Upload test artifacts
-        uses: actions/upload-artifact@v4
-        if: failure()
-        with:
-          name: playwright-results-${{ env.PLAYWRIGHT_ARTIFACT }}
-          path: |
-            packages/app/test-results/
-            packages/app/playwright-report/
-          retention-days: 7
-
-  playwright-2:
-    name: playwright (shard 2/4)
-    needs: changes
-    if: ${{ !cancelled() && (needs.changes.outputs.full != 'false' || needs.changes.outputs.browser != 'false') }}
-    runs-on: ubuntu-latest
-    env:
-      PLAYWRIGHT_SHARD: "2/4"
-      PLAYWRIGHT_ARTIFACT: "2"
-    steps: *playwright_test_steps
-
-  playwright-3:
-    name: playwright (shard 3/4)
-    needs: changes
-    if: ${{ !cancelled() && (needs.changes.outputs.full != 'false' || needs.changes.outputs.browser != 'false') }}
-    runs-on: ubuntu-latest
-    env:
-      PLAYWRIGHT_SHARD: "3/4"
-      PLAYWRIGHT_ARTIFACT: "3"
-    steps: *playwright_test_steps
-
-  playwright-4:
-    name: playwright (shard 4/4)
-    needs: changes
-    if: ${{ !cancelled() && (needs.changes.outputs.full != 'false' || needs.changes.outputs.browser != 'false') }}
-    runs-on: ubuntu-latest
-    env:
-      PLAYWRIGHT_SHARD: "4/4"
-      PLAYWRIGHT_ARTIFACT: "4"
-    steps: *playwright_test_steps
-
-  relay-tests:
-    name: relay-tests
-    needs: changes
-    if: ${{ !cancelled() && (needs.changes.outputs.full != 'false' || needs.changes.outputs.relay != 'false') }}
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: "22"
-          cache: "npm"
-
-      - name: Install dependencies
-        run: node scripts/npm-retry.mjs ci
-
-      - name: Build relay
-        run: npm run build:relay
-
-      - name: Run relay tests
-        run: npm run test --workspace=@getpaseo/relay
-
-  cli-tests-1:
-    name: cli-tests (shard 1/3)
-    needs: changes
-    if: ${{ !cancelled() && (needs.changes.outputs.full != 'false' || needs.changes.outputs.cli != 'false') }}
-    runs-on: ubuntu-latest
-    env:
-      PASEO_LOCAL_SPEECH_AUTO_DOWNLOAD: "0"
-      PASEO_DICTATION_ENABLED: "0"
-      PASEO_VOICE_MODE_ENABLED: "0"
-      PASEO_CLI_TEST_SHARD: "1"
-      PASEO_CLI_TEST_SHARD_TOTAL: "3"
-    steps: &cli_test_steps
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: "22"
-          cache: "npm"
-
-      - name: Install dependencies
-        run: node scripts/npm-retry.mjs ci
-
-      - name: Install agent CLIs for provider tests
-        run: node scripts/npm-retry.mjs install -g @anthropic-ai/claude-code @openai/codex@0.105.0 opencode-ai
-
-      # The local runner builds its dependencies and shards its own E2E files.
-      - name: Run CLI E2E tests
-        run: npm run test:local --workspace=@getpaseo/cli
-
-      # Source tests do not read PASEO_CLI_TEST_SHARD. Run them once, on the
-      # shortest E2E shard, after its runner has built the server stack.
-      - name: Run CLI source tests
-        if: ${{ env.PASEO_CLI_TEST_SHARD == '3' }}
-        run: npm run test:unit --workspace=@getpaseo/cli
-
-  cli-tests-2:
-    name: cli-tests (shard 2/3)
-    needs: changes
-    if: ${{ !cancelled() && (needs.changes.outputs.full != 'false' || needs.changes.outputs.cli != 'false') }}
-    runs-on: ubuntu-latest
-    env:
-      PASEO_LOCAL_SPEECH_AUTO_DOWNLOAD: "0"
-      PASEO_DICTATION_ENABLED: "0"
-      PASEO_VOICE_MODE_ENABLED: "0"
-      PASEO_CLI_TEST_SHARD: "2"
-      PASEO_CLI_TEST_SHARD_TOTAL: "3"
-    steps: *cli_test_steps
-
-  cli-tests-3:
-    name: cli-tests (shard 3/3)
-    needs: changes
-    if: ${{ !cancelled() && (needs.changes.outputs.full != 'false' || needs.changes.outputs.cli != 'false') }}
-    runs-on: ubuntu-latest
-    env:
-      PASEO_LOCAL_SPEECH_AUTO_DOWNLOAD: "0"
-      PASEO_DICTATION_ENABLED: "0"
-      PASEO_VOICE_MODE_ENABLED: "0"
-      PASEO_CLI_TEST_SHARD: "3"
-      PASEO_CLI_TEST_SHARD_TOTAL: "3"
-    steps: *cli_test_steps

.github/workflows/deploy-app.yml

@@ -3,10 +3,10 @@ name: Deploy App
 on:
   push:
     tags:
-      - "v*"
-      - "!v*-beta.*"
-      - "app-v*"
-      - "!app-v*-beta.*"
+      - 'v*'
+      - '!v*-rc.*'
+      - 'app-v*'
+      - '!app-v*-rc.*'
   workflow_dispatch:
 
 jobs:
@@ -18,17 +18,18 @@ jobs:
 
       - uses: actions/setup-node@v4
         with:
-          node-version: "22"
-          cache: "npm"
-          registry-url: "https://npm.pkg.github.com"
-          scope: "@boudra"
+          node-version: '22'
+          cache: 'npm'
+          registry-url: 'https://npm.pkg.github.com'
+          scope: '@boudra'
 
       - name: Install dependencies
-        run: node scripts/npm-retry.mjs ci
+        run: npm install --workspace=@getpaseo/app --include-workspace-root
         env:
           NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-      - name: Build app dependencies
-        run: npm run build:app-deps
+
+      - name: Build highlight dependency
+        run: npm run build --workspace=@getpaseo/highlight
 
       - name: Typecheck
         run: npm run typecheck --workspace=@getpaseo/app

.github/workflows/deploy-relay.yml

@@ -1,8 +1,11 @@
 name: Deploy Relay
 
 on:
-  # Manual-only while relay.paseo.sh bridges traffic to the Fly deployment.
-  # A release or main push must not redeploy the temporary Cloudflare bridge.
+  push:
+    branches: [main]
+    paths:
+      - 'packages/relay/**'
+      - '.github/workflows/deploy-relay.yml'
   workflow_dispatch:
 
 jobs:
@@ -14,11 +17,11 @@ jobs:
 
       - uses: actions/setup-node@v4
         with:
-          node-version: "22"
-          cache: "npm"
+          node-version: '22'
+          cache: 'npm'
 
       - name: Install dependencies
-        run: node scripts/npm-retry.mjs ci --workspace=@getpaseo/relay --include-workspace-root
+        run: npm install --workspace=@getpaseo/relay --include-workspace-root
 
       - name: Typecheck
         run: npm run typecheck --workspace=@getpaseo/relay
@@ -27,3 +30,4 @@ jobs:
         run: cd packages/relay && npx wrangler deploy
         env:
           CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
+

.github/workflows/deploy-website.yml

@@ -4,16 +4,13 @@ on:
   push:
     branches: [main]
     paths:
-      - "CHANGELOG.md"
-      - "public-docs/**"
-      - "packages/website/**"
-      - "packages/protocol/**"
-      - "package.json"
-      - "package-lock.json"
-      - "patches/**"
-      - ".github/workflows/deploy-website.yml"
+      - 'packages/website/**'
+      - 'package.json'
+      - 'package-lock.json'
+      - 'patches/**'
+      - '.github/workflows/deploy-website.yml'
   release:
-    types: [published]
+    types: [published, edited]
   workflow_dispatch:
 
 jobs:
@@ -26,14 +23,11 @@ jobs:
 
       - uses: actions/setup-node@v4
         with:
-          node-version: "22"
-          cache: "npm"
+          node-version: '22'
+          cache: 'npm'
 
       - name: Install dependencies
-        run: node scripts/npm-retry.mjs ci --workspace=@getpaseo/website --workspace=@getpaseo/protocol --include-workspace-root
-
-      - name: Build protocol
-        run: npm run build:protocol
+        run: npm install --workspace=@getpaseo/website --include-workspace-root
 
       - name: Typecheck
         run: npm run typecheck --workspace=@getpaseo/website

.github/workflows/desktop-packages.yml

@@ -1,91 +0,0 @@
-name: Desktop Packages
-
-on:
-  push:
-    branches: [main]
-  # Packaging leaves ordinary PR CI, but a PR that changes what gets packaged
-  # or how it is smoked still proves the real artifacts before merge.
-  pull_request:
-    branches: [main]
-    paths:
-      - "packages/desktop/**"
-      - "plugins/**"
-      - "nix/**"
-      - ".github/workflows/desktop-packages.yml"
-
-concurrency:
-  group: desktop-packages-${{ github.ref }}
-  cancel-in-progress: ${{ github.event_name == 'pull_request' }}
-
-permissions:
-  contents: read
-
-env:
-  ONNXRUNTIME_NODE_INSTALL: skip
-
-jobs:
-  linux:
-    runs-on: ubuntu-24.04
-    timeout-minutes: 30
-    steps:
-      - uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4.4.0
-
-      - uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4.4.0
-        with:
-          node-version: "22"
-          cache: "npm"
-
-      - name: Install dependencies
-        run: node scripts/npm-retry.mjs ci
-
-      - name: Install package smoke dependencies
-        run: sudo apt-get update && sudo apt-get install -y xvfb xauth rpm
-
-      - name: Build Linux desktop artifacts
-        # Smoke package contents and installation without spending minutes on xz compression.
-        run: |
-          printf '{"extends":"%s/packages/desktop/electron-builder.yml","deb":{"compression":"gz"},"rpm":{"fpm":["--rpm-compression=gzip"]}}' "$GITHUB_WORKSPACE" > "$RUNNER_TEMP/desktop-smoke-builder.json"
-          npm run build:desktop -- --publish never --linux --x64 --config "$RUNNER_TEMP/desktop-smoke-builder.json"
-        env:
-          EP_GH_IGNORE_TIME: true
-          PASEO_DESKTOP_SMOKE_ARTIFACT_DIR: ${{ runner.temp }}/desktop-smoke
-
-      - name: Smoke installed artifacts with restricted user namespaces
-        run: |
-          sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=1
-          if unshare --user --map-root-user --net true; then
-            echo "Expected the launching user's namespace probe to be denied"
-            exit 1
-          fi
-          sudo apt-get install -y ./packages/desktop/release/*.deb
-          node packages/desktop/e2e/linux-artifact-smoke.js packages/desktop/release disabled
-        env:
-          PASEO_DESKTOP_SMOKE_ARTIFACT_DIR: ${{ runner.temp }}/desktop-smoke/restricted
-
-      - name: Smoke sandbox-preserving portable launches
-        run: |
-          sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
-          unshare --user --map-root-user --net true
-          node packages/desktop/e2e/linux-artifact-smoke.js packages/desktop/release enabled
-        env:
-          PASEO_DESKTOP_SMOKE_ARTIFACT_DIR: ${{ runner.temp }}/desktop-smoke/userns
-
-      - name: Smoke installed RPM with restricted user namespaces
-        run: |
-          sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=1
-          sudo dpkg --remove paseo
-          # Ubuntu supplies the runtime libraries under Debian package names.
-          # RPM still performs the real payload installation and postinstall.
-          sudo rpm --install --nodeps packages/desktop/release/*.rpm
-          node packages/desktop/e2e/linux-artifact-smoke.js packages/desktop/release disabled --installed-only
-        env:
-          PASEO_DESKTOP_SMOKE_ARTIFACT_DIR: ${{ runner.temp }}/desktop-smoke/rpm
-
-      - name: Upload packaged smoke diagnostics
-        uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
-        if: ${{ !cancelled() }}
-        with:
-          name: desktop-packaged-smoke-linux-x64
-          path: ${{ runner.temp }}/desktop-smoke
-          if-no-files-found: ignore
-          retention-days: 7

.github/workflows/desktop-release.yml

@@ -3,45 +3,27 @@ name: Desktop Release
 on:
   push:
     tags:
-      - "v*"
-      - "desktop-v*"
-      - "desktop-macos-v*"
-      - "desktop-linux-v*"
-      - "desktop-windows-v*"
+      - 'v*'
+      - 'desktop-v*'
+      - 'desktop-macos-v*'
+      - 'desktop-linux-v*'
+      - 'desktop-windows-v*'
   workflow_dispatch:
     inputs:
       tag:
-        description: "Existing tag to build (e.g. v0.1.0)"
+        description: 'Existing tag to build (e.g. v0.1.0)'
         required: true
         type: string
       platform:
-        description: "Optional desktop platform to build."
+        description: 'Optional desktop platform to build.'
         required: false
-        default: "all"
+        default: 'all'
         type: choice
         options:
           - all
           - macos
           - linux
           - windows
-      checkout_ref:
-        description: "Optional branch/ref to checkout while using tag for release metadata."
-        required: false
-        default: ""
-        type: string
-      publish:
-        description: "Publish built artifacts to GitHub Releases."
-        required: false
-        default: "true"
-        type: choice
-        options:
-          - "true"
-          - "false"
-      rollout_hours:
-        description: "Linear rollout duration in hours. Use 0 for instant rollout."
-        required: false
-        default: "36"
-        type: string
 
 concurrency:
   group: desktop-release-${{ github.ref }}
@@ -49,14 +31,12 @@ concurrency:
 
 env:
   SOURCE_TAG: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.tag || github.ref_name }}
-  CHECKOUT_REF: ${{ github.event_name == 'workflow_dispatch' && (github.event.inputs.checkout_ref || github.ref_name) || github.ref_name }}
-  SHOULD_PUBLISH: ${{ github.event_name != 'workflow_dispatch' || github.event.inputs.publish != 'false' }}
-  ROLLOUT_HOURS: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.rollout_hours || '36' }}
-  DESKTOP_PACKAGE_PATH: "packages/desktop"
+  DESKTOP_WORKSPACE: '@getpaseo/desktop'
+  DESKTOP_PACKAGE_PATH: 'packages/desktop'
 
 jobs:
   create-release:
-    if: ${{ (github.event_name == 'push' && !startsWith(github.ref_name, 'desktop-macos-v') && !startsWith(github.ref_name, 'desktop-linux-v') && !startsWith(github.ref_name, 'desktop-windows-v')) || (github.event_name == 'workflow_dispatch' && github.event.inputs.platform == 'all' && github.event.inputs.publish != 'false') }}
+    if: ${{ (github.event_name == 'push' && !startsWith(github.ref_name, 'desktop-macos-v') && !startsWith(github.ref_name, 'desktop-linux-v') && !startsWith(github.ref_name, 'desktop-windows-v')) || (github.event_name == 'workflow_dispatch' && github.event.inputs.platform == 'all') }}
     permissions:
       contents: write
     runs-on: ubuntu-latest
@@ -64,7 +44,7 @@ jobs:
       - uses: actions/checkout@v4
         with:
           sparse-checkout: scripts
-          ref: ${{ env.CHECKOUT_REF }}
+          ref: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.tag || github.ref }}
 
       - name: Resolve release metadata
         shell: bash
@@ -75,7 +55,7 @@ jobs:
         env:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         run: |
-          if node scripts/github-release.mjs --repo "${{ github.repository }}" --tag "$RELEASE_TAG" > /dev/null 2>&1; then
+          if gh release view "$RELEASE_TAG" --repo "${{ github.repository }}" > /dev/null 2>&1; then
             echo "Release $RELEASE_TAG already exists, skipping creation"
           else
             prerelease_flag=""
@@ -85,12 +65,8 @@ jobs:
             gh release create "$RELEASE_TAG" \
               --repo "${{ github.repository }}" \
               --title "Paseo $RELEASE_TAG" \
-              --notes "" \
-              --draft \
-              $prerelease_flag || {
-                echo "Release creation raced with another workflow; continuing."
-                node scripts/github-release.mjs --repo "${{ github.repository }}" --tag "$RELEASE_TAG" > /dev/null
-              }
+              --generate-notes \
+              $prerelease_flag
           fi
 
   publish-macos:
@@ -102,10 +78,8 @@ jobs:
         include:
           - runner: macos-14
             electron_arch: arm64
-            node_heap_mb: 4096
           - runner: macos-15-intel
             electron_arch: x64
-            node_heap_mb: 8192
     permissions:
       contents: write
       packages: read
@@ -115,7 +89,7 @@ jobs:
       - uses: actions/checkout@v4
         with:
           fetch-depth: 0
-          ref: ${{ env.CHECKOUT_REF }}
+          ref: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.tag || github.ref }}
 
       - name: Resolve release metadata
         shell: bash
@@ -124,14 +98,14 @@ jobs:
       - name: Setup Node
         uses: actions/setup-node@v4
         with:
-          node-version: "22"
-          cache: "npm"
+          node-version: '22'
+          cache: 'npm'
           cache-dependency-path: package-lock.json
-          registry-url: "https://npm.pkg.github.com"
-          scope: "@boudra"
+          registry-url: 'https://npm.pkg.github.com'
+          scope: '@boudra'
 
       - name: Install JS dependencies
-        run: node scripts/npm-retry.mjs ci
+        run: npm ci
         env:
           NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 
@@ -151,6 +125,9 @@ jobs:
           fs.writeFileSync(packageJsonPath, `${JSON.stringify(packageJson, null, 2)}\n`);
           NODE
 
+      - name: Build web app for desktop
+        run: npm run build:web --workspace=@getpaseo/app
+
       - name: Build desktop release
         shell: bash
         env:
@@ -161,55 +138,121 @@ jobs:
           APPLE_ID: ${{ secrets.APPLE_ID }}
           APPLE_APP_SPECIFIC_PASSWORD: ${{ secrets.APPLE_PASSWORD }}
           APPLE_TEAM_ID: ${{ secrets.APPLE_TEAM_ID }}
-          PASEO_DESKTOP_SMOKE: "1"
-          PASEO_DESKTOP_SMOKE_ARTIFACT_DIR: ${{ runner.temp }}/desktop-smoke
-          # Metro's jest workers OOM on the generated ws-outbound.aot.js validator,
-          # the last module in the web bundle. Node's default heap is sized from
-          # runner RAM, which is not enough on the Intel runner.
-          NODE_OPTIONS: --max-old-space-size=${{ matrix.node_heap_mb }}
         run: |
           set -euo pipefail
-          build_args=(-- --publish never --mac --${{ matrix.electron_arch }})
-          build_args+=("-c.publish.releaseType=$RELEASE_TYPE")
-          build_args+=("-c.publish.channel=$RELEASE_CHANNEL")
-          npm run build:desktop "${build_args[@]}"
+          publish_mode="never"
+          publish_args=()
+          if [[ "$IS_SMOKE_TAG" != "true" ]]; then
+            publish_mode="always"
+            publish_args+=("-c.publish.releaseType=$RELEASE_TYPE")
+          fi
 
-      - name: Upload packaged smoke diagnostics
-        if: failure()
-        uses: actions/upload-artifact@v4
-        with:
-          name: desktop-smoke-macos-${{ matrix.electron_arch }}
-          path: ${{ runner.temp }}/desktop-smoke
-          if-no-files-found: ignore
-          retention-days: 7
-
-      - name: Upload desktop artifacts to release
-        if: env.SHOULD_PUBLISH == 'true' && env.IS_SMOKE_TAG != 'true'
-        env:
-          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        shell: bash
-        run: |
-          set -euo pipefail
-          release_dir="${DESKTOP_PACKAGE_PATH}/release"
-          release_lookup="$(node scripts/github-release.mjs --repo "${{ github.repository }}" --tag "$RELEASE_TAG")"
-          node scripts/upload-release-assets.mjs "$release_lookup" "$release_dir" "${{ github.repository }}"
-
-      - name: Upload desktop artifacts to workflow
-        if: env.SHOULD_PUBLISH != 'true'
-        uses: actions/upload-artifact@v4
-        with:
-          name: desktop-macos-${{ matrix.electron_arch }}
-          path: ${{ env.DESKTOP_PACKAGE_PATH }}/release/*.dmg
-          retention-days: 7
+          npm run build --workspace="$DESKTOP_WORKSPACE" -- --publish "$publish_mode" --mac --${{ matrix.electron_arch }} "${publish_args[@]}"
 
       - name: Upload manifest artifact
-        if: env.SHOULD_PUBLISH == 'true' && env.IS_SMOKE_TAG != 'true'
+        if: env.IS_SMOKE_TAG != 'true'
         uses: actions/upload-artifact@v4
         with:
           name: mac-manifest-${{ matrix.electron_arch }}
-          path: ${{ env.DESKTOP_PACKAGE_PATH }}/release/${{ env.RELEASE_CHANNEL }}-mac.yml
+          path: ${{ env.DESKTOP_PACKAGE_PATH }}/release/latest-mac.yml
           retention-days: 1
 
+  finalize-mac-manifest:
+    needs: [publish-macos]
+    if: ${{ needs.publish-macos.result == 'success' }}
+    permissions:
+      contents: write
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          sparse-checkout: scripts
+          ref: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.tag || github.ref }}
+
+      - name: Resolve release tag
+        shell: bash
+        run: node scripts/emit-release-env.mjs --source-tag "$SOURCE_TAG" >> "$GITHUB_ENV"
+
+      - name: Download manifest artifacts
+        if: env.IS_SMOKE_TAG != 'true'
+        uses: actions/download-artifact@v4
+        with:
+          pattern: mac-manifest-*
+
+      - name: Merge manifests
+        if: env.IS_SMOKE_TAG != 'true'
+        shell: bash
+        run: |
+          set -euo pipefail
+
+          node <<'NODE'
+          const fs = require('node:fs');
+
+          // Simple YAML parser for electron-builder's latest-mac.yml format
+          function parseManifest(text) {
+            const lines = text.split('\n');
+            const result = { files: [] };
+            let currentFile = null;
+
+            for (const line of lines) {
+              if (line.startsWith('version:')) result.version = line.split(': ')[1].trim();
+              else if (line.startsWith('path:')) result.path = line.split(': ')[1].trim();
+              else if (line.startsWith('sha512:') && !currentFile) result.sha512 = line.split(': ')[1].trim();
+              else if (line.startsWith('releaseDate:')) result.releaseDate = line.split(': ')[1].trim().replace(/'/g, '');
+              else if (line.trim().startsWith('- url:')) {
+                currentFile = { url: line.trim().replace('- url: ', '') };
+                result.files.push(currentFile);
+              } else if (line.trim().startsWith('sha512:') && currentFile) {
+                currentFile.sha512 = line.trim().split(': ')[1].trim();
+              } else if (line.trim().startsWith('size:') && currentFile) {
+                currentFile.size = parseInt(line.trim().split(': ')[1].trim(), 10);
+                currentFile = null;
+              }
+            }
+            return result;
+          }
+
+          function toYaml(manifest) {
+            let out = `version: ${manifest.version}\n`;
+            out += `files:\n`;
+            for (const f of manifest.files) {
+              out += `  - url: ${f.url}\n`;
+              out += `    sha512: ${f.sha512}\n`;
+              out += `    size: ${f.size}\n`;
+            }
+            out += `path: ${manifest.path}\n`;
+            out += `sha512: ${manifest.sha512}\n`;
+            out += `releaseDate: '${manifest.releaseDate}'\n`;
+            return out;
+          }
+
+          const arm64Text = fs.readFileSync('mac-manifest-arm64/latest-mac.yml', 'utf8');
+          const x64Text = fs.readFileSync('mac-manifest-x64/latest-mac.yml', 'utf8');
+
+          const arm64 = parseManifest(arm64Text);
+          const x64 = parseManifest(x64Text);
+
+          // Merge: all files from both, default path points to arm64 zip
+          const merged = {
+            version: arm64.version,
+            files: [...arm64.files, ...x64.files],
+            path: arm64.path,
+            sha512: arm64.sha512,
+            releaseDate: arm64.releaseDate || x64.releaseDate,
+          };
+
+          const output = toYaml(merged);
+          fs.writeFileSync('latest-mac.yml', output);
+          console.log('Merged manifest:\n' + output);
+          NODE
+
+      - name: Upload merged manifest to release
+        if: env.IS_SMOKE_TAG != 'true'
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        run: gh release upload "$RELEASE_TAG" latest-mac.yml --clobber --repo "${{ github.repository }}"
+
   publish-linux:
     needs: [create-release]
     if: ${{ always() && (needs.create-release.result == 'success' || needs.create-release.result == 'skipped') && ((github.event_name == 'workflow_dispatch' && (github.event.inputs.platform == 'all' || github.event.inputs.platform == 'linux')) || (github.event_name == 'push' && (startsWith(github.ref_name, 'v') || startsWith(github.ref_name, 'desktop-v') || startsWith(github.ref_name, 'desktop-linux-v')))) }}
@@ -222,7 +265,7 @@ jobs:
       - uses: actions/checkout@v4
         with:
           fetch-depth: 0
-          ref: ${{ env.CHECKOUT_REF }}
+          ref: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.tag || github.ref }}
 
       - name: Resolve release metadata
         shell: bash
@@ -231,14 +274,14 @@ jobs:
       - name: Setup Node
         uses: actions/setup-node@v4
         with:
-          node-version: "22"
-          cache: "npm"
+          node-version: '22'
+          cache: 'npm'
           cache-dependency-path: package-lock.json
-          registry-url: "https://npm.pkg.github.com"
-          scope: "@boudra"
+          registry-url: 'https://npm.pkg.github.com'
+          scope: '@boudra'
 
       - name: Install JS dependencies
-        run: node scripts/npm-retry.mjs ci
+        run: npm ci
         env:
           NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 
@@ -258,58 +301,24 @@ jobs:
           fs.writeFileSync(packageJsonPath, `${JSON.stringify(packageJson, null, 2)}\n`);
           NODE
 
-      - name: Install Linux smoke display
-        run: sudo apt-get update && sudo apt-get install -y xvfb xauth rpm
+      - name: Build web app for desktop
+        run: npm run build:web --workspace=@getpaseo/app
 
       - name: Build desktop release
         shell: bash
         env:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           EP_GH_IGNORE_TIME: true
-          PASEO_DESKTOP_SMOKE: "1"
-          PASEO_DESKTOP_SMOKE_ARTIFACT_DIR: ${{ runner.temp }}/desktop-smoke
         run: |
           set -euo pipefail
-          build_args=(-- --publish never --linux --x64)
-          build_args+=("-c.publish.releaseType=$RELEASE_TYPE")
-          build_args+=("-c.publish.channel=$RELEASE_CHANNEL")
-          npm run build:desktop "${build_args[@]}"
+          publish_mode="never"
+          publish_args=()
+          if [[ "$IS_SMOKE_TAG" != "true" ]]; then
+            publish_mode="always"
+            publish_args+=("-c.publish.releaseType=$RELEASE_TYPE")
+          fi
 
-      - name: Upload packaged smoke diagnostics
-        if: always()
-        uses: actions/upload-artifact@v4
-        with:
-          name: desktop-smoke-linux-x64
-          path: ${{ runner.temp }}/desktop-smoke
-          if-no-files-found: ignore
-          retention-days: 7
-
-      - name: Upload desktop artifacts to release
-        if: env.SHOULD_PUBLISH == 'true' && env.IS_SMOKE_TAG != 'true'
-        env:
-          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        shell: bash
-        run: |
-          set -euo pipefail
-          release_dir="${DESKTOP_PACKAGE_PATH}/release"
-          release_lookup="$(node scripts/github-release.mjs --repo "${{ github.repository }}" --tag "$RELEASE_TAG")"
-          node scripts/upload-release-assets.mjs "$release_lookup" "$release_dir" "${{ github.repository }}"
-
-      - name: Upload desktop artifacts to workflow
-        if: env.SHOULD_PUBLISH != 'true'
-        uses: actions/upload-artifact@v4
-        with:
-          name: desktop-linux
-          path: ${{ env.DESKTOP_PACKAGE_PATH }}/release/*
-          retention-days: 7
-
-      - name: Upload manifest artifact
-        if: env.SHOULD_PUBLISH == 'true' && env.IS_SMOKE_TAG != 'true'
-        uses: actions/upload-artifact@v4
-        with:
-          name: linux-manifest
-          path: ${{ env.DESKTOP_PACKAGE_PATH }}/release/${{ env.RELEASE_CHANNEL }}-linux.yml
-          retention-days: 1
+          npm run build --workspace="$DESKTOP_WORKSPACE" -- --publish "$publish_mode" --linux --x64 "${publish_args[@]}"
 
   publish-windows:
     needs: [create-release]
@@ -323,7 +332,7 @@ jobs:
       - uses: actions/checkout@v4
         with:
           fetch-depth: 0
-          ref: ${{ env.CHECKOUT_REF }}
+          ref: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.tag || github.ref }}
 
       - name: Resolve release metadata
         shell: bash
@@ -332,14 +341,14 @@ jobs:
       - name: Setup Node
         uses: actions/setup-node@v4
         with:
-          node-version: "22"
-          cache: "npm"
+          node-version: '22'
+          cache: 'npm'
           cache-dependency-path: package-lock.json
-          registry-url: "https://npm.pkg.github.com"
-          scope: "@boudra"
+          registry-url: 'https://npm.pkg.github.com'
+          scope: '@boudra'
 
       - name: Install JS dependencies
-        run: node scripts/npm-retry.mjs ci
+        run: npm ci
         env:
           NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 
@@ -359,202 +368,29 @@ jobs:
           fs.writeFileSync(packageJsonPath, `${JSON.stringify(packageJson, null, 2)}\n`);
           NODE
 
+      - name: Build workspace dependencies
+        run: npm run build:workspace-deps --workspace=@getpaseo/app
+
+      - name: Build web app for desktop
+        shell: pwsh
+        run: |
+          $patchPath = (Get-Item "$env:GITHUB_WORKSPACE/scripts/metro-config-windows-loader-patch.cjs").FullName
+          $env:NODE_OPTIONS = "--require=$patchPath"
+          npx expo export --platform web
+        working-directory: packages/app
+
       - name: Build desktop release
         shell: bash
         env:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           EP_GH_IGNORE_TIME: true
-          PASEO_DESKTOP_SMOKE: "1"
-          PASEO_DESKTOP_SMOKE_ARTIFACT_DIR: ${{ runner.temp }}/desktop-smoke
         run: |
           set -euo pipefail
-          build_args=(-- --publish never --win --x64 --arm64)
-          build_args+=("-c.publish.releaseType=$RELEASE_TYPE")
-          build_args+=("-c.publish.channel=$RELEASE_CHANNEL")
-          npm run build:desktop "${build_args[@]}"
-
-      - name: Upload packaged smoke diagnostics
-        if: failure()
-        uses: actions/upload-artifact@v4
-        with:
-          name: desktop-smoke-windows-x64
-          path: ${{ runner.temp }}/desktop-smoke
-          if-no-files-found: ignore
-          retention-days: 7
-
-      - name: Upload desktop artifacts to release
-        if: env.SHOULD_PUBLISH == 'true' && env.IS_SMOKE_TAG != 'true'
-        env:
-          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        shell: bash
-        run: |
-          set -euo pipefail
-          release_dir="${DESKTOP_PACKAGE_PATH}/release"
-          release_lookup="$(node scripts/github-release.mjs --repo "${{ github.repository }}" --tag "$RELEASE_TAG")"
-          node scripts/upload-release-assets.mjs "$release_lookup" "$release_dir" "${{ github.repository }}"
-
-      - name: Upload desktop artifacts to workflow
-        if: env.SHOULD_PUBLISH != 'true'
-        uses: actions/upload-artifact@v4
-        with:
-          name: desktop-windows
-          path: ${{ env.DESKTOP_PACKAGE_PATH }}/release/*
-          retention-days: 7
-
-      - name: Upload manifest artifact
-        if: env.SHOULD_PUBLISH == 'true' && env.IS_SMOKE_TAG != 'true'
-        uses: actions/upload-artifact@v4
-        with:
-          name: windows-manifest
-          path: ${{ env.DESKTOP_PACKAGE_PATH }}/release/${{ env.RELEASE_CHANNEL }}.yml
-          retention-days: 1
-
-  finalize-rollout:
-    needs: [publish-macos, publish-linux, publish-windows]
-    if: ${{ always() && (github.event_name != 'workflow_dispatch' || github.event.inputs.publish != 'false') }}
-    permissions:
-      contents: write
-    runs-on: ubuntu-latest
-    concurrency:
-      group: desktop-rollout-${{ github.event.inputs.tag || github.ref_name }}
-      cancel-in-progress: false
-
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          sparse-checkout: |
-            package.json
-            package-lock.json
-            scripts
-          ref: ${{ env.CHECKOUT_REF }}
-
-      - name: Resolve release tag
-        shell: bash
-        run: node scripts/emit-release-env.mjs --source-tag "$SOURCE_TAG" >> "$GITHUB_ENV"
-
-      - name: Setup Node
-        uses: actions/setup-node@v4
-        with:
-          node-version: "22"
-          cache: "npm"
-          cache-dependency-path: package-lock.json
-          registry-url: "https://npm.pkg.github.com"
-          scope: "@boudra"
-
-      - name: Install JS dependencies
-        run: node scripts/npm-retry.mjs ci
-        env:
-          NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-
-      - name: Download mac manifest artifacts
-        if: env.IS_SMOKE_TAG != 'true' && needs.publish-macos.result == 'success'
-        uses: actions/download-artifact@v4
-        with:
-          pattern: mac-manifest-*
-          path: release-manifests
-
-      - name: Download Linux manifest artifact
-        if: env.IS_SMOKE_TAG != 'true' && needs.publish-linux.result == 'success'
-        uses: actions/download-artifact@v4
-        with:
-          name: linux-manifest
-          path: release-manifests/linux-manifest
-
-      - name: Download Windows manifest artifact
-        if: env.IS_SMOKE_TAG != 'true' && needs.publish-windows.result == 'success'
-        uses: actions/download-artifact@v4
-        with:
-          name: windows-manifest
-          path: release-manifests/windows-manifest
-
-      - name: Assemble manifests and publish release
-        if: env.IS_SMOKE_TAG != 'true'
-        env:
-          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        shell: bash
-        run: |
-          set -euo pipefail
-          cd release-manifests
-          manifests_dir="$PWD/final"
-          mkdir -p "$manifests_dir"
-
-          expected_manifests=(
-            "${RELEASE_CHANNEL}-mac.yml"
-            "${RELEASE_CHANNEL}-linux.yml"
-            "${RELEASE_CHANNEL}.yml"
-          )
-          release_lookup="$(node ../scripts/github-release.mjs --repo "${{ github.repository }}" --tag "$RELEASE_TAG" --cleanup-duplicates)"
-          existing_assets="$(gh release view "$release_lookup" --repo "${{ github.repository }}" --json assets --jq '.assets[].name')"
-          for manifest_name in "${expected_manifests[@]}"; do
-            if grep -Fxq "$manifest_name" <<< "$existing_assets"; then
-              case "$manifest_name" in
-                "${RELEASE_CHANNEL}-mac.yml") platform_result="${{ needs.publish-macos.result }}" ;;
-                "${RELEASE_CHANNEL}-linux.yml") platform_result="${{ needs.publish-linux.result }}" ;;
-                "${RELEASE_CHANNEL}.yml") platform_result="${{ needs.publish-windows.result }}" ;;
-              esac
-              if [[ "$platform_result" =~ ^(success|skipped)$ ]]; then
-                gh release download "$release_lookup" \
-                  --repo "${{ github.repository }}" \
-                  --pattern "$manifest_name" \
-                  --dir "$manifests_dir"
-              else
-                gh release delete-asset "$release_lookup" "$manifest_name" \
-                  --repo "${{ github.repository }}" \
-                  --yes
-              fi
-            fi
-          done
-
-          if [[ "${{ needs.publish-macos.result }}" == "success" ]]; then
-            manifest_name="${RELEASE_CHANNEL}-mac.yml"
-            node ../scripts/merge-mac-manifest.mjs \
-              "mac-manifest-arm64/${manifest_name}" \
-              "mac-manifest-x64/${manifest_name}" \
-              "$manifests_dir/${manifest_name}"
+          publish_mode="never"
+          publish_args=()
+          if [[ "$IS_SMOKE_TAG" != "true" ]]; then
+            publish_mode="always"
+            publish_args+=("-c.publish.releaseType=$RELEASE_TYPE")
           fi
 
-          if [[ "${{ needs.publish-linux.result }}" == "success" ]]; then
-            cp "linux-manifest/${RELEASE_CHANNEL}-linux.yml" "$manifests_dir/"
-          fi
-
-          if [[ "${{ needs.publish-windows.result }}" == "success" ]]; then
-            cp "windows-manifest/${RELEASE_CHANNEL}.yml" "$manifests_dir/"
-          fi
-
-          shopt -s nullglob
-          files=( "$manifests_dir"/*.yml )
-          if (( ${#files[@]} == 0 )); then
-            echo "::error::No manifest artifacts were available to publish"
-            exit 1
-          fi
-          timestamp="$(date -u +"%Y-%m-%dT%H:%M:%S.000Z")"
-          node ../scripts/stamp-rollout.mjs --release-date "$timestamp" --rollout-hours "$ROLLOUT_HOURS" "${files[@]}"
-          node ../scripts/validate-desktop-manifests.mjs \
-            --release-date "$timestamp" \
-            --rollout-hours "$ROLLOUT_HOURS" \
-            "${files[@]}"
-          gh release upload "$release_lookup" "${files[@]}" --clobber --repo "${{ github.repository }}"
-
-          failed_builds=()
-          [[ "${{ needs.publish-macos.result }}" =~ ^(success|skipped)$ ]] || failed_builds+=(macOS)
-          [[ "${{ needs.publish-linux.result }}" =~ ^(success|skipped)$ ]] || failed_builds+=(Linux)
-          [[ "${{ needs.publish-windows.result }}" =~ ^(success|skipped)$ ]] || failed_builds+=(Windows)
-          if (( ${#failed_builds[@]} > 0 )); then
-            echo "::error::Desktop builds did not complete for ${failed_builds[*]}; the release remains a draft"
-            exit 1
-          fi
-
-          missing_manifests=()
-          for manifest_name in "${expected_manifests[@]}"; do
-            [[ -f "$manifests_dir/$manifest_name" ]] || missing_manifests+=("$manifest_name")
-          done
-          if (( ${#missing_manifests[@]} > 0 )); then
-            echo "::error::Missing updater manifests: ${missing_manifests[*]}; the release remains a draft"
-            exit 1
-          fi
-
-          publish_args=(release edit "$release_lookup" --tag "$RELEASE_TAG" --draft=false --repo "${{ github.repository }}")
-          if [[ "$IS_PRERELEASE" == "true" ]]; then
-            publish_args+=(--prerelease)
-          fi
-          gh "${publish_args[@]}"
+          npm run build --workspace="$DESKTOP_WORKSPACE" -- --publish "$publish_mode" --win --x64 "${publish_args[@]}"

.github/workflows/desktop-rollout.yml

@@ -1,152 +0,0 @@
-name: Desktop Rollout
-
-on:
-  workflow_dispatch:
-    inputs:
-      tag:
-        description: "Existing release tag to re-stamp (e.g. v0.1.42)."
-        required: true
-        type: string
-      rollout_hours:
-        description: "Total rollout duration since the original release date, in hours. Use 0 to admit everyone immediately."
-        required: true
-        type: string
-
-concurrency:
-  group: desktop-rollout-${{ inputs.tag }}
-  cancel-in-progress: false
-
-env:
-  SOURCE_TAG: ${{ inputs.tag }}
-
-jobs:
-  stamp:
-    permissions:
-      contents: write
-    runs-on: ubuntu-latest
-
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          sparse-checkout: |
-            package.json
-            package-lock.json
-            scripts
-
-      - name: Resolve release metadata
-        shell: bash
-        run: node scripts/emit-release-env.mjs --source-tag "$SOURCE_TAG" >> "$GITHUB_ENV"
-
-      - name: Setup Node
-        uses: actions/setup-node@v4
-        with:
-          node-version: "22"
-          cache: "npm"
-          cache-dependency-path: package-lock.json
-          registry-url: "https://npm.pkg.github.com"
-          scope: "@boudra"
-
-      - name: Install JS dependencies
-        run: node scripts/npm-retry.mjs ci
-        env:
-          NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-
-      - name: Download release manifests
-        env:
-          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        shell: bash
-        run: |
-          set -euo pipefail
-          mkdir release-manifests
-          cd release-manifests
-          gh release download "$RELEASE_TAG" --repo "${{ github.repository }}" --pattern "${RELEASE_CHANNEL}*.yml"
-          shopt -s nullglob
-          files=( ./*.yml )
-          if (( ${#files[@]} == 0 )); then
-            echo "::error::No manifests matched ${RELEASE_CHANNEL}*.yml on $RELEASE_TAG"
-            exit 1
-          fi
-          echo "Downloaded ${#files[@]} manifest(s):"
-          printf '  %s\n' "${files[@]}"
-
-      - name: Capture before state
-        id: before
-        shell: bash
-        run: |
-          set -euo pipefail
-          cd release-manifests
-          summary=$(node -e '
-            const yaml = require("js-yaml");
-            const fs = require("fs");
-            for (const f of process.argv.slice(1)) {
-              const m = yaml.load(fs.readFileSync(f, "utf8")) ?? {};
-              console.log(`  ${f}: rolloutHours=${m.rolloutHours ?? "<unset>"} releaseDate=${m.releaseDate ?? "<unset>"}`);
-            }
-          ' ./*.yml)
-          echo "$summary"
-          {
-            echo "summary<<EOF"
-            echo "$summary"
-            echo "EOF"
-          } >> "$GITHUB_OUTPUT"
-
-      - name: Re-stamp rolloutHours
-        env:
-          NEW_HOURS: ${{ inputs.rollout_hours }}
-        shell: bash
-        run: |
-          set -euo pipefail
-          cd release-manifests
-          node ../scripts/stamp-rollout.mjs --rollout-hours "$NEW_HOURS" ./*.yml
-
-      - name: Validate rewritten manifests
-        env:
-          EXPECTED: ${{ inputs.rollout_hours }}
-        shell: bash
-        run: |
-          set -euo pipefail
-          cd release-manifests
-          node -e '
-            const yaml = require("js-yaml");
-            const fs = require("fs");
-            const expected = Number(process.env.EXPECTED);
-            if (!Number.isFinite(expected) || expected < 0) {
-              throw new Error(`EXPECTED must be a non-negative number, got ${process.env.EXPECTED}`);
-            }
-            for (const f of process.argv.slice(1)) {
-              const m = yaml.load(fs.readFileSync(f, "utf8")) ?? {};
-              if (m.rolloutHours !== expected) {
-                throw new Error(`${f}: rolloutHours=${m.rolloutHours}, expected ${expected}`);
-              }
-              if (typeof m.version !== "string" || m.version.length === 0) {
-                throw new Error(`${f}: missing or invalid version`);
-              }
-            }
-          ' ./*.yml
-
-      - name: Upload to release
-        env:
-          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        shell: bash
-        run: |
-          set -euo pipefail
-          cd release-manifests
-          gh release upload "$RELEASE_TAG" ./*.yml --clobber --repo "${{ github.repository }}"
-
-      - name: Write summary
-        env:
-          BEFORE: ${{ steps.before.outputs.summary }}
-        shell: bash
-        run: |
-          {
-            echo "## Rollout updated"
-            echo ""
-            echo "**Tag:** \`$RELEASE_TAG\`"
-            echo "**Channel:** \`$RELEASE_CHANNEL\`"
-            echo "**New rolloutHours:** \`${{ inputs.rollout_hours }}\`"
-            echo ""
-            echo "### Before"
-            echo '```'
-            echo "$BEFORE"
-            echo '```'
-          } >> "$GITHUB_STEP_SUMMARY"

.github/workflows/docker.yml

@@ -1,169 +0,0 @@
-name: Docker
-
-on:
-  push:
-    branches: [main]
-    tags:
-      - "v*"
-  workflow_dispatch:
-    inputs:
-      paseo_version:
-        description: "Expected source version to build. Required when publish is true."
-        required: false
-        default: ""
-      publish:
-        description: "Publish the image to GHCR. Manual publishes require paseo_version."
-        required: false
-        default: "false"
-        type: choice
-        options:
-          - "false"
-          - "true"
-      publish_latest:
-        description: "Also publish ghcr.io/getpaseo/paseo:latest. Ignored for prereleases."
-        required: false
-        default: "false"
-        type: choice
-        options:
-          - "false"
-          - "true"
-
-concurrency:
-  group: docker-${{ github.workflow }}-${{ github.ref }}
-  cancel-in-progress: false
-
-env:
-  REGISTRY: ghcr.io
-  PLATFORMS: linux/amd64,linux/arm64
-
-jobs:
-  setup:
-    runs-on: ubuntu-latest
-    outputs:
-      image: ${{ steps.values.outputs.image }}
-      install_version: ${{ steps.values.outputs.install_version }}
-      publish: ${{ steps.values.outputs.publish }}
-      check_tag: ${{ steps.values.outputs.check_tag }}
-      publish_tags: ${{ steps.values.outputs.publish_tags }}
-    steps:
-      - uses: actions/checkout@v6
-
-      - id: values
-        env:
-          INPUT_PASEO_VERSION: ${{ inputs.paseo_version }}
-          INPUT_PUBLISH: ${{ inputs.publish }}
-          INPUT_PUBLISH_LATEST: ${{ inputs.publish_latest }}
-          REPO_OWNER: ${{ github.repository_owner }}
-          REF_NAME: ${{ github.ref_name }}
-        run: |
-          set -euo pipefail
-
-          owner="$(printf '%s' "${REPO_OWNER}" | tr '[:upper:]' '[:lower:]')"
-          image="ghcr.io/${owner}/paseo"
-          package_version="$(node -p "require('./package.json').version")"
-          install_version="${INPUT_PASEO_VERSION:-${package_version}}"
-          publish=false
-          publish_latest=false
-          prerelease=false
-
-          if [[ "${GITHUB_REF}" == refs/tags/v* ]]; then
-            install_version="${REF_NAME#v}"
-            publish=true
-            if [[ "${REF_NAME}" == *-* ]]; then
-              prerelease=true
-            else
-              publish_latest=true
-            fi
-          elif [[ "${GITHUB_EVENT_NAME}" == "workflow_dispatch" ]]; then
-            if [[ "${INPUT_PUBLISH:-false}" == "true" ]]; then
-              if [[ -z "${INPUT_PASEO_VERSION}" || "${INPUT_PASEO_VERSION}" == "latest" ]]; then
-                echo "::error::paseo_version is required for manual Docker publishes."
-                exit 1
-              fi
-              publish=true
-            fi
-
-            if [[ "${install_version}" == *-* ]]; then
-              prerelease=true
-            fi
-
-            if [[ "${INPUT_PUBLISH_LATEST:-false}" == "true" && "${prerelease}" != "true" ]]; then
-              publish_latest=true
-            fi
-          fi
-
-          check_tag="${image}:check-${GITHUB_SHA::12}"
-          publish_tags="${image}:${install_version}"
-          if [[ "${publish_latest}" == "true" ]]; then
-            publish_tags="${publish_tags}"$'\n'"${image}:latest"
-          fi
-
-          {
-            echo "image=${image}"
-            echo "install_version=${install_version}"
-            echo "publish=${publish}"
-            echo "check_tag=${check_tag}"
-            echo "publish_tags<<EOF"
-            echo "${publish_tags}"
-            echo "EOF"
-          } >> "$GITHUB_OUTPUT"
-
-          echo "Resolved image=${image} install_version=${install_version} publish=${publish}"
-
-  build:
-    needs: setup
-    if: needs.setup.outputs.publish != 'true'
-    runs-on: ubuntu-latest
-    permissions:
-      contents: read
-    steps:
-      - uses: actions/checkout@v6
-
-      - uses: docker/setup-qemu-action@v4
-      - uses: docker/setup-buildx-action@v4
-
-      - uses: docker/build-push-action@v7
-        with:
-          context: .
-          file: docker/base/Dockerfile
-          platforms: ${{ env.PLATFORMS }}
-          build-args: |
-            PASEO_VERSION=${{ needs.setup.outputs.install_version }}
-          tags: ${{ needs.setup.outputs.check_tag }}
-          push: false
-          provenance: false
-          cache-from: type=gha,scope=paseo
-          cache-to: type=gha,scope=paseo,mode=max
-
-  publish:
-    needs: setup
-    if: needs.setup.outputs.publish == 'true'
-    runs-on: ubuntu-latest
-    permissions:
-      contents: read
-      packages: write
-    steps:
-      - uses: actions/checkout@v6
-
-      - uses: docker/setup-qemu-action@v4
-      - uses: docker/setup-buildx-action@v4
-
-      - name: Log in to GHCR
-        uses: docker/login-action@v4
-        with:
-          registry: ${{ env.REGISTRY }}
-          username: ${{ github.actor }}
-          password: ${{ secrets.GITHUB_TOKEN }}
-
-      - uses: docker/build-push-action@v7
-        with:
-          context: .
-          file: docker/base/Dockerfile
-          platforms: ${{ env.PLATFORMS }}
-          build-args: |
-            PASEO_VERSION=${{ needs.setup.outputs.install_version }}
-          tags: ${{ needs.setup.outputs.publish_tags }}
-          push: true
-          provenance: false
-          cache-from: type=gha,scope=paseo
-          cache-to: type=gha,scope=paseo,mode=max

.github/workflows/fix-nix-hash.yml

@@ -0,0 +1,45 @@
+name: Fix Nix hash
+
+on:
+  push:
+    branches: [main]
+    paths:
+      - 'package.json'
+      - 'package-lock.json'
+  pull_request:
+    paths:
+      - 'package.json'
+      - 'package-lock.json'
+
+permissions:
+  contents: write
+
+jobs:
+  fix-nix-hash:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          ref: ${{ github.head_ref || github.ref }}
+          token: ${{ secrets.GITHUB_TOKEN }}
+
+      - uses: actions/setup-node@v4
+        with:
+          node-version: '22'
+          cache: 'npm'
+
+      - uses: cachix/install-nix-action@v31
+        with:
+          nix_path: nixpkgs=channel:nixos-unstable
+
+      - name: Fix lockfile and update hash
+        run: ./scripts/update-nix.sh
+
+      - name: Commit changes
+        run: |
+          git diff --quiet package-lock.json nix/package.nix && exit 0
+          git config user.name "github-actions[bot]"
+          git config user.email "github-actions[bot]@users.noreply.github.com"
+          git add package-lock.json nix/package.nix
+          git commit -m "fix: update lockfile signatures and Nix hash"
+          git push

.github/workflows/nix-build.yml

@@ -0,0 +1,59 @@
+name: Nix Build
+
+on:
+  push:
+    branches: [main]
+    paths:
+      - 'nix/**'
+      - 'flake.nix'
+      - 'flake.lock'
+      - 'package.json'
+      - 'package-lock.json'
+      - 'packages/highlight/**'
+      - 'packages/server/**'
+      - 'packages/relay/**'
+      - 'packages/cli/**'
+  pull_request:
+    branches: [main]
+    paths:
+      - 'nix/**'
+      - 'flake.nix'
+      - 'flake.lock'
+      - 'package.json'
+      - 'package-lock.json'
+      - 'packages/highlight/**'
+      - 'packages/server/**'
+      - 'packages/relay/**'
+      - 'packages/cli/**'
+
+permissions:
+  contents: read
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    continue-on-error: false
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: cachix/install-nix-action@v31
+        with:
+          nix_path: nixpkgs=channel:nixos-unstable
+
+      - name: Build Nix package
+        run: nix build .#default -o result
+
+      - name: Verify lockfile is complete
+        # npm silently omits resolved/integrity fields in workspace monorepos.
+        # Nix needs them for offline builds. See https://github.com/npm/cli/issues/4460
+        run: |
+          node scripts/fix-lockfile.mjs package-lock.json
+          git diff --exit-code package-lock.json || {
+            echo "ERROR: package-lock.json has missing resolved/integrity fields."
+            echo "This is a known npm bug: https://github.com/npm/cli/issues/4460"
+            echo "Run 'node scripts/fix-lockfile.mjs' and commit the result."
+            exit 1
+          }
+
+      - name: Check npmDepsHash is up to date
+        run: ./scripts/update-nix.sh --check

.github/workflows/nix-update-hash.yml

@@ -1,61 +0,0 @@
-name: Nix Update Hash
-
-on:
-  push:
-    branches: [main]
-    paths:
-      - "nix/**"
-      - "flake.nix"
-      - "flake.lock"
-      - "package.json"
-      - "package-lock.json"
-      - "packages/highlight/**"
-      - "packages/plugin/**"
-      - "packages/server/**"
-      - "packages/relay/**"
-      - "packages/cli/**"
-      - "scripts/update-nix.sh"
-      - "scripts/fix-lockfile.mjs"
-      - ".github/workflows/nix-update-hash.yml"
-
-permissions:
-  contents: read
-
-jobs:
-  update-hash:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/create-github-app-token@v1
-        id: app-token
-        with:
-          app-id: ${{ secrets.PASEO_BOT_APP_ID }}
-          private-key: ${{ secrets.PASEO_BOT_APP_PRIVATE_KEY }}
-
-      - uses: actions/checkout@v4
-        with:
-          ref: ${{ github.ref }}
-          token: ${{ steps.app-token.outputs.token }}
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: "22"
-          cache: "npm"
-
-      - uses: cachix/install-nix-action@v31
-        with:
-          nix_path: nixpkgs=channel:nixos-unstable
-
-      - name: Update lockfile + Nix hash if stale
-        run: ./scripts/update-nix.sh
-
-      - name: Build Nix package
-        run: nix build .#default -o result
-
-      - name: Commit hash/lockfile updates
-        run: |
-          git diff --quiet package-lock.json nix/npm-deps.hash && exit 0
-          git config user.name "paseo-ai[bot]"
-          git config user.email "266920839+paseo-ai[bot]@users.noreply.github.com"
-          git add package-lock.json nix/npm-deps.hash
-          git commit -m "fix: update lockfile signatures and Nix hash [skip ci]"
-          git push

.github/workflows/nix.yml

@@ -1,123 +0,0 @@
-name: Nix
-
-on:
-  push:
-    branches: [main]
-
-permissions:
-  contents: read
-
-jobs:
-  build:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: "22"
-          cache: "npm"
-
-      - uses: cachix/install-nix-action@v31
-        with:
-          nix_path: nixpkgs=channel:nixos-unstable
-
-      - name: Update lockfile + Nix hash if stale
-        run: ./scripts/update-nix.sh
-
-      - name: Build Nix package
-        run: nix build .#default -o result
-
-      - name: Smoke Nix daemon
-        run: |
-          set -euo pipefail
-
-          export PASEO_HOME
-          PASEO_HOME="$(mktemp -d)"
-          export PASEO_LISTEN=127.0.0.1:6767
-
-          WRAPPER_LOG="$PASEO_HOME/paseo-cli.log"
-
-          cleanup() {
-            if [[ -n "${DAEMON_PID:-}" ]] && kill -0 "$DAEMON_PID" 2>/dev/null; then
-              kill "$DAEMON_PID"
-              wait "$DAEMON_PID" || true
-            fi
-            rm -rf "$PASEO_HOME"
-          }
-          trap cleanup EXIT
-
-          PASEO_WEB_UI_ENABLED=true PASEO_RELAY_ENABLED=false ./result/bin/paseo daemon run >"$WRAPPER_LOG" 2>&1 &
-          DAEMON_PID=$!
-
-          deadline=$((SECONDS + 30))
-          while (( SECONDS < deadline )); do
-            if STATUS_JSON="$(./result/bin/paseo daemon status --json)" \
-              && jq -e '.connectedDaemon == "reachable"' <<<"$STATUS_JSON" >/dev/null; then
-              echo "$STATUS_JSON"
-              curl --fail --silent --show-error http://127.0.0.1:6767/ >"$PASEO_HOME/web-ui.html"
-              [[ -s "$PASEO_HOME/web-ui.html" ]]
-              if ! TERMINAL_JSON="$(./result/bin/paseo terminal create --cwd "$PASEO_HOME" --name nix-smoke --json)"; then
-                break
-              fi
-              TERMINAL_ID="$(jq -er '.id' <<<"$TERMINAL_JSON")"
-              ./result/bin/paseo terminal send-keys "$TERMINAL_ID" 'PATH= "$PASEO_HOOK_CLI" --version && printf "nix-terminal-%s\n" ok' Enter
-              deadline=$((SECONDS + 15))
-              while (( SECONDS < deadline )); do
-                if ./result/bin/paseo terminal capture "$TERMINAL_ID" --json \
-                  | jq -e '.lines | any(. == "nix-terminal-ok")' >/dev/null; then
-                  ./result/bin/paseo terminal kill "$TERMINAL_ID"
-                  exit 0
-                fi
-                sleep 1
-              done
-              echo "Nix terminal did not execute the command."
-              break
-            fi
-
-            if ! kill -0 "$DAEMON_PID" 2>/dev/null; then
-              echo "Nix daemon exited before becoming reachable."
-              break
-            fi
-
-            sleep 1
-          done
-
-          echo "::group::daemon.log"
-          cat "$PASEO_HOME/daemon.log" 2>/dev/null || echo "<missing>"
-          echo "::endgroup::"
-
-          echo "::group::paseo daemon run stdout/stderr"
-          cat "$WRAPPER_LOG" 2>/dev/null || echo "<missing>"
-          echo "::endgroup::"
-
-          echo "::group::paseo daemon status"
-          ./result/bin/paseo daemon status || true
-          echo "::endgroup::"
-
-          exit 1
-
-      - name: Build Nix desktop package
-        run: nix build .#desktop -o result-desktop
-
-  build-desktop-darwin:
-    runs-on: macos-14
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: cachix/install-nix-action@v31
-        with:
-          nix_path: nixpkgs=channel:nixos-unstable
-
-      - name: Build Nix desktop package
-        run: nix build .#desktop -o result-desktop
-
-      - name: Verify macOS application bundle
-        run: |
-          set -euo pipefail
-
-          app="result-desktop/Applications/Paseo.app"
-          test -x "$app/Contents/MacOS/Paseo"
-          test -L result-desktop/bin/paseo-desktop
-          test "$(/usr/libexec/PlistBuddy -c 'Print :CFBundleIdentifier' "$app/Contents/Info.plist")" = "sh.paseo.desktop"
-          find "$app" -name Info.plist -print0 | xargs -0 -n 1 plutil -lint

.github/workflows/release-notes-sync.yml

@@ -15,7 +15,7 @@ on:
         required: false
         type: string
       create_if_missing:
-        description: "Create a draft release if missing (normally only needed for tag events)."
+        description: "Create release if missing (normally only needed for tag events)."
         required: false
         default: false
         type: boolean
@@ -29,6 +29,7 @@ jobs:
     runs-on: ubuntu-latest
     permissions:
       contents: write
+
     steps:
       - uses: actions/checkout@v4
         with:
@@ -53,7 +54,7 @@ jobs:
           fi
 
           create_if_missing="false"
-          if [[ "$EVENT_NAME" = "push" && "$REF" == refs/tags/v* ]]; then
+          if [ "$EVENT_NAME" = "push" ] && [[ "$REF" == refs/tags/v* ]]; then
             create_if_missing="true"
           elif [ "$EVENT_NAME" = "workflow_dispatch" ] && [ "${INPUT_CREATE_IF_MISSING:-false}" = "true" ]; then
             create_if_missing="true"

.github/workflows/server-ci.yml

@@ -0,0 +1,52 @@
+name: Server CI
+
+on:
+  push:
+    branches: [main]
+    paths:
+      - 'packages/server/**'
+      - 'package.json'
+      - 'package-lock.json'
+      - '.github/workflows/server-ci.yml'
+  pull_request:
+    branches: [main]
+    paths:
+      - 'packages/server/**'
+      - 'package.json'
+      - 'package-lock.json'
+      - '.github/workflows/server-ci.yml'
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - uses: actions/setup-node@v4
+        with:
+          node-version: '20'
+          cache: 'npm'
+
+      - name: Fetch origin/main (worktree tests)
+        run: git fetch --no-tags origin main:refs/remotes/origin/main
+
+      - name: Install server dependencies
+        run: npm install --workspace=@getpaseo/server --include-workspace-root
+
+      - name: Build highlight dependency
+        run: npm run build --workspace=@getpaseo/highlight
+
+      - name: Build relay dependency
+        run: npm run build --workspace=@getpaseo/relay
+
+      - name: Typecheck
+        run: npm run typecheck --workspace=@getpaseo/server
+
+      - name: Test
+        run: npm run test --workspace=@getpaseo/server
+        env:
+          CLAUDE_CODE_OAUTH_TOKEN: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
+          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

.gitignore

@@ -6,7 +6,6 @@ build/
 dist/
 .next/
 out/
-result
 
 # Environment variables
 .env
@@ -14,8 +13,6 @@ result
 .env.local
 .env.test.local
 .env*.local
-.dev.vars
-**/.dev.vars
 
 # Logs
 *.log
@@ -64,11 +61,9 @@ CLAUDE.local.md
 
 .debug.conversations/
 .debug/
-.dev/
 .paseo/
 .wrangler/
 **/.wrangler/
-**/.tanstack/
 
 # Local agent/tooling artifacts (do not commit)
 PLAN.md
@@ -84,12 +79,7 @@ valknut-report.json/
 .plans/
 packages/server/src/server/fixtures/dictation/dictation-debug-largest.wav
 packages/server/src/server/fixtures/dictation/dictation-debug-largest.transcript.txt
-packages/protocol/src/generated/validation/*.aot.ts
 
 /artifacts
 packages/desktop/.cache/
 packages/desktop/src-tauri/resources/managed-runtime/
-app.json
-
-# Heap snapshots dumped by --heapsnapshot-near-heap-limit; keep them for debugging.
-*.heapsnapshot

.mise.toml

@@ -1,10 +1,9 @@
-[vars]
-android_sdk_version = '{{ read_file(path=".tool-versions") | split(pat="android-sdk") | last | trim | split(pat="\n") | first | trim }}'
-
 [env]
-ANDROID_HOME = "{{ env.HOME }}/.local/share/mise/installs/android-sdk/{{ vars.android_sdk_version }}"
+ANDROID_HOME = "{{env.HOME}}/.local/share/mise/installs/android-sdk/1.0"
 _.path = [
-  "{{ env.HOME }}/.local/share/mise/installs/android-sdk/{{ vars.android_sdk_version }}/cmdline-tools/{{ vars.android_sdk_version }}/bin",
-  "{{ env.HOME }}/.local/share/mise/installs/android-sdk/{{ vars.android_sdk_version }}/platform-tools",
-  "{{ env.HOME }}/.local/share/mise/installs/android-sdk/{{ vars.android_sdk_version }}/emulator",
+  "{{env.HOME}}/.local/share/mise/installs/android-sdk/1.0/platform-tools",
+  "{{env.HOME}}/.local/share/mise/installs/android-sdk/1.0/emulator",
 ]
+
+[tools]
+java = "17"

.oxfmtrc.json

@@ -1,15 +0,0 @@
-{
-  "$schema": "./node_modules/oxfmt/configuration_schema.json",
-  "useTabs": false,
-  "tabWidth": 2,
-  "printWidth": 100,
-  "singleQuote": false,
-  "jsxSingleQuote": false,
-  "quoteProps": "as-needed",
-  "trailingComma": "all",
-  "semi": true,
-  "arrowParens": "always",
-  "bracketSameLine": false,
-  "bracketSpacing": true,
-  "ignorePatterns": ["*.lock", "**/*.gen.ts", "**/*.gen.tsx"]
-}

.oxlintrc.json

@@ -1,367 +0,0 @@
-{
-  "$schema": "./node_modules/oxlint/configuration_schema.json",
-  "options": {
-    "typeAware": false
-  },
-  "ignorePatterns": [".dev/**"],
-  "plugins": ["react", "react-perf", "unicorn", "typescript", "oxc", "import", "promise"],
-  "categories": {
-    "correctness": "error",
-    "suspicious": "error",
-    "perf": "error"
-  },
-  "rules": {
-    "react/react-in-jsx-scope": "off",
-
-    "no-await-in-loop": "off",
-
-    "no-unused-expressions": "error",
-    "no-useless-catch": "error",
-    "preserve-caught-error": "error",
-    "require-await": "off",
-    "no-async-promise-executor": "error",
-    "no-useless-escape": "error",
-    "no-empty-pattern": "error",
-    "no-self-assign": "error",
-    "no-shadow": "error",
-    "unicorn/consistent-function-scoping": "off",
-    "unicorn/no-array-sort": "off",
-
-    "unicorn/no-useless-spread": "error",
-    "unicorn/no-useless-fallback-in-spread": "error",
-    "unicorn/no-new-array": "error",
-    "unicorn/no-empty-file": "error",
-
-    "promise/always-return": "error",
-    "promise/no-multiple-resolved": "error",
-
-    "react/no-array-index-key": "error",
-    "react/jsx-no-useless-fragment": "error",
-    "react/jsx-no-constructed-context-values": "error",
-    "react/no-unescaped-entities": "error",
-    "react/button-has-type": "error",
-    "react/jsx-max-depth": ["error", { "max": 6 }],
-
-    "react-hooks/rules-of-hooks": "error",
-    "react-hooks/exhaustive-deps": "error",
-
-    "react-perf/jsx-no-new-array-as-prop": "error",
-    "react-perf/jsx-no-new-function-as-prop": "error",
-    "react-perf/jsx-no-new-object-as-prop": "error",
-    "react-perf/jsx-no-jsx-as-prop": "error",
-
-    "oxc/no-map-spread": "error",
-    "oxc/no-async-endpoint-handlers": "error",
-    "oxc/only-used-in-recursion": "error",
-
-    "typescript/no-explicit-any": "error",
-    "typescript/prefer-as-const": "error",
-    "typescript/no-this-alias": "error",
-    "typescript/no-unnecessary-type-assertion": "error",
-    "typescript/consistent-type-definitions": ["error", "interface"],
-
-    "import/no-unassigned-import": [
-      "error",
-      {
-        "allow": [
-          "**/*.css",
-          "**/expo-router/entry",
-          "**/event-target-polyfill",
-          "**/dotenv/config",
-          "**/react-native",
-          "**/@/styles/unistyles",
-          "**/src/styles/unistyles",
-          "**/@/test/window-local-storage"
-        ]
-      }
-    ],
-
-    "no-nested-ternary": "error",
-    "no-unneeded-ternary": "error",
-
-    "complexity": ["error", { "max": 20 }],
-    "max-depth": ["error", { "max": 4 }],
-    "max-nested-callbacks": ["error", { "max": 3 }]
-  },
-  "overrides": [
-    {
-      "files": [
-        "plugins/*-provider/server/**/*.ts",
-        "packages/plugin/src/server/acp-internal/**/*.ts"
-      ],
-      "rules": {
-        "no-restricted-imports": [
-          "error",
-          {
-            "paths": [
-              {
-                "name": "node:child_process",
-                "importNames": [
-                  "spawn",
-                  "exec",
-                  "execFile",
-                  "spawnSync",
-                  "execSync",
-                  "execFileSync"
-                ],
-                "message": "Use the plugin server process helpers so Windows command scripts and argv are handled consistently."
-              },
-              {
-                "name": "child_process",
-                "importNames": [
-                  "spawn",
-                  "exec",
-                  "execFile",
-                  "spawnSync",
-                  "execSync",
-                  "execFileSync"
-                ],
-                "message": "Use the plugin server process helpers so Windows command scripts and argv are handled consistently."
-              }
-            ]
-          }
-        ]
-      }
-    },
-    {
-      "files": ["packages/app/src/**/*.{ts,tsx}"],
-      "rules": {
-        // React Native style arrays must read Unistyles proxies during render. Hoisting them to
-        // satisfy this allocation rule captures the temporary startup theme instead.
-        "react-perf/jsx-no-new-array-as-prop": "off",
-        "no-restricted-imports": [
-          "error",
-          {
-            "paths": [
-              {
-                "name": "react-native",
-                "importNames": ["TextInput"],
-                "message": "Use EditingTextInput from @/components/ui/text-input. Raw TextInput bypasses editing-surface authority and IME safety."
-              },
-              {
-                "name": "@tanstack/react-query",
-                "importNames": ["useQuery", "useInfiniteQuery", "useQueries"],
-                "message": "App reads must go through useReplicaQuery/useFetchQuery from @/data/query. Grandfathered files may only leave the override burn-down list."
-              },
-              {
-                "name": "react-native-unistyles",
-                "importNames": ["useUnistyles"],
-                "message": "useUnistyles is banned by docs/unistyles.md. Grandfathered files may only leave the override burn-down list."
-              }
-            ]
-          }
-        ]
-      }
-    },
-    {
-      "files": [
-        "packages/app/src/data/**/*.{ts,tsx}",
-        "packages/app/src/**/*.test.{ts,tsx}",
-        "packages/app/src/**/*.spec.{ts,tsx}"
-      ],
-      "rules": {
-        "no-restricted-imports": [
-          "error",
-          {
-            "paths": [
-              {
-                "name": "react-native",
-                "importNames": ["TextInput"],
-                "message": "Use EditingTextInput from @/components/ui/text-input. Raw TextInput bypasses editing-surface authority and IME safety."
-              },
-              {
-                "name": "react-native-unistyles",
-                "importNames": ["useUnistyles"],
-                "message": "useUnistyles is banned by docs/unistyles.md. Grandfathered files may only leave the override burn-down list."
-              }
-            ]
-          }
-        ]
-      }
-    },
-    // Raw query burn-down: 34 files total; the 28 files below still enforce the useUnistyles ban.
-    {
-      "files": [
-        "packages/app/src/assistant-file-links/use-file-link.ts",
-        "packages/app/src/components/message.tsx",
-        "packages/app/src/components/worktree-setup-callout-source.tsx",
-        "packages/app/src/desktop/hooks/use-daemon-status.ts",
-        "packages/app/src/desktop/hooks/use-install-status.ts",
-        "packages/app/src/desktop/settings/desktop-settings.ts",
-        "packages/app/src/git/pull-request-panel/use-data.ts",
-        "packages/app/src/git/use-github-search-query.ts",
-        "packages/app/src/git/use-pr-status-query.ts",
-        "packages/app/src/git/use-status-query.ts",
-        "packages/app/src/hooks/use-archive-agent.ts",
-        "packages/app/src/hooks/use-agent-autocomplete.ts",
-        "packages/app/src/hooks/use-agent-commands-query.ts",
-        "packages/app/src/hooks/use-agent-history.ts",
-        "packages/app/src/hooks/use-branch-switcher.ts",
-        "packages/app/src/hooks/use-changes-preferences/index.ts",
-        "packages/app/src/hooks/use-draft-agent-features.ts",
-        "packages/app/src/hooks/use-form-preferences.ts",
-        "packages/app/src/hooks/use-is-local-daemon.ts",
-        "packages/app/src/hooks/use-keyboard-shortcut-overrides.ts",
-        "packages/app/src/hooks/use-preferred-editor.ts",
-        "packages/app/src/hooks/use-settings/index.ts",
-        "packages/app/src/panels/terminal-panel.tsx",
-        "packages/app/src/projects/icons.ts",
-        "packages/app/src/provider-usage/use-provider-usage.ts",
-        "packages/app/src/screens/project-settings-screen.tsx",
-        "packages/app/src/screens/workspace/use-workspace-checkout-status.ts",
-        "packages/app/src/workspace/desktop-open-targets.ts"
-      ],
-      "rules": {
-        "no-restricted-imports": [
-          "error",
-          {
-            "paths": [
-              {
-                "name": "react-native",
-                "importNames": ["TextInput"],
-                "message": "Use EditingTextInput from @/components/ui/text-input. Raw TextInput bypasses editing-surface authority and IME safety."
-              },
-              {
-                "name": "react-native-unistyles",
-                "importNames": ["useUnistyles"],
-                "message": "useUnistyles is banned by docs/unistyles.md. Grandfathered files may only leave the override burn-down list."
-              }
-            ]
-          }
-        ]
-      }
-    },
-    // useUnistyles burn-down: 74 files total; the 68 files below still enforce the raw-query ban.
-    {
-      "files": [
-        "packages/app/src/app/_layout.tsx",
-        "packages/app/src/app/pair-scan.tsx",
-        "packages/app/src/components/adaptive-modal-sheet.tsx",
-        "packages/app/src/components/add-host-method-modal.tsx",
-        "packages/app/src/components/add-host-modal.tsx",
-        "packages/app/src/components/agent-list.tsx",
-        "packages/app/src/components/agent-status-dot.tsx",
-        "packages/app/src/components/attachment-lightbox.tsx",
-        "packages/app/src/desktop/browser/pane/index.electron.tsx",
-        "packages/app/src/desktop/browser/pane/index.tsx",
-        "packages/app/src/desktop/browser/pane/index.web.tsx",
-        "packages/app/src/components/command-center.tsx",
-        "packages/app/src/components/compact-explorer-sidebar.tsx",
-        "packages/app/src/components/context-window-meter.tsx",
-        "packages/app/src/components/dictation-controls.tsx",
-        "packages/app/src/components/download-toast.tsx",
-        "packages/app/src/components/draggable-list.native.tsx",
-        "packages/app/src/components/headers/back-header.tsx",
-        "packages/app/src/components/headers/menu-header.tsx",
-        "packages/app/src/components/headers/screen-header.tsx",
-        "packages/app/src/components/host-status-dot.tsx",
-        "packages/app/src/components/hosts/host-picker.tsx",
-        "packages/app/src/components/icons/paseo-logo.tsx",
-        "packages/app/src/components/left-sidebar.tsx",
-        "packages/app/src/components/pair-link-modal.tsx",
-        "packages/app/src/components/plan-card.tsx",
-        "packages/app/src/components/provider-diagnostic-sheet.tsx",
-        "packages/app/src/components/question-form-card.tsx",
-        "packages/app/src/components/quitting-overlay.tsx",
-        "packages/app/src/components/realtime-voice-overlay.tsx",
-        "packages/app/src/components/resize-handle.tsx",
-        "packages/app/src/components/rewind/rewind-menu.tsx",
-        "packages/app/src/components/settings-textarea.tsx",
-        "packages/app/src/components/sidebar-callout.tsx",
-        "packages/app/src/components/split-container.tsx",
-        "packages/app/src/components/split-drop-zone.tsx",
-        "packages/app/src/components/terminal-pane.tsx",
-        "packages/app/src/components/toast-host.tsx",
-        "packages/app/src/components/tool-call-sheet.tsx",
-        "packages/app/src/components/ui/alert.tsx",
-        "packages/app/src/components/ui/autocomplete.tsx",
-        "packages/app/src/components/ui/combobox.tsx",
-        "packages/app/src/components/ui/context-menu.tsx",
-        "packages/app/src/components/ui/dropdown-menu.tsx",
-        "packages/app/src/components/ui/external-link.tsx",
-        "packages/app/src/components/volume-meter.tsx",
-        "packages/app/src/components/web-desktop-scrollbar.tsx",
-        "packages/app/src/components/welcome-screen.tsx",
-        "packages/app/src/composer/agent-controls/index.tsx",
-        "packages/app/src/composer/agent-controls/mode-control.tsx",
-        "packages/app/src/constants/layout.ts",
-        "packages/app/src/desktop/components/desktop-permission-row.tsx",
-        "packages/app/src/desktop/components/desktop-permissions-section.tsx",
-        "packages/app/src/desktop/components/desktop-updates-section.tsx",
-        "packages/app/src/desktop/components/integrations-section.tsx",
-        "packages/app/src/desktop/updates/update-callout-source.tsx",
-        "packages/app/src/git/actions-split-button.tsx",
-        "packages/app/src/hooks/use-web-scrollbar-style.web.ts",
-        "packages/app/src/hosts/host-chooser.tsx",
-        "packages/app/src/screens/open-project-screen.tsx",
-        "packages/app/src/screens/projects-screen.tsx",
-        "packages/app/src/screens/sessions-screen.tsx",
-        "packages/app/src/screens/settings-screen.tsx",
-        "packages/app/src/screens/settings/host-page.tsx",
-        "packages/app/src/screens/settings/providers-section.tsx",
-        "packages/app/src/screens/settings/settings-group.tsx",
-        "packages/app/src/screens/startup-splash-screen.tsx",
-        "packages/app/src/screens/workspace/workspace-route-state-views.tsx"
-      ],
-      "rules": {
-        "no-restricted-imports": [
-          "error",
-          {
-            "paths": [
-              {
-                "name": "react-native",
-                "importNames": ["TextInput"],
-                "message": "Use EditingTextInput from @/components/ui/text-input. Raw TextInput bypasses editing-surface authority and IME safety."
-              },
-              {
-                "name": "@tanstack/react-query",
-                "importNames": ["useQuery", "useInfiniteQuery", "useQueries"],
-                "message": "App reads must go through useReplicaQuery/useFetchQuery from @/data/query. Grandfathered files may only leave the override burn-down list."
-              }
-            ]
-          }
-        ]
-      }
-    },
-    // Both burn-downs: 6 overlapping files. They may only shrink out of this exemption.
-    {
-      "files": [
-        "packages/app/src/components/file-explorer-pane.tsx",
-        "packages/app/src/components/file-pane.tsx",
-        "packages/app/src/components/import-session-sheet.tsx",
-        "packages/app/src/components/project-picker-modal.tsx",
-        "packages/app/src/desktop/components/pair-device-section.tsx",
-        "packages/app/src/screens/new-workspace-screen.tsx"
-      ],
-      "rules": {
-        "no-restricted-imports": [
-          "error",
-          {
-            "paths": [
-              {
-                "name": "react-native",
-                "importNames": ["TextInput"],
-                "message": "Use EditingTextInput from @/components/ui/text-input. Raw TextInput bypasses editing-surface authority and IME safety."
-              }
-            ]
-          }
-        ]
-      }
-    },
-    {
-      "files": [
-        "packages/app/src/components/ui/text-input/**/*.{ts,tsx}",
-        "packages/app/src/agent-stream/scroll-keyboard-dismiss/use-scroll-keyboard-dismiss.ts"
-      ],
-      "rules": {
-        "no-restricted-imports": "off"
-      }
-    },
-    {
-      "files": ["**/e2e/**/fixtures.ts"],
-      "rules": {
-        "no-empty-pattern": "off"
-      }
-    }
-  ]
-}

.tool-versions

@@ -1,4 +1,4 @@
 rust        1.85.1
 nodejs      22.20.0
 java        21
-android-sdk 21.0
+android-sdk latest

CLAUDE.md

@@ -2,7 +2,7 @@
 
 Paseo is a mobile app for monitoring and controlling your local AI coding agents from anywhere. Your dev environment, in your pocket. Connects directly to your actual development environment — your code stays on your machine.
 
-**Supported agents:** Claude Code, Codex, GitHub Copilot, OpenCode, Pi, Antigravity, and Muse Code.
+**Supported agents:** Claude Code, Codex, and OpenCode.
 
 ## Repository map
 
@@ -15,180 +15,44 @@ This is an npm workspace monorepo:
 - `packages/desktop` — Electron desktop wrapper
 - `packages/website` — Marketing site (paseo.sh)
 
-## Docs
+## Documentation
 
-`docs/` is the source of truth for system-level and process-level knowledge. **"The docs", "check the docs", or "check the X docs" always mean this directory — not the web.** Look here before fetching anything online; the docs capture gotchas and conventions you cannot derive from the code or external sources.
-
-At the start of non-trivial work, list `docs/` and skim anything relevant to the task.
-
-| Doc                                                                  | What's in it                                                                                                                   |
-| -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
-| [docs/product.md](docs/product.md)                                   | What Paseo is, who it's for, where it's going                                                                                  |
-| [docs/architecture.md](docs/architecture.md)                         | System design, package layering, WebSocket protocol, agent lifecycle, data flow                                                |
-| [docs/agent-lifecycle.md](docs/agent-lifecycle.md)                   | Agent states, parent/child relationships, archive semantics, tabs vs archive, subagents track                                  |
-| [docs/data-model.md](docs/data-model.md)                             | File-based JSON persistence, Zod schemas, atomic writes, no migrations                                                         |
-| [docs/glossary.md](docs/glossary.md)                                 | Authoritative terminology — UI label wins, no synonyms                                                                         |
-| [docs/coding-standards.md](docs/coding-standards.md)                 | Type hygiene, error handling, state design, React patterns, file organization                                                  |
-| [docs/design.md](docs/design.md)                                     | Design system — tokens, buttons, hierarchy, density, alignment rails, states, what's forbidden                                 |
-| [docs/forms.md](docs/forms.md)                                       | Form architecture — non-React form model, form kit, load-state gating; the schedule form is the golden example                 |
-| [docs/hover.md](docs/hover.md)                                       | Hover — the canonical pattern (plain View + onPointerEnter/Leave, separate inner Pressable) and the three ways agents break it |
-| [docs/unistyles.md](docs/unistyles.md)                               | Unistyles gotchas — `useUnistyles()` is forbidden, alternatives in order                                                       |
-| [docs/floating-panels.md](docs/floating-panels.md)                   | Anchored popovers — Portal/Modal escape for Android, lifecycle gates, keyboard-shared-value, status-bar offset, the flash      |
-| [docs/menus.md](docs/menus.md)                                       | The menu engine — popover vs sheet, submenu pages, hover intent, when a decision earns a submenu                               |
-| [docs/expo-router.md](docs/expo-router.md)                           | Expo Router route ownership, startup restore, and native blank-screen gotchas                                                  |
-| [docs/file-icons.md](docs/file-icons.md)                             | Material icon theme integration for the file explorer                                                                          |
-| [docs/providers.md](docs/providers.md)                               | Adding a new agent provider end-to-end                                                                                         |
-| [docs/forge-providers.md](docs/forge-providers.md)                   | Adding a git forge: registry/manifest, drop-in checklist, self-host/GHES, the two facts tiers                                  |
-| [docs/custom-providers.md](docs/custom-providers.md)                 | Custom provider config: Z.AI, Alibaba/Qwen, ACP agents, profiles, custom binaries                                              |
-| [docs/plugins.md](docs/plugins.md)                                   | Local plugin manifest, directory source config, RPCs, native surfaces, and attachment sources                                  |
-| [docs/service-proxy.md](docs/service-proxy.md)                       | Service proxy: exposing workspace scripts at public URLs, DNS setup, reverse proxy config                                      |
-| [docs/development.md](docs/development.md)                           | Dev server, build sync gotchas, CLI reference, agent state, Playwright MCP                                                     |
-| [docs/rpc-namespacing.md](docs/rpc-namespacing.md)                   | WebSocket RPC naming convention — dotted namespaces and `.request`/`.response` pairs                                           |
-| [docs/protocol-compatibility.md](docs/protocol-compatibility.md)     | Why app/daemon versions drift, protocol vs feature contract, capability gating, COMPAT tagging                                 |
-| [docs/protocol-validation.md](docs/protocol-validation.md)           | zod-aot generated inbound WebSocket validation, patched compiler regressions, schema-purity rules                              |
-| [docs/permissions.md](docs/permissions.md)                           | Semantic daemon permissions, principals, credentials, pairing invitations, and Hub authority                                   |
-| [docs/terminal-performance.md](docs/terminal-performance.md)         | Terminal latency pipeline, coalescing/backpressure invariants, benchmark + perf spec usage                                     |
-| [docs/agent-stream-performance.md](docs/agent-stream-performance.md) | Assistant text pipeline — coalescing window, paced reveal, why arrival lumps are smoothed at render                            |
-| [docs/file-observation.md](docs/file-observation.md)                 | Recursive watcher ownership, Linux constraints, teardown invariants, and Parcel comparison                                     |
-| [docs/testing.md](docs/testing.md)                                   | TDD workflow, determinism, real dependencies over mocks, test organization                                                     |
-| [docs/qa.md](docs/qa.md)                                             | QA evidence bar for pull requests — platform matrix, version drift, performance, UI proof                                      |
-| [docs/mobile-testing.md](docs/mobile-testing.md)                     | Maestro and mobile test workflows                                                                                              |
-| [docs/mobile-panels.md](docs/mobile-panels.md)                       | Compact left/center/right panel ownership, worklet motion, gesture revisions, and Fabric constraints                           |
-| [docs/explorer-sidebar.md](docs/explorer-sidebar.md)                 | Explorer sidebar and ordinary side-pane host contracts, lifecycle, placement, and routing preferences                          |
-| [docs/ad-hoc-daemon-testing.md](docs/ad-hoc-daemon-testing.md)       | Isolated in-process daemon test harness                                                                                        |
-| [docs/browser-capture-harness.md](docs/browser-capture-harness.md)   | Real-Electron browser screenshot harness and compositor-surface gotcha                                                         |
-| [docs/android.md](docs/android.md)                                   | App variants, local/cloud builds, EAS workflows, version codes, F-Droid source builds and store metadata                       |
-| [docs/docker.md](docs/docker.md)                                     | Running the daemon and bundled web UI in Docker, volumes, agent images, security                                               |
-| [docs/release.md](docs/release.md)                                   | Release playbook, draft releases, completion checklist                                                                         |
-| [docs/terminal-activity.md](docs/terminal-activity.md)               | Terminal activity indicators — source-agnostic tracker, agent hook reporting, adding a new hook provider                       |
-| [SECURITY.md](SECURITY.md)                                           | Relay threat model, E2E encryption, DNS rebinding, agent auth                                                                  |
-| [public-docs/hub/security.md](public-docs/hub/security.md)           | Public Hub guide — trust boundaries, untrusted triggers, provider controls, and output authority                               |
-
-### Writing docs
-
-- **Integrate, don't append.** Find the doc that owns the subject and rewrite the part that is now wrong. The standard failure is finishing a task and adding a paragraph to the bottom of the closest-looking doc; ten tasks later the doc is a pile of paragraphs in discovery order. `docs/custom-providers.md` is what that looks like.
-- **Don't document logic.** Prose that restates code drifts from the code and loses. Write down what the code can't tell you: why something is shaped the way it is, the gotcha that cost an afternoon, conventions nothing enforces, constraints that span packages or versions. If a reader could get it in two minutes by opening the file, cut it.
-- **One fact, one doc.** Every other mention is a link. If you are about to write the same paragraph in two docs, one of them is a link.
-- **Respect the layers.** `CONTRIBUTING.md` and this file name things and link out. Activity docs like `docs/qa.md` and `docs/testing.md` set the bar for a kind of work. Subject docs like `docs/unistyles.md` own one thing completely. A layer never re-explains the one below it.
-- **One subject per doc.** If the subject doesn't fit in a sentence, split the doc. A section per provider, vendor, or platform is a table plus one worked example.
-- **Delete.** Obsolete sections go. Prefer a `packages/app/src/thing.ts:120` reference over a pasted block.
-- **New doc?** Add a row to the table above and link it from the docs that should send readers there.
-- Code-level facts belong in comments next to the code, not here.
-
-### Doc voice
-
-Plain and short. Second person. State the rule, then the reason when the reason isn't obvious. Match the doc you're editing.
-
-Do not:
-
-- Write a sentence to land a point. "It's not X, it's Y", "That's not a Z, that's a W", and every other setup-and-punchline shape.
-- Add a clause that only asserts importance: "and that matters", "which is what keeps it working", "this is critical".
-- Use "honest", "robust", "seamless", "powerful", "simply", "just", "delightful".
-- Restate something you already said, in different words, for emphasis.
-- Hedge with "generally", "typically", or "you may want to" when the answer is "do this".
-- Clear your throat: "It's worth noting that", "In order to", "This section covers".
+| Doc | What's in it |
+|---|---|
+| [docs/ARCHITECTURE.md](docs/ARCHITECTURE.md) | System design, package layering, WebSocket protocol, agent lifecycle, data flow |
+| [docs/CODING_STANDARDS.md](docs/CODING_STANDARDS.md) | Type hygiene, error handling, state design, React patterns, file organization |
+| [docs/TESTING.md](docs/TESTING.md) | TDD workflow, determinism, real dependencies over mocks, test organization |
+| [docs/DEVELOPMENT.md](docs/DEVELOPMENT.md) | Dev server, build sync gotchas, CLI reference, agent state, Playwright MCP |
+| [docs/RELEASE.md](docs/RELEASE.md) | Release playbook, draft releases, completion checklist |
+| [docs/ANDROID.md](docs/ANDROID.md) | App variants, local/cloud builds, EAS workflows |
+| [docs/DESIGN.md](docs/DESIGN.md) | How to design features before implementation |
+| [SECURITY.md](SECURITY.md) | Relay threat model, E2E encryption, DNS rebinding, agent auth |
 
 ## Quick start
 
 ```bash
-npm run dev                          # Start the dev daemon
-npm run dev:app                      # Start Expo against the dev daemon
-npm run dev:desktop                  # Start Electron desktop dev
+npm run dev                          # Start daemon + Expo in Tmux
 npm run cli -- ls -a -g              # List all agents
 npm run cli -- daemon status         # Check daemon status
 npm run typecheck                    # Always run after changes
-npm run lint                         # Always run after changes
-npm run format                       # Auto-format with Biome
-npm run format:check                 # Check formatting without writing
 ```
 
-Repo dev commands use checkout-local state by default. In this checkout, `PASEO_HOME` resolves to `.dev/paseo-home`, and `npm run cli -- ...` targets that same dev home automatically. The packaged desktop app and production-style daemon keep using `~/.paseo` on port `6767`.
-
-See [docs/development.md](docs/development.md) for full setup, build sync requirements, and debugging.
-
-## Release branches
-
-When the user says "this goes to next", create or
-retarget the PR to `next` and preserve that destination through delivery. Follow
-[release branch discipline](docs/release.md#release-branch-discipline) for creating
-and updating `next`, integrating it after a release, and releasing a hotfix from a tag.
+See [docs/DEVELOPMENT.md](docs/DEVELOPMENT.md) for full setup, build sync requirements, and debugging.
 
 ## Critical rules
 
 - **NEVER restart the main Paseo daemon on port 6767 without permission** — it manages all running agents. If you're an agent, restarting it kills your own process.
 - **NEVER assume a timeout means the service needs restarting** — timeouts can be transient.
 - **NEVER add auth checks to tests** — agent providers handle their own auth.
-- **Before changing app routes, startup routing, remembered workspace restore, or active workspace selection, read [docs/expo-router.md](docs/expo-router.md).**
-- **NEVER run the full test suite locally.** The test suites are heavy and will freeze the machine, especially if multiple agents run them in parallel. Rules:
-  - Run only the specific test file you changed: `npx vitest run <file> --bail=1`
-  - Never run `npm run test` for an entire workspace unless explicitly asked.
-  - If you must run a broad suite, pipe output to a file and read it afterward: `npx vitest run <file> --bail=1 > /tmp/test-output.txt 2>&1` then read the file.
-  - Never re-run a test suite that another agent already ran and reported green — trust the result.
-  - For full suite verification, push to CI and check GitHub Actions instead.
-- Add tests to existing suites and reuse their npm scripts and CI jobs instead of creating feature-specific ones.
-- **Always run typecheck and lint after every change.**
-- **Build workspace packages before diagnosing cross-package type errors.** This repo consumes generated declarations across workspaces. If typecheck fails in a package that depends on another workspace, rebuild the owning stack first so `dist` declarations are current:
-  - `npm run build:client` — rebuild protocol and client declarations.
-  - `npm run build:server` — rebuild highlight, relay, protocol, client, server, and CLI when server/CLI types may be stale.
-  - Do not patch inferred callback parameters or add local duplicate types just to silence stale declaration errors.
-- **Run `npm run format` before committing.** This repo uses Biome for formatting. Do not manually fix formatting — let the formatter handle it.
-- **Always use npm scripts for linting and formatting.** Do not run tools directly with `npx eslint`, `npx oxfmt`, `npx oxlint`, or package-local binaries. For targeted checks, pass file paths through the npm script:
-  - `npm run lint -- packages/app/src/components/message.tsx`
-  - `npm run format:files -- CLAUDE.md packages/app/src/components/message.tsx`
-- **The protocol stays backward-compatible. Features don't have to.** Read [docs/protocol-compatibility.md](docs/protocol-compatibility.md) before touching `packages/protocol`. The short version:
-  - **Protocol contract (always):** an old client parses messages from a new daemon, and a new daemon parses messages from an old client. New fields are optional; never narrow, never remove, never require. Wire schemas stay pure — no `.transform()`, `.catch()`, or `.preprocess()`.
-  - **Feature contract (per-feature):** gate the capability once on `server_info.features.*`, then run the feature or tell the user to update the host. No fallback paths, no defensive branches.
-  - **Every shim is tagged.** `// COMPAT(name): added in vX, remove after <date>` at the site that has to be deleted. `rg "COMPAT\("` is the cleanup backlog; untagged back-compat is permanent by accident.
-  - **New RPCs use dotted namespaces with direction suffixes.** Follow [docs/rpc-namespacing.md](docs/rpc-namespacing.md): `domain.provider.operation.request` pairs with `domain.provider.operation.response`. Existing flat RPC names will migrate over time; don't add new ones.
-
-## Platform gating
-
-The app runs on iOS, Android, web (browser), and web (Electron desktop). Code is cross-platform by default. Gate only when you must. Import gates from `@/constants/platform`.
-
-### The four gates
-
-| Gate                       | Type      | When to use                                                                                                                 |
-| -------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------- |
-| `isWeb`                    | constant  | DOM APIs — `document`, `window`, `<div>`, `addEventListener`, `ResizeObserver`. This is the **exception**, not the default. |
-| `isNative`                 | constant  | Native-only APIs — Haptics, `StatusBar.currentHeight`, push tokens, camera/scanner, `expo-av`.                              |
-| `getIsElectron()`          | cached fn | Desktop wrapper features — file dialogs, titlebar drag region, daemon management, app updates, dock badges.                 |
-| `useIsCompactFormFactor()` | hook      | Layout decisions — sidebar overlay vs pinned, modal vs full screen, single-panel vs split. From `@/constants/layout`.       |
-
-### Decision matrix
-
-| I need to...                                                   | Use                                                                       |
-| -------------------------------------------------------------- | ------------------------------------------------------------------------- |
-| Access DOM (`document`, `window`, `<div>`, `addEventListener`) | `if (isWeb)`                                                              |
-| Use a native-only API (Haptics, push tokens, camera)           | `if (isNative)`                                                           |
-| Use an Electron bridge (file dialog, titlebar, updates)        | `if (getIsElectron())`                                                    |
-| Switch layout between phone and tablet/desktop                 | `useIsCompactFormFactor()`                                                |
-| Show something on hover, always-visible on native              | `isHovered \|\| isNative \|\| isCompact` (hover only works on web)        |
-| Gate to iOS or Android specifically                            | `Platform.OS === "ios"` / `Platform.OS === "android"` (rare, keep inline) |
-
-### Rules
-
-- **Default is cross-platform.** Don't gate unless you have a specific reason.
-- **Prefer Metro file extensions over `if` statements.** When a module has fundamentally different implementations per platform, use `.web.ts` / `.native.ts` file extensions instead of runtime `if (isWeb)` branches. Metro resolves the correct file at build time — the unused platform code is never bundled. Reserve `if (isWeb)` for small, inline checks (a single line or a few props). If you find yourself writing a large `if (isWeb) { ... } else { ... }` block, split into separate files instead.
-  ```
-  hooks/
-    use-audio-recorder.web.ts    ← uses Web Audio API
-    use-audio-recorder.native.ts ← uses expo-audio
-  ```
-  Import as `@/hooks/use-audio-recorder` — Metro picks the right file automatically.
-- **Use `.electron.ts` / `.electron.tsx` for Electron-only web modules.** Electron is still the Metro `web` platform, but desktop dev/build sets `PASEO_WEB_PLATFORM=electron`, so Metro first looks for `.electron.*` files and falls back to normal `.web.*` files. Use this when the implementation depends on Electron-only behavior such as `webviewTag`, desktop preload APIs, or the Electron bridge. Keep plain browser web in `.web.*`, and keep native fallbacks in the base file or `.native.*`.
-  ```
-  desktop/browser/pane/
-    index.electron.tsx ← Electron <webview> implementation
-    index.web.tsx      ← plain web fallback
-    index.tsx          ← native fallback
-  ```
-  Import as `@/desktop/browser/pane` — Electron desktop gets the `.electron.tsx` file, browser web gets `.web.tsx`, and native gets the native/base implementation.
-- **NEVER use raw DOM APIs without `isWeb` guard.** DOM APIs crash native. Casting a RN ref to `HTMLElement` is a red flag — ensure the block is web-only.
-- **NEVER use `onPointerEnter`/`onPointerLeave`.** They don't fire on native iOS.
-- **Hover only works on web.** React Native's `onHoverIn`/`onHoverOut` on `Pressable` does NOT fire on native iOS/iPad — the underlying W3C pointer events are behind disabled experimental flags. For hover-to-show UI (kebab menus, action buttons), use `isHovered || isNative || isCompact` so the controls are always visible on native and hover-to-show on web.
-- **Don't use Platform.OS as a proxy for layout capabilities.** Use breakpoints for layout decisions, not platform checks.
-- **Import `isWeb`/`isNative` from `@/constants/platform`.** Never write `const isWeb = Platform.OS === "web"` locally.
+- **Always run typecheck after every change.**
+- **NEVER make breaking changes to WebSocket or message schemas.** The primary compatibility path is old mobile app clients talking to newly updated daemons. Users update desktop and daemon first, then keep running the old app for a while. Every schema change MUST be backward-compatible for old clients against new daemons:
+  - New fields: always `.optional()` with a sensible default or `.transform()` fallback.
+  - Never change a field from optional to required.
+  - Never remove a field — deprecate it (keep accepting it, stop sending it).
+  - Never narrow a field's type (e.g. `string` → `enum`, `nullable` → non-null).
+  - Test with: "does a 6-month-old client still parse this?" and "does a 6-month-old daemon still send something this client accepts?"
 
 ## Debugging
 
+
 Find the complete daemon logs and traces in the $PASEO_HOME/daemon.log

CONTRIBUTING.md

@@ -1,104 +0,0 @@
-# Contributing to Paseo
-
-This guide is here to save us both time and help you find a useful way to contribute.
-
-Paseo grows through bug reports, testing, workflow discussions, plugins, documentation, and people helping each other. The sections below explain where each contribution belongs and what to expect.
-
-## Philosophy
-
-**Paseo has a lean, opinionated core built to be extended.**
-
-The goal is a low floor and a high ceiling: a polished default experience that is easy to understand, with the flexibility to choose your providers, run on your own infrastructure, and build your own workflows. Paseo should remain self-hosted and respectful of your privacy and control.
-
-The core continues to evolve through improvements to the shared experience. Specialized workflows and integrations belong in the extension ecosystem. Product, design, architecture, and workflow decisions remain with the maintainer.
-
-Read the [product philosophy](docs/product.md) for the reasoning behind these choices and how Paseo develops.
-
-## Build a plugin
-
-Most specialized workflows and integrations are better served by plugins.
-
-Plugins let you build what you need, share it, and maintain it independently. Start with the [plugin documentation](https://paseo.sh/docs/plugins). For applications and integrations built around Paseo, see the [SDK documentation](https://paseo.sh/docs/sdk).
-
-If an extension point is missing, describe the workflow in [Discussions](https://github.com/getpaseo/paseo/discussions). A reusable capability that enables several plugins may be a better addition than implementing one particular workflow in core.
-
-## Report bugs
-
-Open a [GitHub issue](https://github.com/getpaseo/paseo/issues) and fill out the bug report template.
-
-Include:
-
-- What you did, what you expected, and what happened.
-- Reproduction steps, Paseo version, and platform.
-- Relevant logs, screenshots, or a recording.
-
-If an agent investigated, include the evidence and reproduction steps it collected. Its explanation of the cause still needs verification.
-
-Focused fixes for reproducible bugs are welcome. If you submit one, follow the pull request and QA guidance below.
-
-## Discuss workflows before proposing features
-
-Product discussions, including feature requests, belong in [GitHub Discussions](https://github.com/getpaseo/paseo/discussions). Feature requests opened as issues will be closed.
-
-Explain:
-
-- What are you trying to do?
-- How do you do it today?
-- Where does Paseo get in the way?
-- What would a better workflow look like?
-
-This helps other people describe their needs and gives me useful context when deciding what to build.
-
-There is no feature request backlog or commitment to implement a discussion. I may read and learn from it without replying.
-
-## If you still want to submit a pull request
-
-After considering plugins and discussing the workflow, you may still want to propose a change to core. Focused fixes for reproducible bugs are also welcome.
-
-**Pull requests are closed by default.** I may reopen the ones I want to take forward. Submit one only if you are comfortable with it being closed without a detailed review or explanation.
-
-Paseo receives more pull requests than I can responsibly review. Reviewing every submission and explaining every decision would consume the time available for developing the product.
-
-I can prompt an agent to write code just as you can. The bottlenecks are choosing what to build, shaping it, verifying its behavior, and taking responsibility for its maintenance. A finished implementation still leaves that work to do.
-
-If you choose to submit a PR, these are the basics to cover.
-
-### What I look for in a core feature
-
-- **Demonstrated demand.** Link a discussion with concrete examples of other users needing the workflow. A feature for a small, specialized use case belongs in a plugin.
-- **Value across workflows.** The feature should improve how existing capabilities work together and benefit a broad set of users. A reusable improvement is more valuable than an isolated control for one task.
-- **A coherent design across platforms and providers.** Shared capabilities should work across platforms and providers wherever applicable. Do not reshape a shared abstraction around one provider while leaving the others unsupported or inconsistent.
-- **A finished experience.** Follow the [design guidelines](docs/design.md). The feature must look and feel right in Paseo, including loading states, layout stability, and interaction performance. PRs with janky or rushed interfaces will be closed. Design judgment remains with the maintainer.
-
-### Keep the scope small
-
-Submit one focused change. PRs adding more than roughly **3,000 lines of production code** are unlikely to be accepted. Prefer the smallest complete improvement that can be tested and understood on its own.
-
-### QA evidence
-
-Run the changed application or service and test the affected workflow yourself. Include detailed QA evidence so I can see what you exercised and what happened. PRs without this verification and evidence will be closed, whether they fix a bug or add a feature.
-
-Explain the problem and link the relevant bug report or discussion. Include:
-
-- Automated tests that exercise the changed behavior. A bug fix needs a regression test that fails on the broken version.
-- The commands you ran and their output.
-- A recording for interactive UI changes, or before-and-after screenshots for static changes.
-- The platforms you tested and any affected platforms you could not test.
-
-The [QA guide](docs/qa.md) explains the expected evidence and available tooling.
-
-Using an agent is welcome. Sending it to implement a change and submitting its output without trying the result yourself does not meet this bar.
-
-**Satisfying all of the above does not mean your pull request will be merged.**
-
-### What happens to your contribution
-
-If I take a contribution forward, I may narrow it, reshape it, or use it as a reference for my own implementation. **You will be credited for your contribution, including when I reimplement it.**
-
-A closed PR does not necessarily mean the underlying problem was dismissed. It means I am not taking that submission forward. Detailed reviews, individual explanations, and follow-up discussions cannot be provided at this volume.
-
-## Help the community
-
-Testing betas, reproducing bugs, improving documentation, sharing plugins, and answering questions all help Paseo develop.
-
-There is no formal process for becoming a maintainer. Consistent involvement and good judgment build the shared context needed to take on more responsibility.

LICENSE

@@ -2,210 +2,670 @@ Copyright (c) 2025-present Mohamed Boudra
 
 Portions of this software are licensed as follows:
 
-* Third-party components incorporated into Paseo remain licensed under
-  the licenses provided by their respective copyright holders.
-* Except for those third-party components, Paseo is licensed under the
-  Apache License, Version 2.0, reproduced below.
+* All third party components incorporated into the Paseo Software are
+  licensed under the original license provided by the owner of the
+  applicable component.
+* All content outside of the above mentioned restrictions is available
+  under the "AGPLv3" license as defined below.
 
+                    GNU AFFERO GENERAL PUBLIC LICENSE
+                       Version 3, 19 November 2007
 
-                                 Apache License
-                           Version 2.0, January 2004
-                        http://www.apache.org/licenses/
+ Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
 
-   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+                            Preamble
 
-   1. Definitions.
+  The GNU Affero General Public License is a free, copyleft license for
+software and other kinds of works, specifically designed to ensure
+cooperation with the community in the case of network server software.
 
-      "License" shall mean the terms and conditions for use, reproduction,
-      and distribution as defined by Sections 1 through 9 of this document.
+  The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works.  By contrast,
+our General Public Licenses are intended to guarantee your freedom to
+share and change all versions of a program--to make sure it remains free
+software for all its users.
 
-      "Licensor" shall mean the copyright owner or entity authorized by
-      the copyright owner that is granting the License.
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+them if you wish), that you receive source code or can get it if you
+want it, that you can change the software or use pieces of it in new
+free programs, and that you know you can do these things.
 
-      "Legal Entity" shall mean the union of the acting entity and all
-      other entities that control, are controlled by, or are under common
-      control with that entity. For the purposes of this definition,
-      "control" means (i) the power, direct or indirect, to cause the
-      direction or management of such entity, whether by contract or
-      otherwise, or (ii) ownership of fifty percent (50%) or more of the
-      outstanding shares, or (iii) beneficial ownership of such entity.
+  Developers that use our General Public Licenses protect your rights
+with two steps: (1) assert copyright on the software, and (2) offer
+you this License which gives you legal permission to copy, distribute
+and/or modify the software.
 
-      "You" (or "Your") shall mean an individual or Legal Entity
-      exercising permissions granted by this License.
+  A secondary benefit of defending all users' freedom is that
+improvements made in alternate versions of the program, if they
+receive widespread use, become available for other developers to
+incorporate.  Many developers of free software are heartened and
+encouraged by the resulting cooperation.  However, in the case of
+software used on network servers, this result may fail to come about.
+The GNU General Public License permits making a modified version and
+letting the public access it on a server without ever releasing its
+source code to the public.
 
-      "Source" form shall mean the preferred form for making modifications,
-      including but not limited to software source code, documentation
-      source, and configuration files.
+  The GNU Affero General Public License is designed specifically to
+ensure that, in such cases, the modified source code becomes available
+to the community.  It requires the operator of a network server to
+provide the source code of the modified version running there to the
+users of that server.  Therefore, public use of a modified version, on
+a publicly accessible server, gives the public access to the source
+code of the modified version.
 
-      "Object" form shall mean any form resulting from mechanical
-      transformation or translation of a Source form, including but
-      not limited to compiled object code, generated documentation,
-      and conversions to other media types.
+  An older license, called the Affero General Public License and
+published by Affero, was designed to accomplish similar goals.  This is
+a different license, not a version of the Affero GPL, but Affero has
+released a new version of the Affero GPL which permits relicensing under
+this license.
 
-      "Work" shall mean the work of authorship, whether in Source or
-      Object form, made available under the License, as indicated by a
-      copyright notice that is included in or attached to the work
-      (an example is provided in the Appendix below).
+  The precise terms and conditions for copying, distribution and
+modification follow.
 
-      "Derivative Works" shall mean any work, whether in Source or Object
-      form, that is based on (or derived from) the Work and for which the
-      editorial revisions, annotations, elaborations, or other modifications
-      represent, as a whole, an original work of authorship. For the purposes
-      of this License, Derivative Works shall not include works that remain
-      separable from, or merely link (or bind by name) to the interfaces of,
-      the Work and Derivative Works thereof.
+                       TERMS AND CONDITIONS
 
-      "Contribution" shall mean any work of authorship, including
-      the original version of the Work and any modifications or additions
-      to that Work or Derivative Works thereof, that is intentionally
-      submitted to Licensor for inclusion in the Work by the copyright owner
-      or by an individual or Legal Entity authorized to submit on behalf of
-      the copyright owner. For the purposes of this definition, "submitted"
-      means any form of electronic, verbal, or written communication sent
-      to the Licensor or its representatives, including but not limited to
-      communication on electronic mailing lists, source code control systems,
-      and issue tracking systems that are managed by, or on behalf of, the
-      Licensor for the purpose of discussing and improving the Work, but
-      excluding communication that is conspicuously marked or otherwise
-      designated in writing by the copyright owner as "Not a Contribution."
+  0. Definitions.
 
-      "Contributor" shall mean Licensor and any individual or Legal Entity
-      on behalf of whom a Contribution has been received by Licensor and
-      subsequently incorporated within the Work.
+  "This License" refers to version 3 of the GNU Affero General Public License.
 
-   2. Grant of Copyright License. Subject to the terms and conditions of
-      this License, each Contributor hereby grants to You a perpetual,
-      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
-      copyright license to reproduce, prepare Derivative Works of,
-      publicly display, publicly perform, sublicense, and distribute the
-      Work and such Derivative Works in Source or Object form.
+  "Copyright" also means copyright-like laws that apply to other kinds of
+works, such as semiconductor masks.
 
-   3. Grant of Patent License. Subject to the terms and conditions of
-      this License, each Contributor hereby grants to You a perpetual,
-      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
-      (except as stated in this section) patent license to make, have made,
-      use, offer to sell, sell, import, and otherwise transfer the Work,
-      where such license applies only to those patent claims licensable
-      by such Contributor that are necessarily infringed by their
-      Contribution(s) alone or by combination of their Contribution(s)
-      with the Work to which such Contribution(s) was submitted. If You
-      institute patent litigation against any entity (including a
-      cross-claim or counterclaim in a lawsuit) alleging that the Work
-      or a Contribution incorporated within the Work constitutes direct
-      or contributory patent infringement, then any patent licenses
-      granted to You under this License for that Work shall terminate
-      as of the date such litigation is filed.
+  "The Program" refers to any copyrightable work licensed under this
+License.  Each licensee is addressed as "you".  "Licensees" and
+"recipients" may be individuals or organizations.
 
-   4. Redistribution. You may reproduce and distribute copies of the
-      Work or Derivative Works thereof in any medium, with or without
-      modifications, and in Source or Object form, provided that You
-      meet the following conditions:
+  To "modify" a work means to copy from or adapt all or part of the work
+in a fashion requiring copyright permission, other than the making of an
+exact copy.  The resulting work is called a "modified version" of the
+earlier work or a work "based on" the earlier work.
 
-      (a) You must give any other recipients of the Work or
-          Derivative Works a copy of this License; and
+  A "covered work" means either the unmodified Program or a work based
+on the Program.
 
-      (b) You must cause any modified files to carry prominent notices
-          stating that You changed the files; and
+  To "propagate" a work means to do anything with it that, without
+permission, would make you directly or secondarily liable for
+infringement under applicable copyright law, except executing it on a
+computer or modifying a private copy.  Propagation includes copying,
+distribution (with or without modification), making available to the
+public, and in some countries other activities as well.
 
-      (c) You must retain, in the Source form of any Derivative Works
-          that You distribute, all copyright, patent, trademark, and
-          attribution notices from the Source form of the Work,
-          excluding those notices that do not pertain to any part of
-          the Derivative Works; and
+  To "convey" a work means any kind of propagation that enables other
+parties to make or receive copies.  Mere interaction with a user through
+a computer network, with no transfer of a copy, is not conveying.
 
-      (d) If the Work includes a "NOTICE" text file as part of its
-          distribution, then any Derivative Works that You distribute must
-          include a readable copy of the attribution notices contained
-          within such NOTICE file, excluding those notices that do not
-          pertain to any part of the Derivative Works, in at least one
-          of the following places: within a NOTICE text file distributed
-          as part of the Derivative Works; within the Source form or
-          documentation, if provided along with the Derivative Works; or,
-          within a display generated by the Derivative Works, if and
-          wherever such third-party notices normally appear. The contents
-          of the NOTICE file are for informational purposes only and
-          do not modify the License. You may add Your own attribution
-          notices within Derivative Works that You distribute, alongside
-          or as an addendum to the NOTICE text from the Work, provided
-          that such additional attribution notices cannot be construed
-          as modifying the License.
+  An interactive user interface displays "Appropriate Legal Notices"
+to the extent that it includes a convenient and prominently visible
+feature that (1) displays an appropriate copyright notice, and (2)
+tells the user that there is no warranty for the work (except to the
+extent that warranties are provided), that licensees may convey the
+work under this License, and how to view a copy of this License.  If
+the interface presents a list of user commands or options, such as a
+menu, a prominent item in the list meets this criterion.
 
-      You may add Your own copyright statement to Your modifications and
-      may provide additional or different license terms and conditions
-      for use, reproduction, or distribution of Your modifications, or
-      for any such Derivative Works as a whole, provided Your use,
-      reproduction, and distribution of the Work otherwise complies with
-      the conditions stated in this License.
+  1. Source Code.
 
-   5. Submission of Contributions. Unless You explicitly state otherwise,
-      any Contribution intentionally submitted for inclusion in the Work
-      by You to the Licensor shall be under the terms and conditions of
-      this License, without any additional terms or conditions.
-      Notwithstanding the above, nothing herein shall supersede or modify
-      the terms of any separate license agreement you may have executed
-      with Licensor regarding such Contributions.
+  The "source code" for a work means the preferred form of the work
+for making modifications to it.  "Object code" means any non-source
+form of a work.
 
-   6. Trademarks. This License does not grant permission to use the trade
-      names, trademarks, service marks, or product names of the Licensor,
-      except as required for reasonable and customary use in describing the
-      origin of the Work and reproducing the content of the NOTICE file.
+  A "Standard Interface" means an interface that either is an official
+standard defined by a recognized standards body, or, in the case of
+interfaces specified for a particular programming language, one that
+is widely used among developers working in that language.
 
-   7. Disclaimer of Warranty. Unless required by applicable law or
-      agreed to in writing, Licensor provides the Work (and each
-      Contributor provides its Contributions) on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
-      implied, including, without limitation, any warranties or conditions
-      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
-      PARTICULAR PURPOSE. You are solely responsible for determining the
-      appropriateness of using or redistributing the Work and assume any
-      risks associated with Your exercise of permissions under this License.
+  The "System Libraries" of an executable work include anything, other
+than the work as a whole, that (a) is included in the normal form of
+packaging a Major Component, but which is not part of that Major
+Component, and (b) serves only to enable use of the work with that
+Major Component, or to implement a Standard Interface for which an
+implementation is available to the public in source code form.  A
+"Major Component", in this context, means a major essential component
+(kernel, window system, and so on) of the specific operating system
+(if any) on which the executable work runs, or a compiler used to
+produce the work, or an object code interpreter used to run it.
 
-   8. Limitation of Liability. In no event and under no legal theory,
-      whether in tort (including negligence), contract, or otherwise,
-      unless required by applicable law (such as deliberate and grossly
-      negligent acts) or agreed to in writing, shall any Contributor be
-      liable to You for damages, including any direct, indirect, special,
-      incidental, or consequential damages of any character arising as a
-      result of this License or out of the use or inability to use the
-      Work (including but not limited to damages for loss of goodwill,
-      work stoppage, computer failure or malfunction, or any and all
-      other commercial damages or losses), even if such Contributor
-      has been advised of the possibility of such damages.
+  The "Corresponding Source" for a work in object code form means all
+the source code needed to generate, install, and (for an executable
+work) run the object code and to modify the work, including scripts to
+control those activities.  However, it does not include the work's
+System Libraries, or general-purpose tools or generally available free
+programs which are used unmodified in performing those activities but
+which are not part of the work.  For example, Corresponding Source
+includes interface definition files associated with source files for
+the work, and the source code for shared libraries and dynamically
+linked subprograms that the work is specifically designed to require,
+such as by intimate data communication or control flow between those
+subprograms and other parts of the work.
 
-   9. Accepting Warranty or Additional Liability. While redistributing
-      the Work or Derivative Works thereof, You may choose to offer,
-      and charge a fee for, acceptance of support, warranty, indemnity,
-      or other liability obligations and/or rights consistent with this
-      License. However, in accepting such obligations, You may act only
-      on Your own behalf and on Your sole responsibility, not on behalf
-      of any other Contributor, and only if You agree to indemnify,
-      defend, and hold each Contributor harmless for any liability
-      incurred by, or claims asserted against, such Contributor by reason
-      of your accepting any such warranty or additional liability.
+  The Corresponding Source need not include anything that users
+can regenerate automatically from other parts of the Corresponding
+Source.
 
-   END OF TERMS AND CONDITIONS
+  The Corresponding Source for a work in source code form is that
+same work.
 
-   APPENDIX: How to apply the Apache License to your work.
+  2. Basic Permissions.
 
-      To apply the Apache License to your work, attach the following
-      boilerplate notice, with the fields enclosed by brackets "[]"
-      replaced with your own identifying information. (Don't include
-      the brackets!)  The text should be enclosed in the appropriate
-      comment syntax for the file format. We also recommend that a
-      file or class name and description of purpose be included on the
-      same "printed page" as the copyright notice for easier
-      identification within third-party archives.
+  All rights granted under this License are granted for the term of
+copyright on the Program, and are irrevocable provided the stated
+conditions are met.  This License explicitly affirms your unlimited
+permission to run the unmodified Program.  The output from running a
+covered work is covered by this License only if the output, given its
+content, constitutes a covered work.  This License acknowledges your
+rights of fair use or other equivalent, as provided by copyright law.
 
-   Copyright [yyyy] [name of copyright owner]
+  You may make, run and propagate covered works that you do not
+convey, without conditions so long as your license otherwise remains
+in force.  You may convey covered works to others for the sole purpose
+of having them make modifications exclusively for you, or provide you
+with facilities for running those works, provided that you comply with
+the terms of this License in conveying all material for which you do
+not control copyright.  Those thus making or running the covered works
+for you must do so exclusively on your behalf, under your direction
+and control, on terms that prohibit them from making any copies of
+your copyrighted material outside their relationship with you.
 
-   Licensed under the Apache License, Version 2.0 (the "License");
-   you may not use this file except in compliance with the License.
-   You may obtain a copy of the License at
+  Conveying under any other circumstances is permitted solely under
+the conditions stated below.  Sublicensing is not allowed; section 10
+makes it unnecessary.
 
-       http://www.apache.org/licenses/LICENSE-2.0
+  3. Protecting Users' Legal Rights From Anti-Circumvention Law.
 
-   Unless required by applicable law or agreed to in writing, software
-   distributed under the License is distributed on an "AS IS" BASIS,
-   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-   See the License for the specific language governing permissions and
-   limitations under the License.
+  No covered work shall be deemed part of an effective technological
+measure under any applicable law fulfilling obligations under article
+11 of the WIPO copyright treaty adopted on 20 December 1996, or
+similar laws prohibiting or restricting circumvention of such
+measures.
+
+  When you convey a covered work, you waive any legal power to forbid
+circumvention of technological measures to the extent such circumvention
+is effected by exercising rights under this License with respect to
+the covered work, and you disclaim any intention to limit operation or
+modification of the work as a means of enforcing, against the work's
+users, your or third parties' legal rights to forbid circumvention of
+technological measures.
+
+  4. Conveying Verbatim Copies.
+
+  You may convey verbatim copies of the Program's source code as you
+receive it, in any medium, provided that you conspicuously and
+appropriately publish on each copy an appropriate copyright notice;
+keep intact all notices stating that this License and any
+non-permissive terms added in accord with section 7 apply to the code;
+keep intact all notices of the absence of any warranty; and give all
+recipients a copy of this License along with the Program.
+
+  You may charge any price or no price for each copy that you convey,
+and you may offer support or warranty protection for a fee.
+
+  5. Conveying Modified Source Versions.
+
+  You may convey a work based on the Program, or the modifications to
+produce it from the Program, in the form of source code under the
+terms of section 4, provided that you also meet all of these conditions:
+
+    a) The work must carry prominent notices stating that you modified
+    it, and giving a relevant date.
+
+    b) The work must carry prominent notices stating that it is
+    released under this License and any conditions added under section
+    7.  This requirement modifies the requirement in section 4 to
+    "keep intact all notices".
+
+    c) You must license the entire work, as a whole, under this
+    License to anyone who comes into possession of a copy.  This
+    License will therefore apply, along with any applicable section 7
+    additional terms, to the whole of the work, and all its parts,
+    regardless of how they are packaged.  This License gives no
+    permission to license the work in any other way, but it does not
+    invalidate such permission if you have separately received it.
+
+    d) If the work has interactive user interfaces, each must display
+    Appropriate Legal Notices; however, if the Program has interactive
+    interfaces that do not display Appropriate Legal Notices, your
+    work need not make them do so.
+
+  A compilation of a covered work with other separate and independent
+works, which are not by their nature extensions of the covered work,
+and which are not combined with it such as to form a larger program,
+in or on a volume of a storage or distribution medium, is called an
+"aggregate" if the compilation and its resulting copyright are not
+used to limit the access or legal rights of the compilation's users
+beyond what the individual works permit.  Inclusion of a covered work
+in an aggregate does not cause this License to apply to the other
+parts of the aggregate.
+
+  6. Conveying Non-Source Forms.
+
+  You may convey a covered work in object code form under the terms
+of sections 4 and 5, provided that you also convey the
+machine-readable Corresponding Source under the terms of this License,
+in one of these ways:
+
+    a) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by the
+    Corresponding Source fixed on a durable physical medium
+    customarily used for software interchange.
+
+    b) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by a
+    written offer, valid for at least three years and valid for as
+    long as you offer spare parts or customer support for that product
+    model, to give anyone who possesses the object code either (1) a
+    copy of the Corresponding Source for all the software in the
+    product that is covered by this License, on a durable physical
+    medium customarily used for software interchange, for a price no
+    more than your reasonable cost of physically performing this
+    conveying of source, or (2) access to copy the
+    Corresponding Source from a network server at no charge.
+
+    c) Convey individual copies of the object code with a copy of the
+    written offer to provide the Corresponding Source.  This
+    alternative is allowed only occasionally and noncommercially, and
+    only if you received the object code with such an offer, in accord
+    with subsection 6b.
+
+    d) Convey the object code by offering access from a designated
+    place (gratis or for a charge), and offer equivalent access to the
+    Corresponding Source in the same way through the same place at no
+    further charge.  You need not require recipients to copy the
+    Corresponding Source along with the object code.  If the place to
+    copy the object code is a network server, the Corresponding Source
+    may be on a different server (operated by you or a third party)
+    that supports equivalent copying facilities, provided you maintain
+    clear directions next to the object code saying where to find the
+    Corresponding Source.  Regardless of what server hosts the
+    Corresponding Source, you remain obligated to ensure that it is
+    available for as long as needed to satisfy these requirements.
+
+    e) Convey the object code using peer-to-peer transmission, provided
+    you inform other peers where the object code and Corresponding
+    Source of the work are being offered to the general public at no
+    charge under subsection 6d.
+
+  A separable portion of the object code, whose source code is excluded
+from the Corresponding Source as a System Library, need not be
+included in conveying the object code work.
+
+  A "User Product" is either (1) a "consumer product", which means any
+tangible personal property which is normally used for personal, family,
+or household purposes, or (2) anything designed or sold for incorporation
+into a dwelling.  In determining whether a product is a consumer product,
+doubtful cases shall be resolved in favor of coverage.  For a particular
+product received by a particular user, "normally used" refers to a
+typical or common use of that class of product, regardless of the status
+of the particular user or of the way in which the particular user
+actually uses, or expects or is expected to use, the product.  A product
+is a consumer product regardless of whether the product has substantial
+commercial, industrial or non-consumer uses, unless such uses represent
+the only significant mode of use of the product.
+
+  "Installation Information" for a User Product means any methods,
+procedures, authorization keys, or other information required to install
+and execute modified versions of a covered work in that User Product from
+a modified version of its Corresponding Source.  The information must
+suffice to ensure that the continued functioning of the modified object
+code is in no case prevented or interfered with solely because
+modification has been made.
+
+  If you convey an object code work under this section in, or with, or
+specifically for use in, a User Product, and the conveying occurs as
+part of a transaction in which the right of possession and use of the
+User Product is transferred to the recipient in perpetuity or for a
+fixed term (regardless of how the transaction is characterized), the
+Corresponding Source conveyed under this section must be accompanied
+by the Installation Information.  But this requirement does not apply
+if neither you nor any third party retains the ability to install
+modified object code on the User Product (for example, the work has
+been installed in ROM).
+
+  The requirement to provide Installation Information does not include a
+requirement to continue to provide support service, warranty, or updates
+for a work that has been modified or installed by the recipient, or for
+the User Product in which it has been modified or installed.  Access to a
+network may be denied when the modification itself materially and
+adversely affects the operation of the network or violates the rules and
+protocols for communication across the network.
+
+  Corresponding Source conveyed, and Installation Information provided,
+in accord with this section must be in a format that is publicly
+documented (and with an implementation available to the public in
+source code form), and must require no special password or key for
+unpacking, reading or copying.
+
+  7. Additional Terms.
+
+  "Additional permissions" are terms that supplement the terms of this
+License by making exceptions from one or more of its conditions.
+Additional permissions that are applicable to the entire Program shall
+be treated as though they were included in this License, to the extent
+that they are valid under applicable law.  If additional permissions
+apply only to part of the Program, that part may be used separately
+under those permissions, but the entire Program remains governed by
+this License without regard to the additional permissions.
+
+  When you convey a copy of a covered work, you may at your option
+remove any additional permissions from that copy, or from any part of
+it.  (Additional permissions may be written to require their own
+removal in certain cases when you modify the work.)  You may place
+additional permissions on material, added by you to a covered work,
+for which you have or can give appropriate copyright permission.
+
+  Notwithstanding any other provision of this License, for material you
+add to a covered work, you may (if authorized by the copyright holders of
+that material) supplement the terms of this License with terms:
+
+    a) Disclaiming warranty or limiting liability differently from the
+    terms of sections 15 and 16 of this License; or
+
+    b) Requiring preservation of specified reasonable legal notices or
+    author attributions in that material or in the Appropriate Legal
+    Notices displayed by works containing it; or
+
+    c) Prohibiting misrepresentation of the origin of that material, or
+    requiring that modified versions of such material be marked in
+    reasonable ways as different from the original version; or
+
+    d) Limiting the use for publicity purposes of names of licensors or
+    authors of the material; or
+
+    e) Declining to grant rights under trademark law for use of some
+    trade names, trademarks, or service marks; or
+
+    f) Requiring indemnification of licensors and authors of that
+    material by anyone who conveys the material (or modified versions of
+    it) with contractual assumptions of liability to the recipient, for
+    any liability that these contractual assumptions directly impose on
+    those licensors and authors.
+
+  All other non-permissive additional terms are considered "further
+restrictions" within the meaning of section 10.  If the Program as you
+received it, or any part of it, contains a notice stating that it is
+governed by this License along with a term that is a further
+restriction, you may remove that term.  If a license document contains
+a further restriction but permits relicensing or conveying under this
+License, you may add to a covered work material governed by the terms
+of that license document, provided that the further restriction does
+not survive such relicensing or conveying.
+
+  If you add terms to a covered work in accord with this section, you
+must place, in the relevant source files, a statement of the
+additional terms that apply to those files, or a notice indicating
+where to find the applicable terms.
+
+  Additional terms, permissive or non-permissive, may be stated in the
+form of a separately written license, or stated as exceptions;
+the above requirements apply either way.
+
+  8. Termination.
+
+  You may not propagate or modify a covered work except as expressly
+provided under this License.  Any attempt otherwise to propagate or
+modify it is void, and will automatically terminate your rights under
+this License (including any patent licenses granted under the third
+paragraph of section 11).
+
+  However, if you cease all violation of this License, then your
+license from a particular copyright holder is reinstated (a)
+provisionally, unless and until the copyright holder explicitly and
+finally terminates your license, and (b) permanently, if the copyright
+holder fails to notify you of the violation by some reasonable means
+prior to 60 days after the cessation.
+
+  Moreover, your license from a particular copyright holder is
+reinstated permanently if the copyright holder notifies you of the
+violation by some reasonable means, this is the first time you have
+received notice of violation of this License (for any work) from that
+copyright holder, and you cure the violation prior to 30 days after
+your receipt of the notice.
+
+  Termination of your rights under this section does not terminate the
+licenses of parties who have received copies or rights from you under
+this License.  If your rights have been terminated and not permanently
+reinstated, you do not qualify to receive new licenses for the same
+material under section 10.
+
+  9. Acceptance Not Required for Having Copies.
+
+  You are not required to accept this License in order to receive or
+run a copy of the Program.  Ancillary propagation of a covered work
+occurring solely as a consequence of using peer-to-peer transmission
+to receive a copy likewise does not require acceptance.  However,
+nothing other than this License grants you permission to propagate or
+modify any covered work.  These actions infringe copyright if you do
+not accept this License.  Therefore, by modifying or propagating a
+covered work, you indicate your acceptance of this License to do so.
+
+  10. Automatic Licensing of Downstream Recipients.
+
+  Each time you convey a covered work, the recipient automatically
+receives a license from the original licensors, to run, modify and
+propagate that work, subject to this License.  You are not responsible
+for enforcing compliance by third parties with this License.
+
+  An "entity transaction" is a transaction transferring control of an
+organization, or substantially all assets of one, or subdividing an
+organization, or merging organizations.  If propagation of a covered
+work results from an entity transaction, each party to that
+transaction who receives a copy of the work also receives whatever
+licenses to the work the party's predecessor in interest had or could
+give under the previous paragraph, plus a right to possession of the
+Corresponding Source of the work from the predecessor in interest, if
+the predecessor has it or can get it with reasonable efforts.
+
+  You may not impose any further restrictions on the exercise of the
+rights granted or affirmed under this License.  For example, you may
+not impose a license fee, royalty, or other charge for exercise of
+rights granted under this License, and you may not initiate litigation
+(including a cross-claim or counterclaim in a lawsuit) alleging that
+any patent claim is infringed by making, using, selling, offering for
+sale, or importing the Program or any portion of it.
+
+  11. Patents.
+
+  A "contributor" is a copyright holder who authorizes use under this
+License of the Program or a work on which the Program is based.  The
+work thus licensed is called the contributor's "contributor version".
+
+  A contributor's "essential patent claims" are all patent claims
+owned or controlled by the contributor, whether already acquired or
+hereafter acquired, that would be infringed by some manner, permitted
+by this License, of making, using, or selling its contributor version,
+but do not include claims that would be infringed only as a
+consequence of further modification of the contributor version.  For
+purposes of this definition, "control" includes the right to grant
+patent sublicenses in a manner consistent with the requirements of
+this License.
+
+  Each contributor grants you a non-exclusive, worldwide, royalty-free
+patent license under the contributor's essential patent claims, to
+make, use, sell, offer for sale, import and otherwise run, modify and
+propagate the contents of its contributor version.
+
+  In the following three paragraphs, a "patent license" is any express
+agreement or commitment, however denominated, not to enforce a patent
+(such as an express permission to practice a patent or covenant not to
+sue for patent infringement).  To "grant" such a patent license to a
+party means to make such an agreement or commitment not to enforce a
+patent against the party.
+
+  If you convey a covered work, knowingly relying on a patent license,
+and the Corresponding Source of the work is not available for anyone
+to copy, free of charge and under the terms of this License, through a
+publicly available network server or other readily accessible means,
+then you must either (1) cause the Corresponding Source to be so
+available, or (2) arrange to deprive yourself of the benefit of the
+patent license for this particular work, or (3) arrange, in a manner
+consistent with the requirements of this License, to extend the patent
+license to downstream recipients.  "Knowingly relying" means you have
+actual knowledge that, but for the patent license, your conveying the
+covered work in a country, or your recipient's use of the covered work
+in a country, would infringe one or more identifiable patents in that
+country that you have reason to believe are valid.
+
+  If, pursuant to or in connection with a single transaction or
+arrangement, you convey, or propagate by procuring conveyance of, a
+covered work, and grant a patent license to some of the parties
+receiving the covered work authorizing them to use, propagate, modify
+or convey a specific copy of the covered work, then the patent license
+you grant is automatically extended to all recipients of the covered
+work and works based on it.
+
+  A patent license is "discriminatory" if it does not include within
+the scope of its coverage, prohibits the exercise of, or is
+conditioned on the non-exercise of one or more of the rights that are
+specifically granted under this License.  You may not convey a covered
+work if you are a party to an arrangement with a third party that is
+in the business of distributing software, under which you make payment
+to the third party based on the extent of your activity of conveying
+the work, and under which the third party grants, to any of the
+parties who would receive the covered work from you, a discriminatory
+patent license (a) in connection with copies of the covered work
+conveyed by you (or copies made from those copies), or (b) primarily
+for and in connection with specific products or compilations that
+contain the covered work, unless you entered into that arrangement,
+or that patent license was granted, prior to 28 March 2007.
+
+  Nothing in this License shall be construed as excluding or limiting
+any implied license or other defenses to infringement that may
+otherwise be available to you under applicable patent law.
+
+  12. No Surrender of Others' Freedom.
+
+  If conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot convey a
+covered work so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you may
+not convey it at all.  For example, if you agree to terms that obligate you
+to collect a royalty for further conveying from those to whom you convey
+the Program, the only way you could satisfy both those terms and this
+License would be to refrain entirely from conveying the Program.
+
+  13. Remote Network Interaction; Use with the GNU General Public License.
+
+  Notwithstanding any other provision of this License, if you modify the
+Program, your modified version must prominently offer all users
+interacting with it remotely through a computer network (if your version
+supports such interaction) an opportunity to receive the Corresponding
+Source of your version by providing access to the Corresponding Source
+from a network server at no charge, through some standard or customary
+means of facilitating copying of software.  This Corresponding Source
+shall include the Corresponding Source for any work covered by version 3
+of the GNU General Public License that is incorporated pursuant to the
+following paragraph.
+
+  Notwithstanding any other provision of this License, you have
+permission to link or combine any covered work with a work licensed
+under version 3 of the GNU General Public License into a single
+combined work, and to convey the resulting work.  The terms of this
+License will continue to apply to the part which is the covered work,
+but the work with which it is combined will remain governed by version
+3 of the GNU General Public License.
+
+  14. Revised Versions of this License.
+
+  The Free Software Foundation may publish revised and/or new versions of
+the GNU Affero General Public License from time to time.  Such new versions
+will be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+  Each version is given a distinguishing version number.  If the
+Program specifies that a certain numbered version of the GNU Affero General
+Public License "or any later version" applies to it, you have the
+option of following the terms and conditions either of that numbered
+version or of any later version published by the Free Software
+Foundation.  If the Program does not specify a version number of the
+GNU Affero General Public License, you may choose any version ever published
+by the Free Software Foundation.
+
+  If the Program specifies that a proxy can decide which future
+versions of the GNU Affero General Public License can be used, that proxy's
+public statement of acceptance of a version permanently authorizes you
+to choose that version for the Program.
+
+  Later license versions may give you additional or different
+permissions.  However, no additional obligations are imposed on any
+author or copyright holder as a result of your choosing to follow a
+later version.
+
+  15. Disclaimer of Warranty.
+
+  THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
+OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
+THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
+IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
+ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+  16. Limitation of Liability.
+
+  IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
+THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
+GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
+USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
+DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
+EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGES.
+
+  17. Interpretation of Sections 15 and 16.
+
+  If the disclaimer of warranty and limitation of liability provided
+above cannot be given local legal effect according to their terms,
+reviewing courts shall apply local law that most closely approximates
+an absolute waiver of all civil liability in connection with the
+Program, unless a warranty or assumption of liability accompanies a
+copy of the Program in return for a fee.
+
+                     END OF TERMS AND CONDITIONS
+
+            How to Apply These Terms to Your New Programs
+
+  If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+  To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+state the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This program is free software: you can redistribute it and/or modify
+    it under the terms of the GNU Affero General Public License as published by
+    the Free Software Foundation, either version 3 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU Affero General Public License for more details.
+
+    You should have received a copy of the GNU Affero General Public License
+    along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+Also add information on how to contact you by electronic and paper mail.
+
+  If your software can interact with users remotely through a computer
+network, you should also make sure that it provides a way for users to
+get its source.  For example, if your program is a web application, its
+interface could display a "Source" link that leads users to an archive
+of the code.  There are many ways you could offer source, and different
+solutions will be better for different programs; see section 13 for the
+specific requirements.
+
+  You should also get your employer (if you work as a programmer) or school,
+if any, to sign a "copyright disclaimer" for the program, if necessary.
+For more information on this, and how to apply and follow the GNU AGPL, see
+<https://www.gnu.org/licenses/>.

README.ja.md

@@ -1,167 +0,0 @@
-<p align="center">
-  <img src="packages/website/public/logo.svg" width="64" height="64" alt="Paseo logo">
-</p>
-
-<h1 align="center">Paseo</h1>
-
-<p align="center">
-  <a href="README.md">English</a> ·
-  <a href="README.zh-CN.md">简体中文</a> ·
-  <a href="README.ja.md">日本語</a> ·
-  <a href="README.ko.md">한국어</a>
-</p>
-
-<p align="center">
-  <a href="https://github.com/getpaseo/paseo/stargazers">
-    <img src="https://img.shields.io/github/stars/getpaseo/paseo?style=flat&logo=github" alt="GitHub stars">
-  </a>
-  <a href="https://github.com/getpaseo/paseo/releases">
-    <img src="https://img.shields.io/github/v/release/getpaseo/paseo?style=flat&logo=github" alt="GitHub release">
-  </a>
-  <a href="https://x.com/moboudra">
-    <img src="https://img.shields.io/badge/%40moboudra-555?logo=x" alt="X">
-  </a>
-  <a href="https://discord.gg/jz8T2uahpH">
-    <img src="https://img.shields.io/badge/Discord-555?logo=discord" alt="Discord">
-  </a>
-  <a href="https://www.reddit.com/r/PaseoAI/">
-    <img src="https://img.shields.io/badge/Reddit-555?logo=reddit" alt="Reddit">
-  </a>
-</p>
-
-<p align="center">Claude Code、Codex、Copilot、OpenCode、Pi のエージェントを、ひとつのインターフェースで。</p>
-
-<p align="center">
-  <img src="https://paseo.sh/hero-mockup.png" alt="Paseo アプリのスクリーンショット" width="100%">
-</p>
-
-<p align="center">
-  <img src="https://paseo.sh/mobile-mockup.png" alt="Paseo モバイルアプリ" width="100%">
-</p>
-
-> [!NOTE]
-> 私はひとりでメンテナンスしているため、GitHub Issues を毎日確認できるとは限りません。
-> 急ぎの問題や作業がブロックされている場合は、[Discord](https://discord.gg/jz8T2uahpH) から連絡するのが一番早いです。
-
----
-
-自分のマシンでエージェントを並列実行。スマートフォンからでもデスクからでも、開発を進めてリリースできます。
-
-- **セルフホスト:** エージェントはあなたのマシン上で動作し、完全な開発環境を使用します。自分のツール・設定・スキルをそのまま活用できます。
-- **マルチプロバイダー:** Claude Code、Codex、Copilot、OpenCode、Pi を同一のインターフェースで利用。タスクに合ったモデルを選べます。
-- **音声コントロール:** 音声モードでタスクを口述したり問題を話し合ったりできます。ハンズフリーが必要なときに便利です。
-- **クロスデバイス:** iOS、Android、デスクトップ、Web、CLI に対応。机で作業を始め、スマートフォンで確認し、ターミナルから自動化できます。
-- **プライバシー優先:** Paseo にはテレメトリー・トラッキング・強制ログインは一切ありません。
-
-## はじめかた
-
-Paseo はコーディングエージェントを管理するローカルサーバー（デーモン）を起動します。デスクトップアプリ・モバイルアプリ・Web アプリ・CLI などのクライアントがこのデーモンに接続します。
-
-### 前提条件
-
-エージェント CLI をひとつ以上インストールし、認証情報を設定しておく必要があります。
-
-- [Claude Code](https://docs.anthropic.com/en/docs/claude-code)
-- [Codex](https://github.com/openai/codex)
-- [GitHub Copilot](https://github.com/features/copilot/cli/)
-- [OpenCode](https://github.com/anomalyco/opencode)
-- [Pi](https://pi.dev)
-
-### デスクトップアプリ（推奨）
-
-[paseo.sh/download](https://paseo.sh/download) または [GitHub のリリースページ](https://github.com/getpaseo/paseo/releases)からダウンロードしてください。アプリを開くとデーモンが自動的に起動します。追加のインストールは不要です。
-
-スマートフォンから接続するには、Settings 画面に表示される QR コードをスキャンしてください。
-
-### CLI / ヘッドレス
-
-CLI をインストールして Paseo を起動します。
-
-```bash
-npm install -g @getpaseo/cli
-paseo
-```
-
-ターミナルに QR コードが表示されます。どのクライアントからでも接続できます。サーバーやリモートマシンでの利用に適しています。
-
-詳しいセットアップと設定については以下を参照してください。
-
-- [ドキュメント](https://paseo.sh/docs)
-- [設定リファレンス](https://paseo.sh/docs/configuration)
-
-## CLI
-
-アプリでできることはすべてターミナルからも実行できます。
-
-```bash
-paseo run --provider claude/opus-4.6 "implement user authentication"
-paseo run --provider codex/gpt-5.4 --worktree feature-x "implement feature X"
-
-paseo ls                           # 実行中のエージェントを一覧表示
-paseo attach abc123                # ライブ出力をストリーミング
-paseo send abc123 "also add tests" # 追加タスクを送信
-
-# リモートデーモンで実行
-paseo --host workstation.local:6767 run "run the full test suite"
-```
-
-詳細は[完全な CLI リファレンス](https://paseo.sh/docs/cli)を参照してください。
-
-## スキル
-
-スキルはエージェントに Paseo を使って他のエージェントをオーケストレーションする方法を教えます。
-
-```bash
-npx skills add getpaseo/paseo
-```
-
-どのエージェントとの会話でも使用できます。
-
-- `/paseo-handoff` — エージェント間で作業を引き継ぎます。私はこれを使って Claude で計画し、Codex に実装を引き継いでいます。
-- `/paseo-advisor` — 単一のエージェントをアドバイザーとして起動し、作業を委任せずにセカンドオピニオンを得ます。
-- `/paseo-committee` — 対照的な2つのエージェントで委員会を構成し、一歩引いた視点で根本原因を分析して計画を作成します。
-
-## 開発
-
-モノレポのパッケージ構成：
-
-- `packages/server`: Paseo デーモン（エージェントプロセスのオーケストレーション、WebSocket API、MCP サーバー）
-- `packages/app`: Expo クライアント（iOS、Android、Web）
-- `packages/cli`: デーモンおよびエージェントワークフロー向け `paseo` CLI
-- `packages/desktop`: Electron デスクトップアプリ
-- `packages/relay`: リモート接続用リレーパッケージ
-- `packages/website`: マーケティングサイトとドキュメント（`paseo.sh`）
-
-よく使うコマンド：
-
-```bash
-# すべてのローカル開発サービスを起動
-npm run dev
-
-# 個別のサービスを起動
-npm run dev:server
-npm run dev:app
-npm run dev:desktop
-npm run dev:website
-
-# サーバースタックをビルド
-npm run build:server
-
-# リポジトリ全体のチェック
-npm run typecheck
-```
-
-## スポンサー
-
-Paseo は一人で開発しており、使ってくれる人たちの支援で成り立っています。[GitHub Sponsors](https://github.com/sponsors/boudra) で支援できます。企業として毎月[スポンサー](https://paseo.sh/sponsor#spot)になっていただくと、ロゴをここと paseo.sh のホームページに掲載します。
-
-<!-- Sponsor logos go here, in the same order as packages/website/src/data/sponsors.ts -->
-
-## 関連プロジェクト
-
-- [getpaseo/paseo-relay](https://github.com/getpaseo/paseo-relay) — Elixir 製の公式分散リレー
-- [paseo-vscode](https://marketplace.visualstudio.com/items?itemName=hinnes.paseo-vscode) — VS Code 拡張機能
-
-## ライセンス
-
-Apache-2.0

README.ko.md

@@ -1,178 +0,0 @@
-<p align="center">
-  <img src="packages/website/public/logo.svg" width="64" height="64" alt="Paseo 로고">
-</p>
-
-<h1 align="center">Paseo</h1>
-
-<p align="center">
-  <a href="README.md">English</a> ·
-  <a href="README.zh-CN.md">简体中文</a> ·
-  <a href="README.ja.md">日本語</a> ·
-  <a href="README.ko.md">한국어</a>
-</p>
-
-<p align="center">
-  <a href="https://github.com/getpaseo/paseo/stargazers">
-    <img src="https://img.shields.io/github/stars/getpaseo/paseo?style=flat&logo=github" alt="GitHub stars">
-  </a>
-  <a href="https://github.com/getpaseo/paseo/releases">
-    <img src="https://img.shields.io/github/v/release/getpaseo/paseo?style=flat&logo=github" alt="GitHub release">
-  </a>
-  <a href="https://x.com/moboudra">
-    <img src="https://img.shields.io/badge/%40moboudra-555?logo=x" alt="X">
-  </a>
-  <a href="https://discord.gg/jz8T2uahpH">
-    <img src="https://img.shields.io/badge/Discord-555?logo=discord" alt="Discord">
-  </a>
-  <a href="https://www.reddit.com/r/PaseoAI/">
-    <img src="https://img.shields.io/badge/Reddit-555?logo=reddit" alt="Reddit">
-  </a>
-</p>
-
-<p align="center">Claude Code, Codex, Copilot, OpenCode, Pi 에이전트를 위한 하나의 인터페이스</p>
-
-<p align="center">
-  <img src="https://paseo.sh/hero-mockup.png" alt="Paseo app screenshot" width="100%">
-</p>
-
-<p align="center">
-  <img src="https://paseo.sh/mobile-mockup.png" alt="Paseo mobile app" width="100%">
-</p>
-
-내 컴퓨터에서 에이전트를 병렬로 실행하세요. 데스크톱이나 휴대폰에서 배포하세요.
-
-- **셀프 호스팅:** 에이전트는 완전한 개발 환경이 갖춰진 내 컴퓨터에서 실행됩니다. 평소 쓰던 도구, 설정, 스킬을 그대로 쓸 수 있습니다.
-- **여러 제공자 지원:** Claude Code, Codex, Copilot, OpenCode, Pi를 하나의 인터페이스에서 사용할 수 있습니다. 작업마다 알맞은 모델을 고를 수 있습니다.
-- **음성 제어:** 음성 모드에서 작업을 말로 지시하거나 문제를 음성으로 함께 검토할 수 있습니다. 손을 쓰지 않고 작업해야 할 때 유용합니다.
-- **여러 기기 지원:** iOS, Android, 데스크톱, 웹, CLI를 지원합니다. 데스크톱에서 시작해 휴대폰으로 확인하고 터미널에서 자동화할 수 있습니다.
-- **개인정보 보호 우선:** Paseo는 텔레메트리, 추적, 강제 로그인을 사용하지 않습니다.
-
-## 시작하기
-
-Paseo는 코딩 에이전트를 관리하는 로컬 서버인 데몬을 실행합니다. 데스크톱 앱, 모바일 앱, 웹 앱, CLI 같은 클라이언트가 이 데몬에 연결합니다.
-
-### 준비 사항
-
-아래 에이전트 CLI 중 하나 이상을 설치하고 인증 정보를 설정해야 합니다.
-
-- [Claude Code](https://docs.anthropic.com/en/docs/claude-code)
-- [Codex](https://github.com/openai/codex)
-- [GitHub Copilot](https://github.com/features/copilot/cli/)
-- [OpenCode](https://github.com/anomalyco/opencode)
-- [Pi](https://pi.dev)
-
-### 데스크톱 앱(권장)
-
-[paseo.sh/download](https://paseo.sh/download) 또는 [GitHub 릴리스 페이지](https://github.com/getpaseo/paseo/releases)에서 다운로드하세요. 앱을 열면 데몬이 자동으로 시작됩니다. 별도로 설치할 것은 없습니다.
-
-휴대폰에서 연결하려면 **설정 → 호스트 → 기기 페어링**을 여세요.
-
-### CLI / 헤드리스 환경
-
-CLI를 설치하고 Paseo를 시작하세요.
-
-```bash
-npm install -g @getpaseo/cli
-paseo
-```
-
-Paseo가 로컬에서 시작된 뒤 기기 페어링을 위한 종단 간 암호화 릴레이를 켤지 묻습니다. 거절하면 TCP, Tailscale 또는 다른 VPN으로 직접 연결할 수 있습니다. 이 방식은 서버나 원격 머신에서 유용합니다.
-
-자세한 설치와 설정은 아래 문서를 참고하세요.
-
-- [문서](https://paseo.sh/docs)
-- [연결 가이드](https://paseo.sh/docs/connectivity)
-- [설정 레퍼런스](https://paseo.sh/docs/configuration)
-
-### Docker
-
-Docker에서 Paseo 데몬과 셀프 호스팅 웹 UI를 실행하세요:
-
-```bash
-docker run -d --name paseo \
-  -p 6767:6767 \
-  -e PASEO_PASSWORD=change-me \
-  -v "$PWD/paseo-home:/home/paseo" \
-  -v "$PWD:/workspace" \
-  ghcr.io/getpaseo/paseo:latest
-```
-
-컨테이너가 시작되면 `http://localhost:6767`을 여세요. 사용하는 에이전트 CLI를 기본 이미지에 추가한 뒤, 환경 변수나 영구 `/home/paseo` 볼륨으로 인증 정보를 설정하세요. 자세한 내용은 [Docker 문서](docs/docker.md)를 참고하세요.
-
-## CLI
-
-앱에서 할 수 있는 모든 작업은 터미널에서도 할 수 있습니다.
-
-```bash
-paseo run --provider claude/opus-4.6 "implement user authentication"
-paseo run --provider codex/gpt-5.4 --worktree feature-x "implement feature X"
-
-paseo ls                           # 실행 중인 에이전트 목록
-paseo attach abc123                # 실시간 출력 스트리밍
-paseo send abc123 "also add tests" # 후속 작업 전송
-
-# 원격 데몬에서 실행
-paseo --host workstation.local:6767 run "run the full test suite"
-```
-
-자세한 내용은 [전체 CLI 레퍼런스](https://paseo.sh/docs/cli)를 참고하세요.
-
-## 스킬
-
-스킬은 에이전트가 Paseo를 통해 다른 에이전트를 오케스트레이션하는 방법을 알려 줍니다.
-
-```bash
-npx skills add getpaseo/paseo
-```
-
-그런 다음 어떤 에이전트 대화에서든 아래 명령을 사용할 수 있습니다.
-
-- `/paseo-handoff` — 에이전트 간에 작업을 넘깁니다. Claude로 계획을 세운 뒤 Codex에 구현을 넘길 때 이 기능을 씁니다.
-- `/paseo-advisor` — 작업 자체를 넘기지 않고, 에이전트 하나를 조언자로 띄워 두 번째 의견을 받습니다.
-- `/paseo-committee` — 서로 다른 관점의 에이전트 두 개로 위원회를 구성해, 한 발 물러나 근본 원인을 분석하고 계획을 세웁니다.
-
-## 개발
-
-모노레포 패키지 구성은 다음과 같습니다.
-
-- `packages/server`: Paseo 데몬(에이전트 프로세스 오케스트레이션, WebSocket API, MCP 서버 제공)
-- `packages/app`: Expo 클라이언트(iOS, Android, 웹)
-- `packages/cli`: `paseo` CLI(데몬과 에이전트 워크플로)
-- `packages/desktop`: Electron 데스크톱 앱
-- `packages/relay`: 데몬과 클라이언트가 쓰는 릴레이 전송 및 암호화 패키지
-- `packages/website`: 마케팅 사이트 및 문서(`paseo.sh`)
-
-자주 쓰는 명령:
-
-```bash
-# 모든 로컬 개발 서비스 실행
-npm run dev
-
-# 개별 환경 실행
-npm run dev:server
-npm run dev:app
-npm run dev:desktop
-npm run dev:website
-
-# 서버 스택 빌드
-npm run build:server
-
-# 레포 전체 검사 실행
-npm run typecheck
-```
-
-## 스폰서
-
-Paseo는 한 사람이 개발하며, 사용하는 분들의 후원으로 운영됩니다. [GitHub Sponsors](https://github.com/sponsors/boudra)로 후원할 수 있습니다. 회사는 매월 [Paseo를 후원](https://paseo.sh/sponsor#spot)하고 로고를 이곳과 paseo.sh 홈페이지에 게재할 수 있습니다.
-
-<!-- Sponsor logos go here, in the same order as packages/website/src/data/sponsors.ts -->
-
-## 관련 프로젝트
-
-- [getpaseo/paseo-relay](https://github.com/getpaseo/paseo-relay) — Elixir로 작성한 공식 분산형 릴레이
-- [paseo-skins](https://github.com/huangguang1999/paseo-skins) — 커뮤니티 테마와 Agent Skill을 제공하고, 코드 수정 없이 쓸 수 있는 데스크톱 테마 로더
-- [paseo-vscode](https://marketplace.visualstudio.com/items?itemName=hinnes.paseo-vscode) — VS Code 확장 프로그램
-
-## 라이선스
-
-Apache-2.0

README.md

@@ -4,32 +4,7 @@
 
 <h1 align="center">Paseo</h1>
 
-<p align="center">
-  <a href="README.md">English</a> ·
-  <a href="README.zh-CN.md">简体中文</a> ·
-  <a href="README.ja.md">日本語</a> ·
-  <a href="README.ko.md">한국어</a>
-</p>
-
-<p align="center">
-  <a href="https://github.com/getpaseo/paseo/stargazers">
-    <img src="https://img.shields.io/github/stars/getpaseo/paseo?style=flat&logo=github" alt="GitHub stars">
-  </a>
-  <a href="https://github.com/getpaseo/paseo/releases">
-    <img src="https://img.shields.io/github/v/release/getpaseo/paseo?style=flat&logo=github" alt="GitHub release">
-  </a>
-  <a href="https://x.com/moboudra">
-    <img src="https://img.shields.io/badge/%40moboudra-555?logo=x" alt="X">
-  </a>
-  <a href="https://discord.gg/jz8T2uahpH">
-    <img src="https://img.shields.io/badge/Discord-555?logo=discord" alt="Discord">
-  </a>
-  <a href="https://www.reddit.com/r/PaseoAI/">
-    <img src="https://img.shields.io/badge/Reddit-555?logo=reddit" alt="Reddit">
-  </a>
-</p>
-
-<p align="center">One interface for Claude Code, Codex, Copilot, OpenCode, Pi, Antigravity, and Muse Code agents.</p>
+<p align="center">One interface for all your Claude Code, Codex and OpenCode agents.</p>
 
 <p align="center">
   <img src="https://paseo.sh/hero-mockup.png" alt="Paseo app screenshot" width="100%">
@@ -39,34 +14,16 @@
   <img src="https://paseo.sh/mobile-mockup.png" alt="Paseo mobile app" width="100%">
 </p>
 
-Paseo is an open source agentic development environment for desktop, mobile, web, and CLI. Open the desktop app and work: agents, editor, terminals, diffs, pull requests, and a browser in one window. Run many agents at once, each in its own worktree, on one machine or several. The mobile app is the full app, native on iOS and Android.
+---
+
+Run agents in parallel on your own machines. Ship from your phone or your desk.
 
-- **Parallel agents:** Run many agents at once, each in its own worktree.
-- **Built-in orchestration:** Agents in Paseo can create worktrees, launch other agents, and talk to them, across providers.
-- **Complete development workflow:** Edit files, review diffs, open pull requests, and run terminals, in split panes you arrange how you want.
 - **Self-hosted:** Agents run on your machine with your full dev environment. Use your tools, your configs, and your skills.
-- **Multi-provider:** Claude Code, Codex, Copilot, OpenCode, Pi, Antigravity, and Muse Code through the same interface. Pick the right model for each job.
+- **Multi-provider:** Claude Code, Codex, and OpenCode through the same interface. Pick the right model for each job.
 - **Voice control:** Dictate tasks or talk through problems in voice mode. Hands-free when you need it.
 - **Cross-device:** iOS, Android, desktop, web, and CLI. Start work at your desk, check in from your phone, script it from the terminal.
 - **Privacy-first:** Paseo doesn't have any telemetry, tracking, or forced log-ins.
 
-[Run parallel tasks in Paseo](https://paseo.sh/docs/parallel-development): start agents in separate worktrees, review their diffs, run each app, and check it in the built-in browser.
-
-## Plugins
-
-Plugins run on the daemon and show up in every client you connect, with the same UI on desktop, web,
-iOS, and Android. Write a plugin once and it is on your phone.
-
-- **UI:** screens, sidebar items, workspace panels, Command Center items, slash commands, composer pills, attachment sources, timeline items, themes.
-- **Agent lifecycle:** change configuration, environment, and MCP servers, answer permissions, follow up when a turn ends.
-- **Providers:** add a coding agent as a provider.
-
-Install from the registry with `paseo plugin add owner/slug`, or from Git or a local directory.
-
-**[Browse plugins](https://paseo.sh/plugins)** · **[Plugin docs](https://paseo.sh/docs/plugins)**
-
-Plugins run with access to your daemon machine and inside connected clients; install only code you trust.
-
 ## Getting Started
 
 Paseo runs a local server called the daemon that manages your coding agents. Clients like the desktop app, mobile app, web app, and CLI connect to it.
@@ -77,95 +34,50 @@ You need at least one agent CLI installed and configured with your credentials:
 
 - [Claude Code](https://docs.anthropic.com/en/docs/claude-code)
 - [Codex](https://github.com/openai/codex)
-- [GitHub Copilot](https://github.com/features/copilot/cli/)
 - [OpenCode](https://github.com/anomalyco/opencode)
-- [Pi](https://pi.dev)
-- [Antigravity](https://paseo.sh/docs/supported-providers#antigravity)
-- [Muse Code](https://paseo.sh/docs/muse-code)
 
 ### Desktop app (recommended)
 
 Download it from [paseo.sh/download](https://paseo.sh/download) or the [GitHub releases page](https://github.com/getpaseo/paseo/releases). Open the app and the daemon starts automatically. Nothing else to install.
 
-To connect from your phone, open **Settings → your host → Pair Device**.
+To connect from your phone, scan the QR code shown in Settings.
 
-### Server
+### CLI / headless
 
-For a server, a VM, or any machine without the desktop app. Install the CLI and start the daemon:
+Install the CLI and start Paseo:
 
 ```bash
 npm install -g @getpaseo/cli
 paseo
 ```
 
-Paseo starts, then asks whether to enable the end-to-end encrypted relay for device pairing. If you decline, connect directly over TCP, Tailscale, or another VPN. The desktop, mobile, and web apps connect to this daemon like any other host.
+This shows a QR code in the terminal. Connect from any client. This path is useful for servers and remote machines.
 
 For full setup and configuration, see:
-
 - [Docs](https://paseo.sh/docs)
-- [Connectivity guide](https://paseo.sh/docs/connectivity)
 - [Configuration reference](https://paseo.sh/docs/configuration)
 
-### Docker
-
-Run the Paseo daemon and self-hosted web UI in Docker:
-
-```bash
-docker run -d --name paseo \
-  -p 6767:6767 \
-  -e PASEO_PASSWORD=change-me \
-  -v "$PWD/paseo-home:/home/paseo" \
-  -v "$PWD:/workspace" \
-  ghcr.io/getpaseo/paseo:latest
-```
-
-Open `http://localhost:6767` after it starts. Extend the base image with the agent CLIs you use, then provide credentials through environment variables or the persistent `/home/paseo` volume. See the [Docker documentation](docs/docker.md) for full setup details.
-
 ## CLI
 
 Everything you can do in the app, you can do from the terminal.
 
 ```bash
 paseo run --provider claude/opus-4.6 "implement user authentication"
-paseo run --provider codex/gpt-5.5 --worktree feature-x "implement feature X"
+paseo run --provider codex/gpt-5.4 --worktree feature-x "implement feature X"
 
 paseo ls                           # list running agents
 paseo attach abc123                # stream live output
 paseo send abc123 "also add tests" # follow-up task
 
-# run on a remote daemon; --cwd is a path on that host
-paseo run --host workstation.local:6767 --cwd /workspace "run the full test suite"
+# run on a remote daemon
+paseo --host workstation.local:6767 run "run the full test suite"
 ```
 
 See the [full CLI reference](https://paseo.sh/docs/cli) for more.
 
-## TypeScript SDK
+## Orchestration skills (Unstable)
 
-Build issue integrations, dashboards, and orchestration services with `@getpaseo/client`:
-
-```ts
-import { createPaseoClient } from "@getpaseo/client";
-
-const client = createPaseoClient({ url: "ws://127.0.0.1:6767/ws" });
-await client.connect();
-
-const agent = await client.agents.create({
-  config: { provider: "codex/gpt-5.5" },
-  cwd: "/Users/me/dev/storefront",
-  prompt: "Review the current diff and name the riskiest change.",
-});
-
-const result = await agent.waitForFinish();
-console.log(result.lastMessage);
-
-await client.close();
-```
-
-See the [SDK quickstart](https://paseo.sh/docs/sdk/quickstart), [recipes](https://paseo.sh/docs/sdk/recipes), and [API reference](https://paseo.sh/docs/sdk/reference).
-
-## Skills
-
-Skills teach your agent to use Paseo to orchestrate other agents.
+Experimental skills that teach agents how to use the Paseo CLI to orchestrate other agents. I am updating these very frequently as I learn new things, expect changes without notice, might be coupled to my own setup, use at your own risk.
 
 ```bash
 npx skills add getpaseo/paseo
@@ -173,19 +85,27 @@ npx skills add getpaseo/paseo
 
 Then use them in any agent conversation:
 
-- `/paseo-handoff` — hand off work between agents. I use this to plan with Claude and then handoff to Codex to implement.
-- `/paseo-advisor` — spin up a single agent as an advisor for a second opinion, without delegating the work itself.
-- `/paseo-committee` — form a committee of two contrasting agents to step back, do root cause analysis, and produce a plan.
+```bash
+# Use handoff when you discuss something with an agent but want another one to implement.
+# I use this to plan with Claude and then handoff to Codex to implement.
+/paseo-handoff hand off the authentication fix to codex 5.4 in a worktree
+
+# Use loops when you have clear acceptance criteria (aka Ralph loops).
+/paseo-loop loop a codex agent to fix the backend tests, use sonnet to verify, max 10 iterations
+
+# Orchestrator teaches the agent how to create teams and manage them via a chat room.
+# Very opinionated and expects both Codex and Claude to work.
+/paseo-orchestrator spin up a team to implement the database refactor, use chat to coordinate. use claude to plan and codex to implement and review
+```
 
 ## Development
 
 Quick monorepo package map:
-
 - `packages/server`: Paseo daemon (agent process orchestration, WebSocket API, MCP server)
 - `packages/app`: Expo client (iOS, Android, web)
 - `packages/cli`: `paseo` CLI for daemon and agent workflows
 - `packages/desktop`: Electron desktop app
-- `packages/relay`: Relay transport and encryption used by the daemon and clients
+- `packages/relay`: Relay package for remote connectivity
 - `packages/website`: Marketing site and documentation (`paseo.sh`)
 
 Common commands:
@@ -200,24 +120,13 @@ npm run dev:app
 npm run dev:desktop
 npm run dev:website
 
-# build the server stack
-npm run build:server
+# build the daemon
+npm run build:daemon
 
 # repo-wide checks
 npm run typecheck
 ```
 
-## Sponsors
-
-Paseo is an independent project used by tens of thousands of developers daily, built by one person and funded by the people who use it. Support the work on [GitHub Sponsors](https://github.com/sponsors/boudra). Companies can [sponsor Paseo](https://paseo.sh/sponsor#spot) monthly and have their logo shown here and on the paseo.sh homepage.
-
-<!-- Sponsor logos go here, in the same order as packages/website/src/data/sponsors.ts -->
-
-## Related projects
-
-- [getpaseo/paseo-relay](https://github.com/getpaseo/paseo-relay) — official distributed relay, written in Elixir
-- [paseo-vscode](https://marketplace.visualstudio.com/items?itemName=hinnes.paseo-vscode) — VS Code extension
-
 ## License
 
-Apache-2.0
+AGPL-3.0

README.zh-CN.md

@@ -1,213 +0,0 @@
-<p align="center">
-  <img src="packages/website/public/logo.svg" width="64" height="64" alt="Paseo logo">
-</p>
-
-<h1 align="center">Paseo</h1>
-
-<p align="center">
-  <a href="README.md">English</a> ·
-  <a href="README.zh-CN.md">简体中文</a> ·
-  <a href="README.ja.md">日本語</a> ·
-  <a href="README.ko.md">한국어</a>
-</p>
-
-<p align="center">
-  <a href="https://github.com/getpaseo/paseo/stargazers">
-    <img src="https://img.shields.io/github/stars/getpaseo/paseo?style=flat&logo=github" alt="GitHub stars">
-  </a>
-  <a href="https://github.com/getpaseo/paseo/releases">
-    <img src="https://img.shields.io/github/v/release/getpaseo/paseo?style=flat&logo=github" alt="GitHub release">
-  </a>
-  <a href="https://x.com/moboudra">
-    <img src="https://img.shields.io/badge/%40moboudra-555?logo=x" alt="X">
-  </a>
-  <a href="https://discord.gg/jz8T2uahpH">
-    <img src="https://img.shields.io/badge/Discord-555?logo=discord" alt="Discord">
-  </a>
-  <a href="https://www.reddit.com/r/PaseoAI/">
-    <img src="https://img.shields.io/badge/Reddit-555?logo=reddit" alt="Reddit">
-  </a>
-</p>
-
-<p align="center">Claude Code、Codex、Copilot、OpenCode 和 Pi agents 的统一界面。</p>
-
-<p align="center">
-  <img src="https://paseo.sh/hero-mockup.png" alt="Paseo app screenshot" width="100%">
-</p>
-
-<p align="center">
-  <img src="https://paseo.sh/mobile-mockup.png" alt="Paseo mobile app" width="100%">
-</p>
-
-> [!NOTE]
-> 我是独立维护者，不一定每天都能及时处理 GitHub Issues。
-> 如果问题很紧急或阻塞了你，[Discord](https://discord.gg/jz8T2uahpH) 是最快联系到我的地方。
-
----
-
-在你自己的机器上并行运行 agents。无论在手机上还是桌前，都能推进交付。
-
-- **自托管：** Agents 在你的机器上运行，使用完整的本地开发环境、工具、配置和技能。
-- **多提供商：** 通过同一个界面使用 Claude Code、Codex、Copilot、OpenCode 和 Pi。为每个任务选择合适的模型。
-- **语音控制：** 在语音模式下口述任务或讨论问题。需要免手操作时很方便。
-- **跨设备：** 支持 iOS、Android、桌面端、Web 和 CLI。在桌前开始工作，用手机查看进度，也可以从终端脚本化操作。
-- **隐私优先：** Paseo 没有遥测、追踪，也不会强制登录。
-
-## 快速开始
-
-Paseo 会运行一个名为 daemon 的本地服务，用来管理你的 coding agents。桌面 app、移动 app、Web app 和 CLI 等客户端都会连接到它。
-
-### 前置条件
-
-你至少需要安装一个 agent CLI，并用你的凭据完成配置：
-
-- [Claude Code](https://docs.anthropic.com/en/docs/claude-code)
-- [Codex](https://github.com/openai/codex)
-- [GitHub Copilot](https://github.com/features/copilot/cli/)
-- [OpenCode](https://github.com/anomalyco/opencode)
-- [Pi](https://pi.dev)
-
-### 桌面 app（推荐）
-
-从 [paseo.sh/download](https://paseo.sh/download) 或 [GitHub releases 页面](https://github.com/getpaseo/paseo/releases)下载。打开 app 后 daemon 会自动启动，不需要再安装其他东西。
-
-如果要从手机连接，在 Settings 中扫描显示的二维码。
-
-### CLI / 无头模式
-
-安装 CLI 并启动 Paseo：
-
-```bash
-npm install -g @getpaseo/cli
-paseo
-```
-
-终端中会显示一个二维码。你可以从任意客户端连接。这个方式适合服务器和远程机器。
-
-完整安装和配置见：
-
-- [文档](https://paseo.sh/docs)
-- [配置参考](https://paseo.sh/docs/configuration)
-
-## CLI
-
-你能在 app 中完成的事情，也都可以在终端中完成。
-
-```bash
-paseo run --provider claude/opus-4.6 "implement user authentication"
-paseo run --provider codex/gpt-5.4 --worktree feature-x "implement feature X"
-
-paseo ls                           # 列出正在运行的 agents
-paseo attach abc123                # 实时流式查看输出
-paseo send abc123 "also add tests" # 发送后续任务
-
-# 在远程 daemon 上运行
-paseo --host workstation.local:6767 run "run the full test suite"
-```
-
-更多内容见[完整 CLI 参考](https://paseo.sh/docs/cli)。
-
-## Skills
-
-Skills 会教你的 agent 使用 Paseo 来编排其他 agents。
-
-```bash
-npx skills add getpaseo/paseo
-```
-
-然后在任意 agent 对话中使用：
-
-- `/paseo-handoff` — 在 agents 之间交接工作。我会用它先和 Claude 规划，再交给 Codex 实现。
-- `/paseo-advisor` — 启动单个 agent 作为 advisor，提供第二意见，但不把工作委托出去。
-- `/paseo-committee` — 组建两个风格互补的 agents，让它们后退一步做根因分析并产出计划。
-
-## 开发
-
-Monorepo 包结构速览：
-
-- `packages/server`：Paseo daemon（agent 进程编排、WebSocket API、MCP server）
-- `packages/app`：Expo 客户端（iOS、Android、Web）
-- `packages/cli`：用于 daemon 和 agent 工作流的 `paseo` CLI
-- `packages/desktop`：Electron 桌面 app
-- `packages/relay`：用于远程连接的 relay 包
-- `packages/website`：营销站点和文档（`paseo.sh`）
-
-常用命令：
-
-```bash
-# 运行所有本地开发服务
-npm run dev
-
-# 单独运行某个界面
-npm run dev:server
-npm run dev:app
-npm run dev:desktop
-npm run dev:website
-
-# 构建 server stack
-npm run build:server
-
-# 全仓库检查
-npm run typecheck
-```
-
-## 赞助
-
-Paseo 由一个人开发，靠使用它的人来资助。你可以通过 [GitHub Sponsors](https://github.com/sponsors/boudra) 支持这项工作。公司也可以按月[赞助 Paseo](https://paseo.sh/sponsor#spot)，logo 会展示在这里和 paseo.sh 首页上。
-
-<!-- Sponsor logos go here, in the same order as packages/website/src/data/sponsors.ts -->
-
-## 相关项目
-
-- [getpaseo/paseo-relay](https://github.com/getpaseo/paseo-relay) — 官方分布式 relay，使用 Elixir 编写
-- [paseo-vscode](https://marketplace.visualstudio.com/items?itemName=hinnes.paseo-vscode) — VS Code 扩展
-
-### 自托管 relay TLS
-
-自托管 relay 默认使用 `ws://`，除非显式启用 TLS。对于 nginx 后面、监听 443 的 relay，可以这样启动 daemon：
-
-```bash
-PASEO_RELAY_ENDPOINT=127.0.0.1:8080 \
-PASEO_RELAY_PUBLIC_ENDPOINT=relay.example.com:443 \
-PASEO_RELAY_USE_TLS=true \
-paseo daemon start
-```
-
-等价配置：
-
-```json
-{
-  "daemon": {
-    "relay": {
-      "enabled": true,
-      "endpoint": "127.0.0.1:8080",
-      "publicEndpoint": "relay.example.com:443",
-      "useTls": true
-    }
-  }
-}
-```
-
-最小 nginx WebSocket 代理配置：
-
-```nginx
-server {
-  listen 443 ssl;
-  server_name relay.example.com;
-
-  ssl_certificate /etc/letsencrypt/live/relay.example.com/fullchain.pem;
-  ssl_certificate_key /etc/letsencrypt/live/relay.example.com/privkey.pem;
-
-  location /ws {
-    proxy_pass http://127.0.0.1:8080;
-    proxy_http_version 1.1;
-    proxy_set_header Upgrade $http_upgrade;
-    proxy_set_header Connection "upgrade";
-    proxy_set_header Host $host;
-  }
-}
-```
-
-## License
-
-Apache-2.0

SECURITY.md

@@ -19,21 +19,18 @@ The relay is designed to be untrusted. All traffic between your phone and daemon
 
 ### How it works
 
-1. The daemon generates a persistent Curve25519 keypair on first run and stores it at `$PASEO_HOME/daemon-keypair.json` with mode `0600`
-2. The pairing URL (rendered as a QR code or opened directly) carries the daemon's public key in its URL fragment (`https://app.paseo.sh/#offer=...`). Fragments are not sent to the web server, so `app.paseo.sh` never sees the key.
-3. When the phone connects via the relay, it generates a fresh ephemeral Curve25519 keypair and sends an `e2ee_hello` message containing its public key. The daemon will not process any application messages until this handshake completes.
-4. Both sides perform a Curve25519 ECDH key exchange to derive a shared key. All subsequent messages are encrypted with XSalsa20-Poly1305 (NaCl `box`). The encrypted bundle is `[24-byte nonce][ciphertext]`. Peers optionally negotiate `binaryCiphertext` in `e2ee_hello` / `e2ee_ready`: negotiated application text is carried as a base64 WebSocket text frame, while application binary is carried as a raw WebSocket binary frame. A peer that does not negotiate the capability uses base64 text frames for both kinds.
+1. The daemon generates a persistent ECDH keypair and stores it locally
+2. When you scan the QR code or click the pairing link, your phone receives the daemon's public key
+3. Your phone sends a handshake message with its own public key. The daemon will not accept any commands until this handshake completes.
+4. Both sides perform an ECDH key exchange to derive a shared secret. All subsequent messages are encrypted with XSalsa20-Poly1305 (NaCl box).
 
-The WebSocket opcode is preserved end to end after negotiation; the receiver never guesses whether authenticated plaintext is text or binary from its byte contents. The plaintext handshake remains WebSocket text and contains only public keys and capability declarations.
-
-The relay sees only: IP addresses, timing, message sizes, session IDs, and the plaintext `e2ee_hello` / `e2ee_ready` handshake frames (which contain only public keys). It cannot read message contents, forge messages, or derive encryption keys from observing the handshake.
+The relay sees only: IP addresses, timing, message sizes, and session IDs. It cannot read message contents, forge messages, or derive encryption keys from observing the handshake.
 
 ### Why the relay can't attack you
 
 The daemon requires a valid cryptographic handshake before processing any commands. A compromised relay cannot:
 
-- **Impersonate the daemon to your phone** — Without the daemon's secret key, it cannot derive the shared key, so any traffic it injects fails authenticated decryption on the phone
-- **Send commands as you** — The daemon only accepts traffic that decrypts and authenticates under a shared key derived with its own secret key. The phone's keypair is ephemeral per connection, so there is no persistent phone-side secret to steal; protection comes from the daemon's secret key never leaving the daemon.
+- **Send commands** — Without your phone's private key, it cannot complete the handshake
 - **Read your traffic** — All messages are encrypted with XSalsa20-Poly1305 (NaCl box) after the handshake
 - **Forge messages** — NaCl box provides authenticated encryption; tampered messages are rejected
 - **Replay old messages across sessions** — Each session derives fresh encryption keys, so ciphertext from one session cannot be replayed into another session. Within a live session, replay protection is not yet implemented; the protocol uses random nonces and does not track nonce reuse or message counters.
@@ -42,25 +39,13 @@ The daemon requires a valid cryptographic handshake before processing any comman
 
 The QR code or pairing link is the trust anchor. It contains the daemon's public key, which is required to establish the encrypted connection. Treat it like a password — don't share it publicly.
 
-When a daemon password is configured, new relay clients send it in the encrypted `hello` message. This release still admits relay clients that send no credential so existing mobile builds continue to connect. A wrong password is rejected. The next release will require the password for relay connections after updated mobile builds are available.
-
 ## Local daemon trust boundary
 
-By default, the daemon binds to `127.0.0.1`. With no password configured, anything that can reach the daemon socket can control the daemon. Loopback is reachable by other users on the machine and by some forwarding tools.
+By default, the daemon binds to `127.0.0.1`. The local control plane is trusted by network reachability, not by an additional authentication token.
 
-The daemon supports an optional shared-secret password (set via `auth.password` in `config.json` or the `PASEO_PASSWORD` env var; stored bcrypt-hashed). WebSocket clients send the password in `hello`; the daemon sends no session data before admission. Direct connections still accept bearer headers and WebSocket bearer subprotocols for older clients. HTTP stays bearer-header based. Health (`GET /api/health`) and CORS preflight (`OPTIONS`) are exempt; `/api/files/download` and `/mcp/agents` use their own capability tokens.
+Anything that can reach the daemon socket can control the daemon. This is the same security model Docker documents for its daemon: the security boundary is access to the socket or listening address.
 
-The daemon writes a new `$PASEO_HOME/local-credential` on every run with mode `0600` and removes it on shutdown. The CLI and desktop main process read it only for the daemon whose PID lock `listen` matches their connection target. A same-user process can read this credential, so the password protects against network clients and other OS users, not processes running as the daemon user. Protect `$PASEO_HOME` accordingly. Relay traffic remains end-to-end encrypted independently of password admission.
-
-Connected clients are trusted operators of the daemon user. File previews follow that authority: a preview request may read any regular file the daemon process can read, while keeping path normalization and symlink checks in the daemon file service. Workspace-relative paths remain a UI convenience, not a security boundary.
-
-When Paseo checks out a change request from a different repository, it does not run that workspace's `paseo.json` setup, automatic terminals, named scripts, or teardown until you explicitly run setup for that workspace. The decision lasts for the workspace and does not re-prompt after new commits. Same-repository changes, ordinary branches, local workspaces, agent launches, terminals, explicit shell commands, and metadata-generation instructions are outside this gate.
-
-If you expose the daemon beyond loopback, such as by binding to `0.0.0.0`, forwarding it through a tunnel or reverse proxy, or publishing it from a Docker container, you are responsible for restricting and securing that access. Setting a password is strongly recommended in that case.
-
-In Docker, the official image runs the daemon and agents as the non-root
-`paseo` user by default. Mounted workspaces and credentials are still fully
-available to anything the agents run inside the container.
+If you expose the daemon beyond loopback, such as by binding to `0.0.0.0`, forwarding it through a tunnel or reverse proxy, or publishing it from a Docker container, you are responsible for restricting and securing that access.
 
 For remote access, use the relay connection. It is the supported path for reaching the daemon off-machine, and it adds end-to-end encryption plus a pairing handshake before commands are accepted.
 
@@ -70,28 +55,12 @@ Host header validation and CORS origin checks are defense-in-depth controls for
 
 CORS is not a complete security boundary. It controls which browser origins can make requests, but does not prevent a malicious website from resolving its domain to your local machine (DNS rebinding).
 
-Paseo validates the `Host` header on every HTTP request and every WebSocket upgrade against an allowlist (Vite-style semantics). By default, only `localhost`, `*.localhost`, and any literal IP address (IPv4 or IPv6) are accepted. Additional hostnames can be configured via `hostnames` in `config.json` or the `PASEO_HOSTNAMES` env var (comma-separated; entries beginning with `.` match a domain and its subdomains; the value `true` disables the allowlist entirely). Requests with unrecognized hosts are rejected with `403 Host not allowed`.
-
-## HTML file preview
-
-Previewing an `.html` file in the file pane renders it as a page, so markup an agent wrote — or markup that arrived with a repo you cloned — executes when you open it. The preview is built to contain that, not to trust it.
-
-The document loads with an opaque origin and a policy that permits inline script and style and refuses everything else: no remote script, font, image, or media; no `fetch`, XHR, WebSocket, or beacon; no form posts; no plugins; no nested frames. It has no access to Paseo's DOM, and storage and cookie APIs throw inside it rather than returning anything. It cannot navigate the top window, and it cannot open popups. It cannot read any file but itself.
-
-One gap remains on web and desktop: a sandboxed document may navigate _itself_, and no CSP directive in current browsers prevents that. `navigate-to` was dropped from CSP Level 3 and is not enforced, and `<meta http-equiv="refresh">` needs no script at all. A hostile page can therefore reach a server by navigating away, carrying data available inside the preview, such as its own contents, browser and device properties, user input inside the page, and your IP address. It cannot read Paseo, another file, storage, or cookies.
-
-Native builds narrow this gap rather than closing it outright. The WebView refuses every navigation after the initial document, but that decision is made in the app's JavaScript, and on Android the WebView falls back to allowing a navigation when the decision doesn't come back in time. Treat it as a strong mitigation, not a guarantee: if the JS thread is stalled at the moment a page navigates, the same leak is possible there too.
-
-If you don't trust a page, read it in `Source`, which executes nothing. Source is available as an editable view on supported web hosts and a read-only view everywhere else.
+Paseo uses a host allowlist to validate the `Host` header on incoming requests. Requests with unrecognized hosts are rejected.
 
 ## Agent authentication
 
 Paseo wraps agent CLIs (Claude Code, Codex, OpenCode) but does not manage their authentication. Each agent provider handles its own credentials. Paseo never stores or transmits provider API keys. Agents run in your user context with your existing credentials.
 
-## Forge host trust
-
-Paseo only talks to a forge host that is either a known cloud host or one the forge CLI is already authenticated to. It never probes or routes credentials to an unauthenticated, remote-derived host.
-
 ## Reporting vulnerabilities
 
 If you discover a security vulnerability, please report it privately by emailing hello@moboudra.com. Do not open a public issue.

app.json

@@ -0,0 +1,5 @@
+{
+  "android": {
+    "package": "com.moboudra.paseo"
+  }
+}

biome.json

@@ -0,0 +1,32 @@
+{
+  "$schema": "https://biomejs.dev/schemas/2.0.0/schema.json",
+  "vcs": {
+    "enabled": true,
+    "clientKind": "git",
+    "useIgnoreFile": true
+  },
+  "files": {
+    "includes": ["**", "!*.lock"]
+  },
+  "formatter": {
+    "indentStyle": "space",
+    "indentWidth": 2,
+    "lineWidth": 100
+  },
+  "javascript": {
+    "formatter": {
+      "quoteStyle": "double",
+      "trailingCommas": "all",
+      "semicolons": "always"
+    }
+  },
+  "css": {
+    "parser": {
+      "cssModules": true,
+      "tailwindDirectives": true
+    }
+  },
+  "linter": {
+    "enabled": false
+  }
+}

docker/Dockerfile.agents.example

@@ -1,17 +0,0 @@
-# Example child image that adds agent CLIs to the official Paseo image.
-#
-# Build:
-#   docker build -f docker/Dockerfile.agents.example -t paseo-with-agents .
-#
-# Then set `image: paseo-with-agents` in docker/docker-compose.example.yml.
-
-FROM ghcr.io/getpaseo/paseo:latest
-
-USER root
-RUN npm install -g \
-  @anthropic-ai/claude-code \
-  @openai/codex \
-  opencode-ai
-
-# Leave the image user as root. The base entrypoint prepares mounted volumes,
-# then drops the daemon and launched agents to the non-root `paseo` user.

docker/README.md

@@ -1,30 +0,0 @@
-# Paseo Docker Image
-
-This directory contains the official Paseo daemon image.
-
-The image runs the daemon headless and serves the bundled web UI from the same
-HTTP origin. Start it, then open the daemon URL in a browser.
-
-```bash
-docker run -d --name paseo \
-  -p 6767:6767 \
-  -e PASEO_PASSWORD=change-me \
-  -v "$PWD/paseo-home:/home/paseo" \
-  -v "$PWD:/workspace" \
-  ghcr.io/getpaseo/paseo:latest
-```
-
-Then open `http://localhost:6767`.
-
-The base image intentionally does not bundle agent CLIs. Extend it with the
-agents you use:
-
-```Dockerfile
-FROM ghcr.io/getpaseo/paseo:latest
-
-USER root
-RUN npm install -g @openai/codex @anthropic-ai/claude-code
-```
-
-See [docs/docker.md](../docs/docker.md) for Compose, reverse proxy, security,
-agent auth, and troubleshooting notes.

docker/base/Dockerfile

@@ -1,105 +0,0 @@
-# syntax=docker/dockerfile:1
-
-ARG NODE_IMAGE=node:22-bookworm-slim
-FROM --platform=$BUILDPLATFORM ${NODE_IMAGE} AS source-pack
-
-ARG PASEO_VERSION
-
-ENV ONNXRUNTIME_NODE_INSTALL=skip
-
-WORKDIR /tmp/paseo-src
-COPY . .
-
-RUN set -eux; \
-    if [ -n "${PASEO_VERSION:-}" ]; then \
-      test "$(node -p "require('./package.json').version")" = "${PASEO_VERSION}"; \
-    fi; \
-    node -e 'const fs=require("node:fs"); const pkg=JSON.parse(fs.readFileSync("package.json","utf8")); delete pkg.scripts.prepare; fs.writeFileSync("package.json", `${JSON.stringify(pkg)}\n`);'; \
-    npm ci
-
-RUN set -eux; \
-    mkdir -p /tmp/paseo-packs; \
-    npm pack --workspace=@getpaseo/highlight --pack-destination /tmp/paseo-packs; \
-    npm pack --workspace=@getpaseo/relay --pack-destination /tmp/paseo-packs; \
-    npm pack --workspace=@getpaseo/protocol --pack-destination /tmp/paseo-packs; \
-    npm pack --workspace=@getpaseo/client --pack-destination /tmp/paseo-packs; \
-    npm pack --workspace=@getpaseo/plugin --pack-destination /tmp/paseo-packs; \
-    npm pack --workspace=@getpaseo/server --pack-destination /tmp/paseo-packs; \
-    npm pack --workspace=@getpaseo/cli --pack-destination /tmp/paseo-packs
-
-FROM ${NODE_IMAGE}
-
-ENV HOME=/home/paseo \
-    PASEO_HOME=/home/paseo/.paseo \
-    PASEO_LISTEN=0.0.0.0:6767 \
-    PASEO_WEB_UI_ENABLED=true \
-    PASEO_LOG_FORMAT=json \
-    PASEO_LOG_LEVEL=info \
-    CLAUDE_CONFIG_DIR=/home/paseo/.claude \
-    CODEX_HOME=/home/paseo/.codex \
-    XDG_CONFIG_HOME=/home/paseo/.config \
-    XDG_DATA_HOME=/home/paseo/.local/share \
-    XDG_STATE_HOME=/home/paseo/.local/state \
-    XDG_CACHE_HOME=/home/paseo/.cache \
-    ONNXRUNTIME_NODE_INSTALL=skip
-
-RUN set -eux; \
-    apt-get update; \
-    apt-get install -y --no-install-recommends \
-      bash \
-      ca-certificates \
-      curl \
-      git \
-      gosu \
-      lbzip2 \
-      openssh-client \
-      procps \
-      tini; \
-    rm -rf /var/lib/apt/lists/*
-
-COPY --from=source-pack /tmp/paseo-packs /tmp/paseo-packs
-RUN set -eux; \
-	npm install -g /tmp/paseo-packs/*.tgz; \
-    rm -rf /tmp/paseo-packs; \
-    npm cache clean --force; \
-    server_entry="$(npm root -g)/@getpaseo/server/dist/scripts/supervisor-entrypoint.js"; \
-    test -f "$server_entry"; \
-    printf '%s\n' "$server_entry" > /etc/paseo-server-entry; \
-    node --check "$server_entry"
-
-RUN set -eux; \
-    existing_group="$(getent group 1000 | cut -d: -f1 || true)"; \
-    if [ -n "$existing_group" ] && [ "$existing_group" != "paseo" ]; then \
-      groupmod --new-name paseo "$existing_group"; \
-    elif [ -z "$existing_group" ]; then \
-      groupadd --gid 1000 paseo; \
-    fi; \
-    existing_user="$(getent passwd 1000 | cut -d: -f1 || true)"; \
-    if [ -n "$existing_user" ] && [ "$existing_user" != "paseo" ]; then \
-      usermod --login paseo --gid paseo --home /home/paseo --shell /bin/bash "$existing_user"; \
-    elif [ -z "$existing_user" ]; then \
-      useradd --uid 1000 --gid paseo --create-home --home-dir /home/paseo --shell /bin/bash paseo; \
-    fi; \
-    mkdir -p \
-      /workspace \
-      "$PASEO_HOME" \
-      "$CLAUDE_CONFIG_DIR" \
-      "$CODEX_HOME" \
-      "$XDG_CONFIG_HOME" \
-      "$XDG_DATA_HOME" \
-      "$XDG_STATE_HOME" \
-      "$XDG_CACHE_HOME"; \
-    chown -R paseo:paseo /home/paseo /workspace
-
-COPY docker/base/rootfs/ /
-RUN chmod +x /usr/local/bin/paseo-docker-entrypoint
-
-WORKDIR /workspace
-
-EXPOSE 6767
-VOLUME ["/home/paseo"]
-
-HEALTHCHECK --interval=30s --timeout=5s --start-period=30s --retries=3 \
-  CMD node -e "const listen=process.env.PASEO_LISTEN||'0.0.0.0:6767'; const m=listen.match(/:(\\d+)$/); const port=m?Number(m[1]):6767; require('http').get({hostname:'127.0.0.1',port,path:'/api/health'},r=>process.exit(r.statusCode===200?0:1)).on('error',()=>process.exit(1))"
-
-ENTRYPOINT ["/usr/bin/tini", "--", "/usr/local/bin/paseo-docker-entrypoint"]

docker/base/rootfs/usr/local/bin/paseo-docker-entrypoint

@@ -1,78 +0,0 @@
-#!/usr/bin/env bash
-set -euo pipefail
-
-IMAGE_HOME="/home/paseo"
-
-: "${HOME:=$IMAGE_HOME}"
-: "${PASEO_HOME:=${HOME}/.paseo}"
-: "${PASEO_LISTEN:=0.0.0.0:6767}"
-: "${PASEO_WEB_UI_ENABLED:=true}"
-: "${PASEO_LOG_LEVEL:=info}"
-: "${PASEO_LOG_FORMAT:=json}"
-: "${CLAUDE_CONFIG_DIR:=${HOME}/.claude}"
-: "${CODEX_HOME:=${HOME}/.codex}"
-: "${XDG_CONFIG_HOME:=${HOME}/.config}"
-: "${XDG_DATA_HOME:=${HOME}/.local/share}"
-: "${XDG_STATE_HOME:=${HOME}/.local/state}"
-: "${XDG_CACHE_HOME:=${HOME}/.cache}"
-
-export HOME
-export PASEO_HOME
-export PASEO_LISTEN
-export PASEO_WEB_UI_ENABLED
-export PASEO_LOG_LEVEL
-export PASEO_LOG_FORMAT
-export CLAUDE_CONFIG_DIR
-export CODEX_HOME
-export XDG_CONFIG_HOME
-export XDG_DATA_HOME
-export XDG_STATE_HOME
-export XDG_CACHE_HOME
-
-ensure_dir() {
-  local dir="$1"
-  mkdir -p "$dir"
-  if [[ "$(id -u)" == "0" ]]; then
-    local owner
-    owner="$(stat -c "%u" "$dir")"
-    if [[ "$owner" == "0" ]]; then
-      chown paseo:paseo "$dir"
-    fi
-  fi
-}
-
-ensure_dir "$HOME"
-ensure_dir "$PASEO_HOME"
-ensure_dir "$CLAUDE_CONFIG_DIR"
-ensure_dir "$CODEX_HOME"
-ensure_dir "$XDG_CONFIG_HOME"
-ensure_dir "$XDG_DATA_HOME"
-ensure_dir "$XDG_STATE_HOME"
-ensure_dir "$XDG_CACHE_HOME"
-
-if [[ "$#" -gt 0 ]]; then
-  if [[ "$(id -u)" == "0" ]]; then
-    exec gosu paseo "$@"
-  fi
-  exec "$@"
-fi
-
-if [[ -z "${PASEO_PASSWORD:-}" ]]; then
-  {
-    echo "[paseo] WARNING: PASEO_PASSWORD is not set."
-    echo "[paseo] The daemon accepts unauthenticated control connections from any client that can reach it."
-    echo "[paseo] Set PASEO_PASSWORD for any published port or network-reachable deployment."
-  } >&2
-fi
-
-if [[ ! -f /etc/paseo-server-entry ]]; then
-  echo "[paseo] FATAL: /etc/paseo-server-entry is missing." >&2
-  exit 1
-fi
-
-entry="$(cat /etc/paseo-server-entry)"
-echo "[paseo] starting daemon on ${PASEO_LISTEN} with web UI ${PASEO_WEB_UI_ENABLED}"
-if [[ "$(id -u)" == "0" ]]; then
-  exec gosu paseo node "$entry"
-fi
-exec node "$entry"

docker/docker-compose.example.yml

@@ -1,21 +0,0 @@
-# Minimal Paseo daemon + web UI deployment.
-#
-# Open http://localhost:6767 after `docker compose up -d`.
-# For any network-reachable deployment, change PASEO_PASSWORD first.
-services:
-  paseo:
-    image: ghcr.io/getpaseo/paseo:latest
-    container_name: paseo
-    restart: unless-stopped
-    ports:
-      - "6767:6767"
-    environment:
-      PASEO_PASSWORD: "change-me"
-      # Add DNS names you use to reach this container. IPs and localhost are
-      # already allowed by default.
-      # PASEO_HOSTNAMES: "paseo.example.com,.lan"
-    volumes:
-      # Persistent daemon state and agent credentials/config.
-      - ./paseo-home:/home/paseo
-      # Code visible to Paseo and the agents it launches.
-      - ./workspace:/workspace

docs/ANDROID.md

@@ -0,0 +1,69 @@
+# Android
+
+## App variants
+
+Controlled by `APP_VARIANT` in `packages/app/app.config.js` (vanilla Expo, no custom Gradle plugin):
+
+| Variant | App name | Package ID |
+|---|---|---|
+| `production` | Paseo | `sh.paseo` |
+| `development` | Paseo Debug | `sh.paseo.debug` |
+
+EAS profiles: `development`, `production`, and `production-apk` in `packages/app/eas.json`.
+
+`development` uses Android `debug`.
+
+## Local build + install
+
+From repo root:
+
+```bash
+npm run android:development    # Debug build
+npm run android:production     # Release build
+npm run android:clear          # Remove generated Android project
+```
+
+Or from `packages/app`:
+
+```bash
+# Debug
+APP_VARIANT=development npx expo prebuild --platform android --non-interactive
+APP_VARIANT=development npx expo run:android --variant=debug
+
+# Release
+APP_VARIANT=production npx expo prebuild --platform android --non-interactive
+APP_VARIANT=production npx expo run:android --variant=release
+
+# Clear generated Android project
+rm -rf android
+```
+
+## Screenshots
+
+```bash
+adb exec-out screencap -p > screenshot.png
+```
+
+## Cloud build + submit (EAS)
+
+Stable tag pushes like `v0.1.0` trigger:
+
+- `packages/app/.eas/workflows/release-mobile.yml` on Expo servers (iOS + Android build + submit)
+- `.github/workflows/android-apk-release.yml` on GitHub Actions (APK asset on GitHub Release)
+
+Release candidate tags like `v0.1.1-rc.1` only trigger the GitHub APK workflow. They publish a GitHub prerelease APK for testing and do not submit to the stores.
+
+### Useful commands
+
+```bash
+cd packages/app
+
+# List recent workflow runs
+npx eas workflow:runs --workflow release-mobile.yml --limit 10
+
+# Inspect a run
+npx eas workflow:view <run-id>
+
+# Stream logs for a failed job
+npx eas workflow:logs <job-id> --non-interactive --all-steps
+```

docs/ARCHITECTURE.md

@@ -0,0 +1,192 @@
+# Architecture
+
+Paseo is a client-server system for monitoring and controlling local AI coding agents. The daemon runs on your machine, manages agent processes, and streams their output in real time over WebSocket. Clients (mobile app, CLI, desktop app) connect to the daemon to observe and interact with agents.
+
+Your code never leaves your machine. Paseo is local-first.
+
+## System overview
+
+```
+┌─────────────┐    ┌─────────────┐    ┌─────────────┐
+│  Mobile App  │    │     CLI     │    │ Desktop App │
+│   (Expo)     │    │ (Commander) │    │ (Electron)  │
+└──────┬───────┘    └──────┬──────┘    └──────┬──────┘
+       │                   │                  │
+       │    WebSocket      │    WebSocket     │    Managed subprocess
+       │    (direct or     │    (direct)      │    + WebSocket
+       │     via relay)    │                  │
+       └───────────┬───────┴──────────────────┘
+                   │
+            ┌──────▼──────┐
+            │   Daemon    │
+            │  (Node.js)  │
+            └──────┬──────┘
+                   │
+      ┌────────────┼────────────┐
+      │            │            │
+┌─────▼─────┐ ┌───▼────┐ ┌────▼─────┐
+│  Claude   │ │ Codex  │ │ OpenCode │
+│  Agent    │ │ Agent  │ │  Agent   │
+│  SDK      │ │ Server │ │          │
+└───────────┘ └────────┘ └──────────┘
+```
+
+## Components at a glance
+
+- **Daemon:** Local server that spawns and manages agent processes and exposes the WebSocket API.
+- **App:** Cross-platform Expo client for iOS, Android, web, and the shared UI used by desktop.
+- **CLI:** Terminal interface for agent workflows that can also start and manage the daemon.
+- **Desktop app:** Electron wrapper around the web app that bundles and auto-manages its own daemon.
+- **Relay:** Optional encrypted bridge for remote access without opening ports directly.
+
+## Packages
+
+### `packages/server` — The daemon
+
+The heart of Paseo. A Node.js process that:
+
+- Listens for WebSocket connections from clients
+- Manages agent lifecycle (create, run, stop, resume, archive)
+- Streams agent output in real time via a timeline model
+- Exposes an MCP server for agent-to-agent control
+- Optionally connects outbound to a relay for remote access
+
+**Key modules:**
+
+| Module | Responsibility |
+|---|---|
+| `bootstrap.ts` | Daemon initialization: HTTP server, WS server, agent manager, storage, relay |
+| `websocket-server.ts` | WebSocket connection management, hello/welcome handshake, binary multiplexing |
+| `session.ts` | Per-client session state, timeline subscriptions, terminal operations |
+| `agent/agent-manager.ts` | Agent lifecycle state machine, timeline tracking, subscriber management |
+| `agent/agent-storage.ts` | File-backed JSON persistence at `$PASEO_HOME/agents/` |
+| `agent/mcp-server.ts` | MCP server for sub-agent creation, permissions, timeouts |
+| `providers/` | Provider adapters: Claude (Agent SDK), Codex (AppServer), OpenCode |
+| `relay-transport.ts` | Outbound relay connection with E2E encryption |
+| `client/daemon-client.ts` | Client library for connecting to the daemon (used by CLI and app) |
+
+### `packages/app` — Mobile + web client (Expo)
+
+Cross-platform React Native app that connects to one or more daemons.
+
+- Expo Router navigation (`/h/[serverId]/agents`, etc.)
+- `DaemonRegistryContext` manages saved daemon connections
+- `SessionContext` wraps the daemon client for the active session
+- `Stream` model handles timeline with compaction, gap detection, sequence-based deduplication
+- Voice features: dictation (STT) and voice agent (realtime)
+
+### `packages/cli` — Command-line client
+
+Commander.js CLI with Docker-style commands:
+
+- `paseo agent ls/run/stop/logs/inspect/wait/send/attach`
+- `paseo daemon start/stop/restart/status/pair`
+- `paseo permit allow/deny/ls`
+- `paseo provider ls/models`
+- `paseo worktree ls/archive`
+
+Communicates with the daemon via the same WebSocket protocol as the app.
+
+### `packages/relay` — E2E encrypted relay
+
+Enables remote access when the daemon is behind a firewall.
+
+- ECDH key exchange + AES-256-GCM encryption
+- Relay server is zero-knowledge — it routes encrypted bytes, cannot read content
+- Client and daemon channels with identical API (`createClientChannel`, `createDaemonChannel`)
+- Pairing via QR code transfers the daemon's public key to the client
+
+See [SECURITY.md](../SECURITY.md) for the full threat model.
+
+### `packages/desktop` — Desktop app (Electron)
+
+Electron wrapper for macOS, Linux, and Windows.
+
+- Can spawn the daemon as a managed subprocess
+- Native file access for workspace integration
+- Same WebSocket client as mobile app
+
+### `packages/website` — Marketing site
+
+TanStack Router + Cloudflare Workers. Serves paseo.sh.
+
+## WebSocket protocol
+
+All clients speak the same binary-multiplexed WebSocket protocol.
+
+**Handshake:**
+
+```
+Client → Server:  WSHelloMessage { id, clientId, version, timestamp }
+Server → Client:  WSWelcomeMessage { clientId, daemonVersion, sessionId, capabilities }
+```
+
+**Message types:**
+
+- `agent_update` — Agent state changed (status, title, labels)
+- `agent_stream` — New timeline event from a running agent
+- `workspace_update` — Workspace state changed
+- `agent_permission_request` — Agent needs user approval for a tool call
+- Command-response pairs for fetch, list, create, etc.
+
+**Binary multiplexing:**
+
+Terminal I/O and agent streaming share the same connection via `BinaryMuxFrame`:
+- Channel 0: control messages
+- Channel 1: terminal data
+- 1-byte channel ID + 1-byte flags + variable payload
+
+## Agent lifecycle
+
+```
+initializing → idle → running → idle (or error → closed)
+                 ↑        │
+                 └────────┘  (agent completes a turn, awaits next prompt)
+```
+
+- **AgentManager** tracks up to 200 timeline items per agent
+- Timeline is append-only with epochs (each run starts a new epoch)
+- Events stream to all subscribed clients in real time
+- Agent state persists to `$PASEO_HOME/agents/{cwd-with-dashes}/{agent-id}.json`
+
+## Agent providers
+
+Each provider implements a common `AgentClient` interface:
+
+| Provider | Wraps | Session format |
+|---|---|---|
+| Claude | Anthropic Agent SDK | `~/.claude/projects/{cwd}/{session-id}.jsonl` |
+| Codex | CodexAppServer | `~/.codex/sessions/{date}/rollout-{ts}-{id}.jsonl` |
+| OpenCode | OpenCode CLI | Provider-managed |
+
+All providers:
+- Handle their own authentication (Paseo does not manage API keys)
+- Support session resume via persistence handles
+- Map tool calls to a normalized `ToolCallDetail` type
+- Expose provider-specific modes (plan, default, full-access)
+
+## Data flow: running an agent
+
+1. Client sends `CreateAgentRequestMessage` with config (prompt, cwd, provider, model, mode)
+2. Session routes to `AgentManager.create()`
+3. AgentManager creates a `ManagedAgent`, initializes provider session
+4. Provider runs the agent → emits `AgentStreamEvent` items
+5. Events append to the agent timeline, broadcast to all subscribed clients
+6. Tool calls are normalized to `ToolCallDetail` (shell, read, edit, write, search, etc.)
+7. Permission requests flow: agent → server → client → user decision → server → agent
+
+## Storage
+
+```
+$PASEO_HOME/
+├── agents/{cwd-with-dashes}/{agent-id}.json   # Agent state + config
+├── projects/projects.json                      # Project registry
+├── projects/workspaces.json                    # Workspace registry
+└── daemon.log                                  # Daemon trace logs
+```
+
+## Deployment models
+
+1. **Local daemon** (default): `paseo daemon start` on `127.0.0.1:6767`
+2. **Managed desktop**: Electron app spawns daemon as subprocess
+3. **Remote + relay**: Daemon behind firewall, relay bridges with E2E encryption

docs/CODING_STANDARDS.md

@@ -0,0 +1,174 @@
+# Coding Standards
+
+These standards apply to all code changes: features, bug fixes, refactors, and performance work.
+
+## Core principles
+
+- **Zero complexity budget** — justify every abstraction with specific benefits
+- **Fully typed TypeScript** — no `any`, no untyped boundaries
+- **YAGNI** — build features and abstractions only when needed
+- **Functional and declarative** over object-oriented
+- **`interface`** over `type` when possible
+- **`function` declarations** over arrow function assignments
+- **Single-purpose functions** — one function, one job
+- **Design for edge cases through types** rather than explicit handling
+- **Don't catch errors** unless there's a strong reason to
+- **No index.ts barrel files** that only re-export — they create unnecessary indirection
+- **No "while I'm at it" improvements** — stay focused on the task
+
+## Type hygiene
+
+### Infer from schemas
+
+Never hand-write a TypeScript type that can be inferred from a Zod schema.
+
+```typescript
+// Bad: duplicate type that can drift
+const schema = z.object({ procedure: z.string(), args: z.record(z.unknown()) });
+type RPCArgs = { procedure: string; args: Record<string, unknown> };
+
+// Good: infer from schema
+type RPCArgs = z.infer<typeof schema>;
+```
+
+### Named types over inline
+
+No complex inline types in public function signatures.
+
+```typescript
+// Bad
+function enqueueJob(input: { userId: string; priority: "low" | "normal" | "high" }) {}
+
+// Good
+interface EnqueueJobInput { userId: string; priority: "low" | "normal" | "high" }
+function enqueueJob(input: EnqueueJobInput) {}
+```
+
+### Object parameters
+
+If a function needs more than one argument, use a single object parameter.
+
+```typescript
+// Bad: positional args
+function createToolCall(provider: string, toolName: string, payload: unknown) {}
+
+// Good: object param
+interface CreateToolCallInput { provider: string; toolName: string; payload: unknown }
+function createToolCall(input: CreateToolCallInput) {}
+```
+
+### One canonical type per concept
+
+Don't redefine the same concept in different layer-specific shapes (`RpcX`, `DbX`, `UiX`). Keep one canonical type and add explicit layer wrappers that reference it.
+
+```typescript
+// Bad: duplicated fields across layers
+type RpcToolCall = { toolName: string; args: Record<string, unknown>; requestId: string };
+type DbToolCall = { toolName: string; args: Record<string, unknown>; id: string; createdAt: Date };
+
+// Good: canonical type + wrappers
+type ToolCall = { toolName: string; args: Record<string, unknown> };
+type ToolCallRequest = { requestId: string; toolCall: ToolCall };
+type ToolCallRecord = { id: string; createdAt: Date; toolCall: ToolCall };
+```
+
+## Make impossible states impossible
+
+Use discriminated unions instead of bags of booleans and optionals.
+
+```typescript
+// Bad
+interface FetchState { isLoading: boolean; error?: Error; data?: Data }
+
+// Good
+type FetchState =
+  | { status: "idle" }
+  | { status: "loading" }
+  | { status: "error"; error: Error }
+  | { status: "success"; data: Data };
+```
+
+## Optionality is a design decision
+
+Don't mark fields optional to avoid migrations. Decide deliberately:
+
+1. Is optionality actually needed?
+2. If there are distinct valid states → discriminated union
+3. If value can be intentionally empty → explicit `null`
+4. Keep optionality at real boundaries (external input), then resolve it
+
+## Validate at boundaries, trust internally
+
+Parse external data once at the boundary with schema validation. Then use typed values everywhere else.
+
+```typescript
+// Bad: optional chaining because shape is unclear
+const value = response?.data?.items?.[0]?.name;
+
+// Good: validate at boundary, trust the types
+const parsed = responseSchema.parse(rawResponse);
+const value = parsed.data.items[0].name;
+```
+
+## Error handling
+
+- **Fail explicitly** — if caller requests X and X is unavailable, throw rather than silently returning Y
+- **Use typed domain errors** — not plain `Error`. Carry structured metadata for handling, logging, and user messaging
+- **Preserve error semantics** — don't collapse meaningful typed errors into generic `Error`
+
+```typescript
+class TimeoutError extends Error {
+  constructor(
+    public readonly operation: string,
+    public readonly waitedMs: number,
+  ) {
+    super(`${operation} timed out after ${waitedMs}ms`);
+    this.name = "TimeoutError";
+  }
+}
+```
+
+## Keep logic density low
+
+Avoid packing branching, lookup, and transformation into single dense expressions.
+
+```typescript
+// Bad: nested ternaries + inline lookups
+const billing = shouldUseLegacy(account)
+  ? getLegacy(account)
+  : buildBilling(account, rates.find((r) => r.region === account.region));
+
+// Good: named steps, then assemble
+const rate = rates.find((r) => r.region === account.region);
+if (!rate) throw new MissingRateError(account.region);
+const billing = shouldUseLegacy(account) ? getLegacy(account) : buildBilling(account, rate);
+```
+
+## Centralize policy
+
+When the same discriminator (`plan`, `provider`, `kind`, `status`) is checked across multiple files, centralize it into a policy model. A new case should require editing one place, not many.
+
+## React: keep components dumb
+
+- Components render state and dispatch events — they don't compute transitions
+- If a component has more than two interacting `useState` calls, extract a state machine or reducer
+- `useRef` for mutable coordination state (flags, timers) is a smell — model states explicitly
+- Never mirror a source of truth into local state; derive from it
+- Test state logic as pure functions without rendering
+
+## File organization
+
+- Organize by domain first (`providers/claude/`), not by technical type (`tool-parsers/`)
+- Name files after the main export (`create-toolcall.ts`)
+- Use `index.ts` as an entrypoint, not a dumping ground
+- Collocate tests with implementation (`thing.ts` + `thing.test.ts`)
+
+## Refactoring contract
+
+Refactoring is structure work, not feature work.
+
+- Preserve behavior by default, especially user-facing behavior
+- Do not remove features to simplify code without explicit approval
+- Have a verification strategy before you start
+- Fully migrate callers and remove old paths in the same refactor
+- No fallback behavior by default — prefer explicit error over silent degradation

docs/DESIGN.md

@@ -0,0 +1,73 @@
+# Designing Features
+
+How to think through a feature before writing code.
+
+## Start from the user
+
+Even for backend work, start from the user's perspective:
+
+- What problem does this solve?
+- What triggers it? User action, schedule, event?
+- What does success look like from the user's perspective?
+- What data does it need? Where does that data come from?
+
+## Map existing code
+
+Before designing anything new, understand what exists:
+
+- Where does similar functionality live?
+- What patterns does the codebase already use?
+- What layers exist? (See [ARCHITECTURE.md](./ARCHITECTURE.md))
+- What types and data shapes are already defined?
+
+New features rarely mean only new code. Usually they require modifying existing interfaces, extending existing types, or refactoring to accommodate the new functionality. Identify what needs to change, not just what needs to be added.
+
+## Define verification before implementation
+
+Before designing the solution, define how you'll know it works:
+
+- What tests will prove this feature is correct?
+- At what layer? Unit, integration, E2E?
+- What's the simplest way to verify the core behavior?
+
+If you can't define verification, you don't understand the feature well enough yet.
+
+## Design the shape
+
+### Data
+
+- What types are needed?
+- Use discriminated unions — make impossible states impossible
+- One canonical type per concept (see [CODING_STANDARDS.md](./CODING_STANDARDS.md))
+
+### Layers
+
+- What belongs in each layer?
+- Where are the boundaries?
+- What does each layer expose to the layer above?
+
+### Interactions
+
+- How does data flow through the system?
+- What triggers what?
+- Where do side effects happen?
+
+### Refactoring
+
+- What existing code needs to change?
+- Is existing code testable enough? If not, that's part of the plan.
+
+## Create a concrete plan
+
+Once the design is clear:
+
+1. **Acceptance criteria** — specific, verifiable outcomes (not "should work well" but "returns X when given Y")
+2. **Ordered steps** — what to build first (usually: types, then lowest layer, then up)
+3. **What to refactor** before adding new code
+4. **How to verify** each step
+
+## Principles
+
+- **Fit, don't force** — new code should fit existing patterns, or refactor first
+- **Simple** — the best design is the simplest one that works
+- **Verify early** — define how to test before designing the implementation

docs/DEVELOPMENT.md

@@ -0,0 +1,130 @@
+# Development
+
+## Prerequisites
+
+- Node.js (see `.tool-versions` for exact version)
+- npm workspaces (comes with Node)
+
+## Running the dev server
+
+```bash
+npm run dev
+```
+
+The dev script automatically picks an available port. Both the server and Expo app run in a Tmux session — see `CLAUDE.local.md` for system-specific session details.
+
+### Running alongside the main checkout
+
+Set `PASEO_HOME` to isolate state when running a second instance (e.g., in a worktree):
+
+```bash
+PASEO_HOME=~/.paseo-blue npm run dev
+```
+
+- `PASEO_HOME` — path for runtime state (agents, sockets, etc.). Defaults to `~/.paseo`.
+
+### Default ports
+
+In the main checkout:
+- Daemon: `localhost:6767`
+- Expo app: `localhost:8081`
+
+In worktrees or with `npm run dev`, ports may differ. Never assume defaults.
+
+### Daemon logs
+
+Check `$PASEO_HOME/daemon.log` for trace-level logs.
+
+## Build sync gotchas
+
+### Relay → Daemon
+
+When changing `packages/relay/src/*`, rebuild before running the daemon:
+
+```bash
+npm run build --workspace=@getpaseo/relay
+```
+
+The Node daemon imports `@getpaseo/relay` from `packages/relay/dist/*`, not `src/*`.
+
+### Server → CLI
+
+When changing `packages/server/src/client/*` (especially `daemon-client.ts`) or shared WS protocol types, rebuild before running CLI commands:
+
+```bash
+npm run build --workspace=@getpaseo/server
+```
+
+The CLI imports `@getpaseo/server` via package exports resolving to `dist/*`. Stale `dist` means the CLI speaks an old protocol and fails with handshake warnings or timeouts.
+
+## CLI reference
+
+Use `npm run cli` to run the local CLI (instead of the globally installed `paseo` which points to the main checkout).
+
+```bash
+npm run cli -- ls -a -g              # List all agents globally
+npm run cli -- ls -a -g --json       # Same, as JSON
+npm run cli -- inspect <id>          # Show detailed agent info
+npm run cli -- logs <id>             # View agent timeline
+npm run cli -- daemon status         # Check daemon status
+```
+
+Use `--host <host:port>` to point the CLI at a different daemon:
+
+```bash
+npm run cli -- --host localhost:7777 ls -a
+```
+
+## Agent state
+
+Agent data lives at:
+
+```
+$PASEO_HOME/agents/{cwd-with-dashes}/{agent-id}.json
+```
+
+Find an agent by ID:
+```bash
+find $PASEO_HOME/agents -name "{agent-id}.json"
+```
+
+Find by content:
+```bash
+rg -l "some title text" $PASEO_HOME/agents/
+```
+
+## Provider session files
+
+Get the session ID from the agent JSON (`persistence.sessionId`), then:
+
+**Claude:**
+```
+~/.claude/projects/{cwd-with-dashes}/{session-id}.jsonl
+```
+
+**Codex:**
+```
+~/.codex/sessions/{YYYY}/{MM}/{DD}/rollout-{timestamp}-{session-id}.jsonl
+```
+
+## Testing with Playwright MCP
+
+Use Playwright MCP connecting to Metro at `http://localhost:8081` for UI testing.
+
+Do NOT use browser history (back/forward). Always navigate by clicking UI elements or using `browser_navigate` with the full URL — the app uses client-side routing and browser history breaks state.
+
+## Expo troubleshooting
+
+```bash
+npx expo-doctor
+```
+
+Diagnoses version mismatches and native module issues.
+
+## Typecheck
+
+Always run typecheck after changes:
+
+```bash
+npm run typecheck
+```

docs/FILE_ICONS.md

@@ -0,0 +1,109 @@
+# File Icons
+
+The file explorer uses colored SVG icons from [`material-icon-theme`](https://github.com/material-extensions/vscode-material-icon-theme) (installed as a dev dependency in `packages/app`).
+
+Icons are inlined as SVG strings in:
+
+```
+packages/app/src/components/material-file-icons.ts
+```
+
+This file is auto-generated. Do not edit it by hand.
+
+## How it works
+
+- `SVG_ICONS` maps icon names (e.g. `"typescript"`) to raw SVG strings
+- `EXTENSION_TO_ICON` maps file extensions (e.g. `"ts"`) to icon names
+- `getFileIconSvg(fileName)` returns the SVG string for a given filename, falling back to a generic file icon
+
+## Adding a new icon
+
+1. Find the icon name in the material-icon-theme manifest:
+
+```bash
+node -e "
+const m = require('./node_modules/material-icon-theme/dist/material-icons.json');
+console.log('fileExtensions:', m.fileExtensions['YOUR_EXT']);
+console.log('languageIds:', m.languageIds['YOUR_LANG']);
+"
+```
+
+2. Verify the SVG exists:
+
+```bash
+cat node_modules/material-icon-theme/icons/ICON_NAME.svg
+```
+
+3. Add two things to `material-file-icons.ts`:
+
+   - The SVG string in `SVG_ICONS`:
+     ```ts
+     "icon_name": `<svg ...>...</svg>`,
+     ```
+
+   - The extension mapping in `EXTENSION_TO_ICON`:
+     ```ts
+     "ext": "icon_name",
+     ```
+
+4. Run `npm run typecheck` to verify.
+
+## Currently included icons
+
+53 unique icons covering these extensions:
+
+| Extension(s) | Icon |
+|---|---|
+| `ts` | typescript |
+| `tsx` | react_ts |
+| `js` | javascript |
+| `jsx` | react |
+| `py` | python |
+| `go` | go |
+| `rs` | rust |
+| `rb` | ruby |
+| `java` | java |
+| `kt` | kotlin |
+| `c` | c |
+| `cpp` | cpp |
+| `h` | h |
+| `hpp` | hpp |
+| `cs` | csharp |
+| `swift` | swift |
+| `dart` | dart |
+| `ex`, `exs` | elixir |
+| `erl` | erlang |
+| `hs` | haskell |
+| `clj` | clojure |
+| `scala` | scala |
+| `ml` | ocaml |
+| `r` | r |
+| `lua` | lua |
+| `zig` | zig |
+| `nix` | nix |
+| `php` | php |
+| `html` | html |
+| `css` | css |
+| `scss` | sass |
+| `less` | less |
+| `json` | json |
+| `yml`, `yaml` | yaml |
+| `xml` | xml |
+| `toml` | toml |
+| `md`, `markdown` | markdown |
+| `sql` | database |
+| `graphql`, `gql` | graphql |
+| `sh`, `bash` | console |
+| `tf` | terraform |
+| `hcl` | hcl |
+| `vue` | vue |
+| `svelte` | svelte |
+| `astro` | astro |
+| `wasm` | webassembly |
+| `svg` | svg |
+| `png`, `jpg`, `jpeg`, `gif`, `webp`, `ico` | image |
+| `txt` | document |
+| `conf`, `cfg`, `ini` | settings |
+| `lock` | lock |
+| `groovy` | groovy |
+| `gradle` | gradle |

docs/MOBILE_TESTING.md

@@ -0,0 +1,206 @@
+# Mobile Testing
+
+## Maestro
+
+Maestro flows live in `packages/app/maestro/`. Reusable sub-flows live in `packages/app/maestro/flows/`.
+
+Run a flow:
+
+```bash
+maestro test packages/app/maestro/my-flow.yaml
+```
+
+### Screenshots
+
+`takeScreenshot` writes to the **current working directory** — there's no way to configure the output path in the YAML. To keep screenshots out of the checkout, `cd` into a temp directory and use an absolute path for the flow:
+
+```bash
+FLOW="$(pwd)/packages/app/maestro/my-flow.yaml"
+mkdir -p /tmp/maestro-out
+cd /tmp/maestro-out && maestro test "$FLOW"
+```
+
+`packages/app/maestro/.gitignore` excludes `*.png` as a safety net.
+
+### Element targeting
+
+Use `testID` or `nativeID` on components, then target with `id:` in flows. Prefer this over text matching — text breaks on copy changes.
+
+```tsx
+// Component
+<Pressable testID="sidebar-sessions" onPress={onPress}>
+```
+
+```yaml
+# Flow
+- tapOn:
+    id: "sidebar-sessions"
+- assertVisible:
+    id: "sidebar-sessions"
+```
+
+### Conditional steps
+
+Use `runFlow:when:visible` for steps that should only execute when a specific element is on screen:
+
+```yaml
+- runFlow:
+    when:
+      visible:
+        id: "sidebar-sessions"
+    commands:
+      - swipe:
+          direction: LEFT
+          duration: 300
+```
+
+This is how `flows/dev-client.yaml` handles Expo dev client screens that only appear in dev builds.
+
+### Don't use launchApp against a running dev app
+
+`launchApp` kills and restarts the app, disrupting Expo dev client state and host connections. For flows that test against an already-running dev app, **omit launchApp entirely** — just interact with whatever is on screen.
+
+Use `launchApp` only in flows that need a clean start (e.g., onboarding tests).
+
+### Swipe gestures
+
+Use `start`/`end` with percentage coordinates for precise control:
+
+```yaml
+# Edge swipe from left to open sidebar
+- swipe:
+    start: "5%,50%"
+    end: "80%,50%"
+    duration: 300
+```
+
+`direction: RIGHT` is simpler but less precise — use it for generic swipes, use coordinates when the start position matters (edge gestures, avoiding specific UI regions).
+
+### Assertions
+
+`assertVisible` checks **actual screen visibility**, not just view tree presence. An element that exists in the tree but is off-screen (e.g., `translateX: -400`) will correctly fail `assertVisible`. This makes it reliable for catching animation bugs where state says "open" but the view is visually hidden.
+
+For async elements, use `extendedWaitUntil`:
+
+```yaml
+- extendedWaitUntil:
+    visible: ".*Online.*"
+    timeout: 90000
+```
+
+### Dev client handling
+
+Two reusable flows handle Expo dev client screens after launch:
+
+- `flows/launch.yaml` — handles dev launcher, dismisses dev menu, asserts "Welcome to Paseo"
+- `flows/dev-client.yaml` — same but without asserting a particular app route
+
+## Self-verification loops
+
+Maestro can only interact with the app UI — it can't toggle iOS appearance, change locale, or simulate network conditions. For bugs that depend on system-level state, wrap Maestro in a bash script that handles the system changes between Maestro runs.
+
+This pattern also lets agents self-verify fixes without manual user testing.
+
+### Pattern
+
+1. Run baseline Maestro flow (confirm feature works)
+2. Make system-level change via `xcrun simctl` (toggle appearance, etc.)
+3. Re-run Maestro flow (confirm feature still works)
+4. Repeat N iterations to catch intermittent failures
+
+Scripts run `maestro test` from inside a temp directory so screenshots don't dirty the checkout.
+
+See `packages/app/maestro/test-sidebar-theme.sh` for the canonical example:
+
+```bash
+bash packages/app/maestro/test-sidebar-theme.sh 6 1
+# Args: iterations=6, wait_seconds=1 between toggle and test
+```
+
+Key elements of the script pattern:
+
+```bash
+set -euo pipefail
+ITERATIONS="${1:-3}"
+
+for i in $(seq 1 "$ITERATIONS"); do
+  # Toggle system state
+  xcrun simctl ui booted appearance light
+
+  # Wait for change to propagate
+  sleep 1
+
+  # Run Maestro flow and capture result
+  if maestro test "$FLOW" 2>&1 | tee "$ITER_DIR/test.log"; then
+    echo "PASS"
+  else
+    echo "FAIL"
+    xcrun simctl io booted screenshot "$ITER_DIR/failure-state.png"
+  fi
+done
+```
+
+## Unistyles + Reanimated
+
+### The crash
+
+Applying Unistyles theme-reactive styles (`StyleSheet.create((theme) => ...)`) directly to `Animated.View` causes **"Unable to find node on an unmounted component"** on theme change.
+
+Unistyles wraps styled components in `<UnistylesComponent>` and patches native view properties via C++. Reanimated also manages the same native node for animated transforms. When the theme changes, both systems try to update the node simultaneously and the view crashes.
+
+### The fix
+
+Use plain React Native `StyleSheet.create` for static positioning on `Animated.View`. Pass theme-dependent values as inline styles from `useUnistyles()`:
+
+```tsx
+// BAD: Unistyles dynamic style on Animated.View
+const styles = StyleSheet.create((theme) => ({
+  sidebar: {
+    position: "absolute",
+    top: 0,
+    left: 0,
+    bottom: 0,
+    backgroundColor: theme.colors.surfaceSidebar, // theme-reactive
+    overflow: "hidden",
+  },
+}));
+
+<Animated.View style={[styles.sidebar, animatedStyle]} />
+```
+
+```tsx
+// GOOD: static stylesheet + inline theme values
+import { StyleSheet as RNStyleSheet } from "react-native";
+
+const staticStyles = RNStyleSheet.create({
+  sidebar: {
+    position: "absolute",
+    top: 0,
+    left: 0,
+    bottom: 0,
+    overflow: "hidden",
+  },
+});
+
+const { theme } = useUnistyles();
+
+<Animated.View
+  style={[staticStyles.sidebar, animatedStyle, { backgroundColor: theme.colors.surfaceSidebar }]}
+/>
+```
+
+Regular `View` components can safely use Unistyles dynamic styles — the conflict is specific to `Animated.View`.
+
+## iOS Simulator
+
+```bash
+# Screenshot
+xcrun simctl io booted screenshot /tmp/screenshot.png
+
+# Dark/light mode
+xcrun simctl ui booted appearance          # check current
+xcrun simctl ui booted appearance dark     # set dark
+xcrun simctl ui booted appearance light    # set light
+```
+
+Expo dev server logs are in the tmux pane running `npm run dev`. Daemon logs are at `$PASEO_HOME/daemon.log` (see [DEVELOPMENT.md](DEVELOPMENT.md)).

docs/PRODUCT.md

@@ -0,0 +1,74 @@
+# Product
+
+What Paseo is, who it's for, and where it's going.
+
+## What is Paseo
+
+Paseo is a next-generation development environment built around agents. One interface to run, monitor, and interact with coding agents across desktop, mobile, terminal, and web.
+
+The development workflow is shifting from manually editing files to orchestrating agents that do the editing. Paseo is built for that workflow.
+
+## Core philosophy
+
+Freedom and flexibility. Every design decision follows from this:
+
+- **Multi-provider** — Use any coding agent harness. Pick the right model for each job, switch freely as the landscape shifts. No vendor-lock in.
+- **Cross-device** — Desktop, mobile, web, CLI. Start work at your desk, check progress from your phone, script from the terminal.
+- **Self-hosted** — The daemon runs on your machine. Your code, your keys, your environment. No inference markup, no cloud dependency.
+- **Respectful** - No telemetry, no forced cloud, no forced accounts
+- **Open source** — AGPL-3.0. Users can inspect, fork, and contribute.
+- **BYOK** — Bring your own keys. Use your subsidized plans and first-party provider pricing. Paseo adds zero cost on top.
+
+## How it works
+
+### Projects and workspaces
+
+Projects are grouped in the sidebar, detected automatically from your filesystem and tagged by git remote when available.
+
+Each project opens as a workspace. For git projects, the default workspace is the main checkout. Users can create additional workspaces, which are isolated copies (git worktrees) where agents work without affecting main.
+
+### Inside a workspace
+
+A workspace is a flexible canvas:
+- Launch multiple agents side by side in split panes
+- Open terminals alongside agents
+- Mix and match providers within the same workspace
+
+### The daemon
+
+Paseo is a client-server system. The daemon (Node.js) runs on your machine, manages agent processes, and streams output in real time over WebSocket. Clients connect to the daemon — locally or remotely.
+
+This architecture means:
+- The daemon can run on any machine: laptop, VM, remote server
+- Multiple clients can connect simultaneously
+- Agents keep running when you close the app
+
+## Target user
+
+Anyone who builds software:
+
+- Care about owning their tools and their data
+- Use multiple AI providers and want to switch freely
+- Run agents on real tasks across real projects
+- Want to work from multiple devices
+
+## What compounds over time
+
+- **Trust** — Showing up daily, shipping in public, being open source. Earned slowly, lost quickly.
+- **Community contributions** — Code, packaging, skills, agent configs. Contributors become advocates.
+- **Ecosystem** — Skills, integrations, shared configs. Community-built content that makes the platform more valuable.
+
+## Strategic bets
+
+1. **Models commoditize.** Value moves to the orchestration layer. The best model changes monthly — the workflow layer stays.
+2. **Multi-provider wins.** No single provider stays on top. Developers want the best model for each task.
+3. **The daemon as infrastructure.** Server/client architecture enables deployment anywhere.
+4. **Open source outlasts funding.** Open source communities are resilient. Contributors become advocates.
+
+## Current state (March 2026)
+
+- Desktop (Electron), mobile (iOS/Android), web, CLI
+- Providers: Claude Code (Agent SDK), Codex (app-server), OpenCode
+- Daily releases
+- Community contributions starting (packaging, bug fixes)
+- Key UX: split panes, keybinding customization, workspace model

docs/PROVIDERS.md

@@ -0,0 +1,359 @@
+# Adding a New Provider to Paseo
+
+This guide walks through adding a new agent provider end-to-end. There are two integration patterns, and this doc covers both.
+
+## Two Integration Patterns
+
+### ACP (Agent Client Protocol) -- recommended
+
+Extend `ACPAgentClient`. The base class handles process spawning, stdio transport, session lifecycle, streaming, permissions, and model discovery. You provide configuration (command, modes, capabilities) and optionally override `isAvailable()` for auth checks.
+
+Existing ACP providers: `claude-acp`, `copilot`.
+
+### Direct
+
+Implement the `AgentClient` and `AgentSession` interfaces yourself. This gives full control but requires you to handle process management, streaming, permissions, and session persistence from scratch.
+
+Existing direct providers: `claude`, `codex`, `opencode`.
+
+---
+
+## ACP Provider Checklist
+
+### 1. Create the provider class
+
+Create `packages/server/src/server/agent/providers/{name}-agent.ts`.
+
+Define capabilities, modes, and a thin subclass of `ACPAgentClient`:
+
+```ts
+import type { Logger } from "pino";
+import type { AgentCapabilityFlags, AgentMode } from "../agent-sdk-types.js";
+import type { ProviderRuntimeSettings } from "../provider-launch-config.js";
+import { ACPAgentClient } from "./acp-agent.js";
+
+const MY_PROVIDER_CAPABILITIES: AgentCapabilityFlags = {
+  supportsStreaming: true,
+  supportsSessionPersistence: true,
+  supportsDynamicModes: true,
+  supportsMcpServers: true,
+  supportsReasoningStream: true,
+  supportsToolInvocations: true,
+};
+
+const MY_PROVIDER_MODES: AgentMode[] = [
+  {
+    id: "default",
+    label: "Default",
+    description: "Standard agent mode",
+  },
+  // Add more modes as needed
+];
+
+type MyProviderClientOptions = {
+  logger: Logger;
+  runtimeSettings?: ProviderRuntimeSettings;
+};
+
+export class MyProviderACPAgentClient extends ACPAgentClient {
+  constructor(options: MyProviderClientOptions) {
+    super({
+      provider: "my-provider",        // Must match the ID used everywhere else
+      logger: options.logger,
+      runtimeSettings: options.runtimeSettings,
+      defaultCommand: ["my-agent-binary", "--acp"],  // CLI command to spawn
+      defaultModes: MY_PROVIDER_MODES,
+      capabilities: MY_PROVIDER_CAPABILITIES,
+    });
+  }
+
+  // Override isAvailable() if the provider needs specific auth/env vars
+  override async isAvailable(): Promise<boolean> {
+    if (!(await super.isAvailable())) {
+      return false;  // Binary not found
+    }
+    return Boolean(process.env["MY_PROVIDER_API_KEY"]);
+  }
+}
+```
+
+The `super.isAvailable()` call checks that the binary from `defaultCommand` is on `$PATH`. Override only to add credential checks on top.
+
+For reference, here is how Copilot does it -- no auth override needed because the CLI handles auth itself:
+
+```ts
+export class CopilotACPAgentClient extends ACPAgentClient {
+  constructor(options: CopilotACPAgentClientOptions) {
+    super({
+      provider: "copilot",
+      logger: options.logger,
+      runtimeSettings: options.runtimeSettings,
+      defaultCommand: ["copilot", "--acp"],
+      defaultModes: COPILOT_MODES,
+      capabilities: COPILOT_CAPABILITIES,
+    });
+  }
+
+  override async isAvailable(): Promise<boolean> {
+    return super.isAvailable();
+  }
+}
+```
+
+### 2. Add to the provider manifest
+
+In `packages/server/src/server/agent/provider-manifest.ts`, add mode definitions with UI metadata (icons, color tiers) and a provider definition entry.
+
+First, define the modes with visual metadata:
+
+```ts
+const MY_PROVIDER_MODES: AgentProviderModeDefinition[] = [
+  {
+    id: "default",
+    label: "Default",
+    description: "Standard agent mode",
+    icon: "ShieldCheck",
+    colorTier: "safe",
+  },
+  {
+    id: "autonomous",
+    label: "Autonomous",
+    description: "Runs without prompting",
+    icon: "ShieldOff",
+    colorTier: "dangerous",
+  },
+];
+```
+
+Available `colorTier` values: `"safe"`, `"moderate"`, `"dangerous"`, `"planning"`.
+Available `icon` values: `"ShieldCheck"`, `"ShieldAlert"`, `"ShieldOff"`.
+
+Then add to the `AGENT_PROVIDER_DEFINITIONS` array:
+
+```ts
+export const AGENT_PROVIDER_DEFINITIONS: AgentProviderDefinition[] = [
+  // ... existing providers ...
+  {
+    id: "my-provider",
+    label: "My Provider",
+    description: "Short description of the provider",
+    defaultModeId: "default",
+    modes: MY_PROVIDER_MODES,
+    // Optional: enable voice
+    voice: {
+      enabled: true,
+      defaultModeId: "default",
+      defaultModel: "some-model",
+    },
+  },
+];
+```
+
+### 3. Add the factory to the provider registry
+
+In `packages/server/src/server/agent/provider-registry.ts`, import your class and add a factory entry:
+
+```ts
+import { MyProviderACPAgentClient } from "./providers/my-provider-agent.js";
+
+const PROVIDER_CLIENT_FACTORIES: Record<string, ProviderClientFactory> = {
+  // ... existing factories ...
+  "my-provider": (logger, runtimeSettings) =>
+    new MyProviderACPAgentClient({
+      logger,
+      runtimeSettings: runtimeSettings?.["my-provider"],
+    }),
+};
+```
+
+### 4. Add a provider icon (app)
+
+Create `packages/app/src/components/icons/my-provider-icon.tsx` following the pattern from existing icons (e.g., `claude-icon.tsx`):
+
+```tsx
+import Svg, { Path } from "react-native-svg";
+
+interface MyProviderIconProps {
+  size?: number;
+  color?: string;
+}
+
+export function MyProviderIcon({ size = 16, color = "currentColor" }: MyProviderIconProps) {
+  return (
+    <Svg width={size} height={size} viewBox="0 0 24 24" fill={color}>
+      <Path d="..." />
+    </Svg>
+  );
+}
+```
+
+Then register it in `packages/app/src/components/provider-icons.ts`:
+
+```ts
+import { MyProviderIcon } from "@/components/icons/my-provider-icon";
+
+const PROVIDER_ICONS: Record<string, typeof Bot> = {
+  claude: ClaudeIcon as unknown as typeof Bot,
+  codex: CodexIcon as unknown as typeof Bot,
+  "my-provider": MyProviderIcon as unknown as typeof Bot,
+};
+```
+
+If no icon is registered, the app falls back to a generic `Bot` icon from lucide.
+
+### 5. Add E2E test config
+
+In `packages/server/src/server/daemon-e2e/agent-configs.ts`, add your provider:
+
+```ts
+export const agentConfigs = {
+  // ... existing configs ...
+  "my-provider": {
+    provider: "my-provider",
+    model: "default-model-id",
+    modes: {
+      full: "autonomous",   // Mode with no permission prompts
+      ask: "default",       // Mode that requires permission approval
+    },
+  },
+} as const satisfies Record<string, AgentTestConfig>;
+```
+
+Add an availability check in `isProviderAvailable()`:
+
+```ts
+case "my-provider":
+  return (
+    isCommandAvailable("my-agent-binary") &&
+    Boolean(process.env.MY_PROVIDER_API_KEY)
+  );
+```
+
+Add to the `allProviders` array:
+
+```ts
+export const allProviders: AgentProvider[] = [
+  "claude",
+  "claude-acp",
+  "codex",
+  "copilot",
+  "opencode",
+  "my-provider",
+];
+```
+
+### 6. Run typecheck
+
+```bash
+npm run typecheck
+```
+
+This is required after every change per project rules.
+
+---
+
+## Direct Provider Checklist
+
+If your agent does not speak ACP, implement the interfaces from `agent-sdk-types.ts` directly.
+
+### Interfaces to implement
+
+**`AgentClient`** -- factory for sessions and model listing:
+
+```ts
+interface AgentClient {
+  readonly provider: AgentProvider;
+  readonly capabilities: AgentCapabilityFlags;
+  createSession(config: AgentSessionConfig, launchContext?: AgentLaunchContext): Promise<AgentSession>;
+  resumeSession(handle: AgentPersistenceHandle, overrides?: Partial<AgentSessionConfig>, launchContext?: AgentLaunchContext): Promise<AgentSession>;
+  listModels(options?: ListModelsOptions): Promise<AgentModelDefinition[]>;
+  isAvailable(): Promise<boolean>;
+  // Optional:
+  listPersistedAgents?(options?: ListPersistedAgentsOptions): Promise<PersistedAgentDescriptor[]>;
+}
+```
+
+**`AgentSession`** -- a running agent conversation:
+
+```ts
+interface AgentSession {
+  readonly provider: AgentProvider;
+  readonly id: string | null;
+  readonly capabilities: AgentCapabilityFlags;
+  run(prompt: AgentPromptInput, options?: AgentRunOptions): Promise<AgentRunResult>;
+  startTurn(prompt: AgentPromptInput, options?: AgentRunOptions): Promise<{ turnId: string }>;
+  subscribe(callback: (event: AgentStreamEvent) => void): () => void;
+  streamHistory(): AsyncGenerator<AgentStreamEvent>;
+  getRuntimeInfo(): Promise<AgentRuntimeInfo>;
+  getAvailableModes(): Promise<AgentMode[]>;
+  getCurrentMode(): Promise<string | null>;
+  setMode(modeId: string): Promise<void>;
+  getPendingPermissions(): AgentPermissionRequest[];
+  respondToPermission(requestId: string, response: AgentPermissionResponse): Promise<void>;
+  describePersistence(): AgentPersistenceHandle | null;
+  interrupt(): Promise<void>;
+  close(): Promise<void>;
+  // Optional:
+  listCommands?(): Promise<AgentSlashCommand[]>;
+  setModel?(modelId: string | null): Promise<void>;
+  setThinkingOption?(thinkingOptionId: string | null): Promise<void>;
+}
+```
+
+### Steps
+
+1. Create `packages/server/src/server/agent/providers/{name}-agent.ts` implementing both interfaces
+2. Add to the provider manifest (same as ACP step 2 above)
+3. Add factory to the registry (same as ACP step 3 above)
+4. Add icon (same as ACP step 4 above)
+5. Add E2E config (same as ACP step 5 above)
+6. Run typecheck
+
+---
+
+## Testing
+
+### Manual testing with the CLI
+
+Start the daemon if not already running, then:
+
+```bash
+# Launch an agent with your provider
+paseo run --provider my-provider
+
+# Launch with a specific model and mode
+paseo run --provider my-provider --model some-model --mode default
+
+# List running agents
+paseo ls -a -g
+
+# Check if the provider reports models
+paseo models --provider my-provider
+```
+
+### E2E test patterns
+
+The E2E configs in `agent-configs.ts` expose two helpers:
+
+- `getFullAccessConfig(provider)` -- returns config for a session with no permission prompts
+- `getAskModeConfig(provider)` -- returns config for a session that triggers permission requests
+
+Tests use `isProviderAvailable(provider)` to skip when the binary or credentials are missing, so CI will not fail for providers that are not installed.
+
+---
+
+## Gotchas
+
+**Mode IDs can be URIs.** ACP providers like Copilot use full URIs as mode IDs (e.g., `"https://agentclientprotocol.com/protocol/session-modes#agent"`). Never assume mode IDs are simple strings. The manifest `defaultModeId` must match exactly.
+
+**Models and modes are discovered dynamically.** ACP providers report available models and modes at runtime via the protocol. The static definitions in `provider-manifest.ts` are used for UI scaffolding (icons, color tiers) but the runtime values from the agent process are the source of truth.
+
+**`AgentProvider` is always `string`.** The type alias is `type AgentProvider = string`. Provider IDs are validated against the manifest at runtime, not at the type level.
+
+**Auth patterns vary.** Some providers need API keys in env vars (`ANTHROPIC_API_KEY`, `OPENAI_API_KEY`), some use OAuth tokens (`CLAUDE_CODE_OAUTH_TOKEN`), some use auth files (`~/.codex/auth.json`), and some handle auth entirely in their CLI binary (Copilot). Your `isAvailable()` method should check whatever is needed.
+
+**The manifest mode list and the agent class mode list are separate.** The manifest in `provider-manifest.ts` includes UI metadata (`icon`, `colorTier`). The agent class defines modes without UI metadata (just `id`, `label`, `description`). Keep them in sync.
+
+**`defaultCommand` is a tuple.** The first element is the binary name, the rest are default arguments. The base class uses this to find the executable and spawn the process.
+
+**Runtime settings can override the command.** Users can configure custom binary paths or environment variables per provider via `ProviderRuntimeSettings`. Your factory in the registry should pass `runtimeSettings?.["your-provider"]` through to the constructor.

docs/RELEASE.md

@@ -0,0 +1,177 @@
+# Release
+
+All workspaces share one version and release together.
+
+## Two paths
+
+There are two supported ways to ship from `main`:
+
+1. **Direct stable release**: you are ready to ship the current `main` commit to everyone immediately.
+2. **Release candidate flow**: you want public test builds first, but you are not ready for the website, npm, or production mobile release flows to move yet.
+
+## Standard release (patch)
+
+Before running any stable patch release command:
+
+- Make sure the intended release commit is already committed to `main` and the working tree is clean.
+- Make sure local `npm run typecheck` passes on that commit.
+- Do not use `npm run release:patch` as a substitute for checking whether the current commit is actually ready.
+
+```bash
+npm run release:patch
+```
+
+This bumps the version across all workspaces, runs checks, publishes to npm, and pushes the branch + tag (triggering desktop, APK, and EAS mobile workflows).
+
+If asked to "release paseo" without specifying major/minor, treat it as a patch release.
+
+Use the direct stable path when the current `main` changes are ready to become the public release immediately.
+
+## Manual step-by-step
+
+```bash
+npm run typecheck            # Verify the exact commit you intend to release
+npm run release:check        # Typecheck, build, dry-run pack
+npm run version:all:patch    # Bump version, create commit + tag
+npm run release:publish      # Publish to npm
+npm run release:push         # Push HEAD + tag (triggers CI workflows)
+```
+
+## Release candidate flow
+
+```bash
+npm run release:rc:patch       # Bump to X.Y.Z-rc.1, push commit + tag
+# ... test desktop and APK prerelease assets from GitHub Releases ...
+npm run release:rc:next        # Optional: cut X.Y.Z-rc.2, rc.3, ...
+npm run release:promote        # Promote X.Y.Z-rc.N to stable X.Y.Z
+```
+
+- RC tags are published GitHub prereleases like `v0.1.41-rc.1`
+- RCs publish desktop assets and APKs for testing, but they do not publish npm packages and do not trigger the production web/mobile release flows
+- `release:promote` creates a fresh stable tag like `v0.1.41`; the final release never reuses the RC tag
+- Desktop assets now come from the Electron package at `packages/desktop`
+- **Do NOT create a changelog entry for RCs.** The changelog remains stable-only. RC release notes are generated automatically so the website stays pinned to the latest published stable release.
+
+Use the RC path when you need to:
+
+- test a build manually in a Linux or Windows VM
+- send a build to a user who is hitting a specific problem
+- iterate on `rc.1`, `rc.2`, `rc.3`, and so on before deciding to ship broadly
+
+## Website behavior
+
+- The website download page points to GitHub's latest published **stable** release.
+- Published RC prereleases are public on GitHub Releases, but they do **not** become the website download target.
+- The website only moves when you publish the final stable release tag like `v0.1.41`.
+
+## Fixing a failed release build
+
+**NEVER bump the version to fix a build problem.** New versions are reserved for meaningful product changes (features, fixes, improvements). Build/CI failures are fixed on the current version.
+
+**Do not rely on `workflow_dispatch` for tagged code fixes.** The `workflow_dispatch` trigger runs the workflow file from the default branch but checks out the code at the tag ref (`ref: ${{ inputs.tag }}`). That means fixes committed to `main` won't change the tagged source tree being built. `workflow_dispatch` only helps when the fix lives in the workflow file itself.
+
+To retry a failed workflow, **always push a retry tag** on the commit you want to build. Reusing the same tag name is expected: move it with `git tag -f ...` and push it with `--force` so the workflow rebuilds the commit you actually want.
+
+Prefer a tag push over `workflow_dispatch` whenever you are rebuilding release code or release assets.
+
+The retry tag patterns below still work and remain the supported way to rebuild specific release targets:
+
+```bash
+# Desktop (all platforms)
+git tag -f desktop-v0.1.28 HEAD && git push origin desktop-v0.1.28 --force
+
+# Desktop (single platform)
+git tag -f desktop-macos-v0.1.28 HEAD && git push origin desktop-macos-v0.1.28 --force
+git tag -f desktop-linux-v0.1.28 HEAD && git push origin desktop-linux-v0.1.28 --force
+git tag -f desktop-windows-v0.1.28 HEAD && git push origin desktop-windows-v0.1.28 --force
+
+# Android APK
+git tag -f android-v0.1.28 HEAD && git push origin android-v0.1.28 --force
+
+# RC
+git tag -f v0.1.29-rc.2 HEAD && git push origin v0.1.29-rc.2 --force
+```
+
+This ensures the checkout ref matches the actual code on `main` with the fix included.
+
+- `vX.Y.Z` or `vX.Y.Z-rc.N` rebuilds the full tagged release
+- `desktop-vX.Y.Z` rebuilds desktop for all desktop platforms only
+- `desktop-macos-vX.Y.Z`, `desktop-linux-vX.Y.Z`, and `desktop-windows-vX.Y.Z` rebuild only that desktop platform
+- `android-vX.Y.Z` rebuilds the Android APK release only
+
+## Notes
+
+- `version:all:*` bumps root + syncs workspace versions and `@getpaseo/*` dependency versions
+- `release:prepare` refreshes workspace `node_modules` links to prevent stale types
+- `npm run dev:desktop` and `npm run build:desktop` target the Electron desktop package in `packages/desktop`
+- If `release:publish` partially fails, re-run it — npm skips already-published versions
+- The website uses GitHub's latest published release API for download links, so published RC prereleases do not replace the stable download target.
+
+## Changelog format
+
+Stable release notes depend on the changelog heading format. The heading **must** be strictly followed:
+
+```
+## X.Y.Z - YYYY-MM-DD
+```
+
+No prefix (`v`), no extra text. The parser matches the first `## X.Y.Z` line to extract the version. A malformed heading will break download links on the homepage.
+
+## Changelog policy
+
+- `CHANGELOG.md` is for **final stable releases only**.
+- Do not add or edit changelog entries while iterating on RCs.
+- Write the proper changelog entry when you are cutting the final stable release that comes after the RC cycle.
+- Between stable releases, keep changelog work out of the repo until the final release is ready.
+
+## Changelog ownership
+
+- **Only Claude should write changelog entries.**
+- If you are Codex and a stable release needs a changelog entry, launch a Claude agent with Paseo to draft it, then review and commit the result.
+
+## Changelog voice
+
+The changelog is shown on the Paseo homepage. Write it for **end users**, not developers.
+
+- **Frame everything from the user's perspective.** Describe what changed in the app, not what changed in the code. Users care that "workspaces load instantly" — not that a component no longer remounts.
+- **Never mention component names, internal modules, or implementation details.** No `WorkingIndicator`, no `accumulatedUsage`, no `reconcileAndEmitWorkspaceUpdates`.
+- **Collapse internal iterations.** If a feature was added and then fixed within the same release, just list the feature as working. Users never saw the broken version.
+- **Only list changes relative to the previous stable release.** The diff is `v(previous)..HEAD`. If something was introduced and fixed between those two tags, it never shipped — don't mention the fix.
+- **Cut low-signal entries.** "Toolbar buttons have consistent sizing" is too granular. Combine small polish items or drop them.
+
+## Pre-release sanity check
+
+Before cutting any release (RC or stable), run a Codex review of the diff as a last line of defence against shipping bugs.
+
+Load the `paseo` skill and launch a **Codex 5.4** agent with a prompt like:
+
+> Review the diff between the latest release tag and HEAD. Focus on:
+>
+> 1. **Breaking changes** — especially in the WebSocket protocol, agent lifecycle, and any server↔client contract.
+> 2. **Backward compatibility** — the important direction is old app clients talking to newly updated daemons. Users update desktop and daemon first, then keep running the old app for a while. Flag anything that breaks old clients against new daemons or requires both sides to update in lockstep.
+> 3. **Regressions** — anything that looks like it could break existing functionality.
+>
+> Diff: `git diff <latest-release-tag>..HEAD`
+
+The agent's job is a deep sanity check, not a full code review. If it flags anything, investigate before proceeding.
+
+## Changelog scope
+
+The changelog always covers **stable-to-HEAD**:
+
+- **RC release**: the diff and release notes cover `latest stable tag → HEAD`. RC release notes are auto-generated and not added to `CHANGELOG.md`.
+- **Stable release**: the diff and changelog entry cover `latest stable tag → HEAD`. Any intermediate RCs are skipped — the changelog captures the full delta from the previous stable release, not just what changed since the last RC.
+
+In other words, RCs are checkpoints along the way; the changelog only records the final jump from one stable version to the next.
+
+## Completion checklist
+
+- [ ] Run the pre-release sanity check (see above) and address any findings
+- [ ] Ensure the intended release commit is already committed and the git worktree is clean before running any `release:*` patch/promote command
+- [ ] Ensure local `npm run typecheck` passes on that exact commit before running any `release:*` patch/promote command
+- [ ] Update `CHANGELOG.md` with user-facing release notes (features, fixes — not refactors)
+- [ ] Verify the changelog heading follows strict `## X.Y.Z - YYYY-MM-DD` format
+- [ ] `npm run release:patch` or `npm run release:promote` completes successfully
+- [ ] GitHub `Desktop Release` workflow for the `v*` tag is green
+- [ ] GitHub `Android APK Release` workflow for the same tag is green
+- [ ] EAS `release-mobile.yml` workflow for the same tag is green

docs/TESTING.md

@@ -0,0 +1,123 @@
+# Testing
+
+## Philosophy
+
+Tests prove behavior, not structure. Every test should answer: "what user-visible or API-visible behavior does this verify?"
+
+## Test-driven development
+
+Work in vertical slices: one test, one implementation, repeat. Each test responds to what you learned from the previous cycle.
+
+```
+RIGHT (vertical):
+  RED→GREEN: test1→impl1
+  RED→GREEN: test2→impl2
+  RED→GREEN: test3→impl3
+
+WRONG (horizontal):
+  RED:   test1, test2, test3, test4, test5
+  GREEN: impl1, impl2, impl3, impl4, impl5
+```
+
+Writing all tests first then all implementation produces bad tests — you end up testing imagined behavior instead of actual behavior.
+
+## Determinism first
+
+Tests must produce the same result every run:
+
+- No conditional assertions or branching paths
+- No reliance on timing, randomness, or network jitter
+- No weak assertions (`toBeTruthy`, `toBeDefined`)
+- Assert the full intended behavior, not fragments
+
+```typescript
+// Bad: conditional and weak
+it("creates a tool call", async () => {
+  const result = await createToolCall(input);
+  if (result.ok) {
+    expect(result.id).toBeDefined();
+  }
+});
+
+// Good: deterministic and explicit
+it("returns timeout error when provider times out", async () => {
+  const result = await createToolCall(input);
+  expect(result).toEqual({
+    ok: false,
+    error: { code: "PROVIDER_TIMEOUT", waitedMs: 30000 },
+  });
+});
+```
+
+## Flaky tests are a bug
+
+Never remove a test because it's flaky. Find the variance source (time, randomness, race condition, shared state, non-deterministic output, environment drift) and fix it.
+
+## Real dependencies over mocks
+
+Mocks are not the default. They require an explicit decision.
+
+- **Database**: real test database, not a mock
+- **APIs**: real APIs with test/sandbox credentials, not request mocks
+- **File system**: temporary directory that gets cleaned up, not fs mocks
+
+Ask: "will this still hold with real dependencies at runtime?" If no, don't mock.
+
+### Use swappable adapters instead
+
+When you need test isolation, design code so dependencies are injectable:
+
+```typescript
+interface EmailSender {
+  send(to: string, body: string): Promise<void>;
+}
+
+// Production
+const realSender: EmailSender = { send: sendgrid.send };
+
+// Test: in-memory adapter
+function createTestEmailSender() {
+  const sent: Array<{ to: string; body: string }> = [];
+  return {
+    send: async (to: string, body: string) => { sent.push({ to, body }); },
+    sent,
+  };
+}
+```
+
+## End-to-end means end-to-end
+
+When a test is labeled end-to-end, it calls the real service. No environment variable gates, no conditional skipping, no mocking the external dependency.
+
+## Test organization
+
+- Collocate tests with implementation: `thing.ts` + `thing.test.ts`
+- Extract complex setup into reusable helpers
+- Test bodies should read like plain English
+- Build a vocabulary of test helpers that make complex flows simple
+
+## Agent authentication in tests
+
+Agent providers handle their own auth. Do not add auth checks, environment variable gates, or conditional skips to tests. If auth fails, report it.
+
+## Debugging with tests
+
+Use the test as your debugging ground:
+
+1. Add temporary logging to the code under test
+2. Run the test, observe actual values
+3. Trace the flow end-to-end through test output
+4. Confirm each assumption with actual output
+5. Remove logging when done
+
+The test output is the source of truth, not your reading of the code.
+
+## Design for testability
+
+If code isn't testable, refactor it. Signs:
+- You want to reach for a mock
+- You can't inject a dependency
+- You need to test private internals
+- Setup requires too much global state
+
+Aim for deep modules: small interface, deep implementation. Fewer methods = fewer tests needed, simpler params = simpler setup.

docs/ad-hoc-daemon-testing.md

@@ -1,165 +0,0 @@
-# Ad-hoc daemon testing
-
-Spin up an isolated in-process daemon test harness without touching the main daemon on port 6767.
-
-This is for test code only. Executable daemon processes must start through
-`scripts/supervisor-entrypoint.ts` or `dist/scripts/supervisor-entrypoint.js`;
-do not use `createPaseoDaemon` as a product launch path.
-
-## Quick start
-
-```typescript
-import os from "node:os";
-import path from "node:path";
-import { mkdir, mkdtemp, rm } from "node:fs/promises";
-import pino from "pino";
-import { createPaseoDaemon } from "./bootstrap.js";
-import { DaemonClient } from "./test-utils/daemon-client.js";
-
-const logger = pino({ level: "warn" });
-const paseoHomeRoot = await mkdtemp(path.join(os.tmpdir(), "paseo-test-"));
-const paseoHome = path.join(paseoHomeRoot, ".paseo");
-await mkdir(paseoHome, { recursive: true });
-const staticDir = await mkdtemp(path.join(os.tmpdir(), "paseo-static-"));
-
-const daemon = await createPaseoDaemon(
-  {
-    listen: "127.0.0.1:0", // OS picks a free port
-    paseoHome,
-    corsAllowedOrigins: [],
-    hostnames: true,
-    mcpEnabled: false,
-    staticDir,
-    mcpDebug: false,
-    agentClients: {},
-    agentStoragePath: path.join(paseoHome, "agents"),
-    relayEnabled: false,
-    relayEndpoint: "relay.paseo.sh:443",
-    appBaseUrl: "https://app.paseo.sh",
-    // Add custom config here, e.g.:
-    // providerOverrides: { ... },
-  },
-  logger,
-);
-
-await daemon.start();
-const target = daemon.getListenTarget();
-const port = target!.type === "tcp" ? target!.port : null;
-
-const client = new DaemonClient({
-  url: `ws://127.0.0.1:${port}/ws`,
-  appVersion: "0.1.70", // see gotcha #1
-});
-await client.connect();
-await client.fetchAgents({ subscribe: {} });
-
-// ... do your testing ...
-
-await client.close();
-await daemon.stop();
-await rm(paseoHomeRoot, { recursive: true, force: true });
-await rm(staticDir, { recursive: true, force: true });
-```
-
-Run with:
-
-```bash
-npx tsx packages/server/src/server/your-script.ts
-```
-
-## Using the test helper
-
-For simpler cases, `createTestPaseoDaemon` + `DaemonClient` handles temp dirs and port selection:
-
-```typescript
-import { createTestPaseoDaemon } from "./test-utils/paseo-daemon.js";
-import { DaemonClient } from "./test-utils/daemon-client.js";
-
-const daemon = await createTestPaseoDaemon();
-const client = new DaemonClient({
-  url: `ws://127.0.0.1:${daemon.port}/ws`,
-  appVersion: "0.1.70",
-});
-await client.connect();
-await client.fetchAgents({ subscribe: {} });
-
-// ... test ...
-
-await client.close();
-await daemon.close(); // stops daemon + cleans up temp dirs
-```
-
-The test helper does **not** expose `providerOverrides`. In test harnesses, use `createPaseoDaemon` directly when you need it (see quick start above).
-
-## Common client methods
-
-```typescript
-// Provider discovery
-const snapshot = await client.getProvidersSnapshot({ cwd: "/tmp" });
-const models = await client.listProviderModels("claude");
-const modes = await client.listProviderModes("claude");
-
-// Agent lifecycle
-const agent = await client.createAgent({ provider: "claude", cwd: "/tmp" });
-await client.sendMessage(agent.id, "Hello");
-const updated = await client.waitForAgentUpsert(agent.id, (s) => s.status === "idle");
-```
-
-## Gotchas
-
-### 1. appVersion gates provider visibility
-
-The daemon hides non-legacy providers (anything other than claude, codex, opencode) from clients that don't send an `appVersion >= 0.1.45`. The `DaemonClient` sends no version by default, so custom providers like ACP-based ones will be invisible in snapshot responses.
-
-Always pass `appVersion`:
-
-```typescript
-const client = new DaemonClient({
-  url: `ws://127.0.0.1:${port}/ws`,
-  appVersion: "0.1.70",
-});
-```
-
-### 2. Provider snapshots are async
-
-After the daemon starts, providers are probed in the background. The first `getProvidersSnapshot()` call will likely return `status: "loading"` for most providers. Poll until the provider you care about is no longer loading:
-
-```typescript
-let snapshot = await client.getProvidersSnapshot({ cwd: "/tmp" });
-for (let i = 0; i < 20; i++) {
-  const entry = snapshot.entries.find((e) => e.provider === "gemini");
-  if (entry && entry.status !== "loading") break;
-  await new Promise((r) => setTimeout(r, 2_000));
-  snapshot = await client.getProvidersSnapshot({ cwd: "/tmp" });
-}
-```
-
-### 3. fetchAgents is required before most operations
-
-Call `client.fetchAgents()` after connecting. The daemon session expects this handshake before it processes other requests — without it, messages like `get_providers_snapshot_request` will silently hang.
-
-### 4. listen: "127.0.0.1:0" for port allocation
-
-Always use port `0` so the OS picks a free port. Never hardcode a port — it will collide with the main daemon or other test runs.
-
-### 5. Script must live inside packages/server
-
-The test utilities use relative imports through the TypeScript project. Place your script somewhere under `packages/server/src/` and import from there. Scripts outside the repo will fail with module resolution errors.
-
-### 6. Cleanup on failure
-
-Wrap your test logic in try/finally to ensure the daemon stops and temp dirs are cleaned up, even if an assertion fails:
-
-```typescript
-try {
-  // ... test logic ...
-} finally {
-  await client.close();
-  await daemon.stop().catch(() => undefined);
-  await rm(paseoHomeRoot, { recursive: true, force: true });
-}
-```
-
-### 7. ACP providers spawn real processes
-
-When testing ACP providers (e.g., Gemini with `extends: "acp"`), the daemon will spawn real processes to probe for models and modes. The binary must be installed and on PATH. Probing can take 5-15 seconds depending on the provider.

docs/agent-lifecycle.md

@@ -1,281 +0,0 @@
-# Agent lifecycle
-
-How an agent is created, runs, becomes a subagent, gets archived, and disappears from the UI. The model spans the daemon (lifecycle, archive) and the client (tabs, the subagents track).
-
-## States
-
-```
-initializing → idle → running → idle (or error → closed)
-                 ↑        │
-                 └────────┘  (agent completes a turn, awaits next prompt)
-```
-
-Each live agent in `AgentManager` carries a `lastStatus` of `initializing`, `idle`, `running`, or `error`. `closed` is the persisted, resumable state for an agent record that has no live provider runtime. State transitions persist to disk and stream to subscribed clients via WebSocket.
-
-## Runtime residency
-
-An unarchived agent may be `closed` without being deleted or archived. Closing releases its provider
-processes and subscriptions while retaining its Paseo identity, persistence handle, timeline,
-workspace, labels, title, usage, attention, timestamps, and parent relationship. Opening or prompting
-the agent runs through `ensureAgentLoaded()`, which resumes the durable provider session under the
-same Paseo agent ID. Provider history is not appended again when the canonical timeline is already
-primed.
-
-Reload releases the old runtime before resuming its durable session: an idle provider process can
-still own an exclusive writer. A close failure retains that runtime for cleanup and blocks the
-replacement. Once closure succeeds, a failed resume leaves the durable agent closed and retryable.
-
-Idle agents remain resident indefinitely. Runtime closure happens only through an explicit lifecycle
-action such as archive, replacement, reload, workspace teardown, or daemon shutdown.
-
-A provider runtime can still die on its own — crash, OOM kill, host suspend. Work the agent parked
-inside that process dies with it: Claude Code's background Bash shells, `Monitor` watches, and
-workflows all live in the CLI process, and the completion notification that would have woken the
-agent never arrives. A runtime that dies mid-turn is reported by whatever is draining its stream, but
-between turns nothing is watching, so the agent sits at `idle` looking healthy while its background
-work is gone. Report that exit as a turn failure so the agent lands in `error` with a timeline entry.
-Claude and OMP report exits between turns. OMP relaunches from its session file on the next prompt;
-the unfinished turn is lost.
-
-### Cancellation
-
-Provider interruption is idempotent at the `AgentSession` boundary. It resolves when the prior
-foreground turn can no longer run, including when the provider reports that it is already idle. It
-rejects only when the provider may still own the turn. Provider adapters translate native errors
-into that contract; lifecycle callers do not interpret provider-specific errors.
-
-After an acknowledged interrupt, the manager settles the captured run even when no terminal event
-arrives or the run was still waiting for its provider turn id. The captured run token prevents an
-older cancellation from settling a newer turn. If interruption is rejected or times out, the agent
-keeps its active foreground turn and replacement, reload, rewind, and Stop report the failure.
-Accepting new work after an ambiguous interruption would create a split-brain session.
-
-## Relationships
-
-Agents can launch other agents via the agent-scoped `create_agent` MCP tool. Agent-scoped creation is always asynchronous and always stamps `paseo.parent-agent-id`, pointing back at the caller. Omit `workspaceId` to use the caller's workspace, or pass an existing workspace ID returned by `create_workspace`. Placement never changes parentage.
-
-- **Subagents** — exist as part of the creating agent's work, appear in that agent's subagent track, and are archived with it.
-- **Detached agents** — stand on their own after an explicit detach transition, do not appear in the former parent's subagent track, and are not archived with it.
-
-Parent archive detaches a subagent instead of archiving it when either condition holds:
-
-- The child belongs to another workspace.
-- The child is currently open in an agent tab.
-
-All other children archive with the parent. After the workspace layout hydrates, the client marks
-every managed subagent present in its tabs with `paseo.open-agent-tab.<client-id>=true` through the
-generic agent metadata update. This includes background and restored tabs; navigation does not own
-the marker. Closing a tab sets that client's label to `false`. Any `true` client label keeps the child
-open. Detach clears the parent and every open-tab label. The surviving child therefore becomes a
-normal root agent immediately, and closing its still-open tab archives it.
-
-Runtime ownership is resolved from explicit workspace ID and caller context, never from `cwd`. Workspace creation is a separate operation with `local | worktree` isolation; agent creation reuses that workspace unless a new workspace is explicitly requested.
-
-Users can also detach an existing subagent from the subagents track. Detach is deliberately a manual lifecycle gesture, not an agent-facing MCP tool. It removes the parent and open-tab lifecycle labels: it does not stop, archive, move, or restart the agent. The agent keeps its current `cwd` and `workspaceId`, leaves the former parent's track, and behaves like a root agent for tab close, workspace activity, and future parent archive.
-
-`notifyOnFinish` defaults to `true` for agent-scoped creation and prompt follow-ups because most delegated work needs to report back to the creating agent. Set it to `false` only for truly fire-and-forget agents or prompts.
-Permission requests are notification checkpoints, not the end of that subscription. The caller is notified again after a permission response when the child finishes, errors, or requests another permission.
-The permission notification includes the normalized request plus the child and request IDs, so the caller can inspect it and respond without fetching agent status.
-A watched child that closes before its finish event also notifies the caller so delegated work cannot disappear silently during archive or workspace teardown.
-
-## Provider-managed child agents
-
-Some providers can create their own child sessions inside one provider runtime. OMP's task tool reports these with `child_session` events; `AgentManager` imports the live provider handle, stamps `paseo.parent-agent-id`, and surfaces the result as a normal subagent in the parent's subagents track.
-
-The provider still owns the underlying runtime. Paseo keeps an agent record so the child can be opened, tracked, archived, and cascaded with the parent, but prompts and history hydration route through the provider adapter for that native child handle.
-
-## Background workspaces
-
-`workspace.background` controls discovery only. Background workspaces contain ordinary durable
-agents and terminals: provider history, plugin hooks, parentage, archive, and restart recovery
-keep their normal behavior. Visibility is creation-only; selecting an existing workspace cannot
-change it. New workspaces default to false, inherit the caller workspace's value when an agent
-creates one without an override, and accept explicit true or false.
-
-The daemon derives agent discovery from workspace ownership. Default workspace and agent lists,
-including History requests, exclude background work; `filter.includeBackground` includes it.
-Exact-ID operations bypass discovery filtering. The app replicates both kinds and filters only
-its sidebar with **Show background**, so direct navigation and restored tabs remain available.
-
-Sequenced directories keep complete canonical collections. A filtered read must never replace
-those collections with its subset. Inclusive and default observations have distinct cursor
-scopes, so changing scope requires a fresh snapshot rather than reusing an incomplete cache.
-Clients gate creation and inclusive discovery on `features.backgroundWorkspaces`.
-
-### Private daemon helpers
-
-Branch-name and commit-message generators still use private disposable internal runtimes.
-`AgentManager` does not persist them or their provider sessions, excludes them from public
-discovery and plugin hooks, and drops their timelines on archive. An archived helper retains
-its exact-ID result briefly to cover completion before a waiter attaches. This internal
-lifecycle is separate from public workspace visibility and is not a public creation option.
-
-## Archive
-
-Archive is a **soft delete**: the agent record stays on disk with `archivedAt` set, the runtime is closed, and the agent disappears from active lists. Archive is **global** — it lives on the server and propagates to every connected client.
-
-Archive sets `archivedAt`, invokes the provider's native archive hook, and cascades to managed
-children.
-
-`create_agent_request` can opt an agent into `autoArchive`. In that mode the daemon archives the agent after the first terminal turn event (`turn_completed`, `turn_failed`, or `turn_canceled`). When the agent owns an isolated workspace, auto-archive archives that workspace too; the managed worktree is removed when its final workspace reference is gone.
-
-Archiving runs through `AgentManager.archiveAgent` (`packages/server/src/server/agent/agent-manager.ts`):
-
-1. Snapshot the current session into the registry
-2. Set `archivedAt` and normalize `lastStatus` away from `running`/`initializing`
-3. Notify subscribers
-4. Close the runtime (kills the process if still running)
-5. **Resolve children** — detach cross-workspace and open-tab children; cascade-archive the rest recursively
-
-Cascade is what keeps subagent fleets from outliving their orchestrator.
-
-Workspace archive is a separate lifecycle. Archiving or removing a worktree can close a surviving
-agent record without setting the agent's `archivedAt`, while its `workspaceId` still points at the
-archived workspace. History navigation must not infer workspace lifecycle from `agent.archivedAt`
-or mutate either lifecycle. The workspace route asks the daemon for authoritative recovery state;
-only the route's explicit Unarchive or Restore action changes the archived workspace.
-
-History navigation opens the selected agent without changing either archive state. Workspace
-**Restore** recovers only the workspace; the selected archived agent stays open with its callout.
-The agent's **Unarchive** runs the provider's native unarchive hook before interactive resume and
-history hydration. Other archived agents stay archived.
-
-Opening an agent is a navigation choice, independent of whether its details are cached. The
-layout retains that choice across reload while the panel fetches the agent from the daemon.
-Once the daemon reports the agent active, its tab follows normal archive propagation again.
-An empty active list cannot cancel an explicit History selection. Agent-detail loading does
-not own selection or release the explicit open.
-
-Persisted resume, native restore, and both live and stored-only archive enter the same per-agent
-lifecycle queue. Resume chooses its history or interactive purpose from the durable record after
-entering that queue. Shutdown must finish before the manager releases runtime ownership; a failed
-close retains the runtime for cleanup and blocks replacement through that close operation.
-
-Authoritative timeline catch-up can use a runtime-only `history` resume purpose. For Codex, that
-purpose initializes a temporary app-server, reads the persisted thread and child histories, and
-releases the process before returning. It never loads, resumes, or unarchives a native thread,
-including legacy records whose native archive failed. The retained history session contains only
-the read results. Interactive resume remains responsible for repairing a provider session archived
-outside Paseo while its Paseo agent is active.
-
-Provider session connection owns every process it spawns until the session is registered with
-`AgentManager`. If initialization, persisted-session resume, or initial history hydration fails,
-`connect()` must dispose that process before rethrowing; the manager cannot clean up a session it never
-received.
-
-## Tabs vs archive
-
-These are two distinct concepts that used to be conflated:
-
-| Concept                    | Scope      | Triggers                   |
-| -------------------------- | ---------- | -------------------------- |
-| **Tab** (workspace layout) | Per-client | User opens/closes a view   |
-| **Archive** (lifecycle)    | Global     | Explicit lifecycle gesture |
-
-Closing a tab on a **root agent** still archives — the tab is the agent's home, so closing it means "I'm done with this agent." A confirm dialog protects against archiving a running agent by accident.
-
-Closing a tab on a **subagent** (any agent with `parentAgentId`) is **layout-only**. The app clears the current client's open-tab label before removing the tab. Another client's open tab remains protected. The agent stays unarchived and stays in its parent's track, so a later parent archive cascades to it when no client still has it open. The user can re-open the tab from the track at any time. Single and bulk tab close apply the same policy.
-
-The asymmetry is intentional: a subagent's persistent relationship lives in the parent's track. Same-workspace subagents are not auto-opened as tabs; the user opens one from that track when needed. A cross-workspace subagent is also auto-opened as a tab in its own workspace so opening that workspace does not appear empty. It remains in the parent's track until it is actually detached.
-
-## Workspace activity
-
-Agent lifecycle status stays literal: a parent agent is `idle` when its own turn is idle, even if a child is running.
-
-Workspace status is an aggregate activity signal computed **per `workspaceId`**. Ownership is never derived from `cwd` — many workspaces may share one directory, and same-`cwd` siblings do not clump under one status. Root agents and cross-workspace subagents contribute their normal state bucket to their own workspace. Same-workspace descendants contribute `running` to the nearest ancestor in that workspace; their non-running attention, permission, and error states stay in the parent's subagents track. This makes a cross-workspace subagent behave like a detached agent for workspace visibility and status without removing its parent relationship.
-
-Running provider-native subagents contribute `running` to the workspace owned by their parent agent. Their completed, failed, and canceled states stay in the parent's subagents track.
-
-A finished workspace can be marked unread after it has been reviewed. The daemon restores
-`finished` attention on its newest eligible workspace-root agent without sending a new completion
-notification. Opening the workspace clears that attention through the normal focus flow.
-
-Attention is set by the agent finishing or failing and cleared by the client's
-`workspace.clear_attention`, which fires when the user reads the chat. Loading an agent's runtime is
-neither, so resuming carries the stored attention and the stored last-activity time through
-untouched. Forging either makes a background resume look like the user read a workspace and like the
-agent worked in it just now, which rewrites the sidebar timestamp permanently — persisted
-`updatedAt` is what workspace `statusEnteredAt` is re-derived from on the next daemon start.
-
-## The subagents track
-
-The track is a pill at the foot of an agent's pane (`packages/app/src/subagents/track.tsx`): a count you can read at a glance, and a panel behind it — a popover on wide screens, a sheet on compact ones — holding the rows. It floats over the transcript rather than sitting in a band above the composer, so the timeline scrolls underneath it; `packages/app/src/panels/agent-tracks.tsx` owns that placement, and the pill frame is shared with the task list in `packages/app/src/composer/tracks.tsx`.
-
-The rows combine two kinds of children:
-
-- **Paseo subagents** are full managed agents. Their membership rule (`packages/app/src/subagents/select.ts`) is:
-
-```
-parentAgentId === thisAgent.id  AND  !archivedAt
-```
-
-- **Provider subagents** are child executions owned by Claude, Codex, or OpenCode. They are not inserted into `AgentManager` as managed agents. Providers emit a separate descriptor and timeline stream through `agent.provider_subagents.*`; the client keeps that state outside the normal agent store and merges only the presentation rows into the track. A descriptor's optional `parentSubagentId` identifies its direct provider-subagent parent; an absent value identifies a direct child of the managed agent.
-
-Clicking either kind opens a workspace tab. A Paseo subagent tab is a normal interactive agent pane. A provider subagent tab is a read-only timeline pane with no composer, archive, detach, rewind, or fork actions. It shows its own direct children in a subagents track. Both panes use `AgentStreamView`, so message, reasoning, tool-call, and layout rendering stay identical.
-
-Provider timelines use the same structural timeline item format but deliberately have a separate lifecycle and transport. A provider thread/session identifier is not a Paseo agent identifier, and closing its tab is always layout-only.
-
-Provider descriptors may include one compact subtitle. The provider owns its contents and formatting; clients display and truncate it without interpreting provider-specific model, thinking, or usage fields.
-
-### Claude provider subagents: the task protocol
-
-Claude Code announces subagent lifecycle on the SDK stream (`task_started` / `task_updated` / `task_notification` / `task_progress`), and Paseo reads those announcements rather than reconstructing them from sidechain frames. The live source (`subagents/live-source.ts`) and the replay source (`subagents/replay-source.ts`) both translate into one observation vocabulary (`subagents/observation.ts`), so a fact is derived once for both paths instead of once per path. Gotchas that are not obvious from the SDK types:
-
-- **Not every announced task belongs in the track.** Task subagents announce as `local_agent` and workflows as `local_workflow`; a backgrounded shell announces as `local_bash` with the same `tool_use_id` shape, and ambient housekeeping sets `skip_transcript`. The Claude provider normalizes a workflow to a generic provider-subagent descriptor titled `Workflow`, using Claude's summary as its description and timeline opener. Shared storage, protocol, and UI do not distinguish it from another provider subagent.
-- **A task that was never declared gets no descriptor, by any route.** Filtered tasks still emit `task_notification`s carrying a `tool_use_id`, and still emit frames carrying `parent_tool_use_id`. Attributing either produces a descriptor with no identity and a defaulted `running` status — a nameless row that never finishes. Status, presentation updates, and sidechain frames all route through the declaration table.
-- **Task ids are session-scoped, not turn-scoped.** Cancelling a turn must not clear the routing table: a backgrounded child settles after the interrupt and needs its descriptor to still exist. Cancellation instead terminalizes the declared children that were running in the foreground, and a later `task_notification` is free to correct that guess. Backgrounded children are identified by `is_backgrounded` on `task_started` (set at spawn; a resumed subagent is always background) or, when moved there later, on `task_updated.patch`.
-- **A resumed task can be announced again with a new `tool_use_id`.** The first Task tool id remains the canonical descriptor and later ids are routing aliases for the same session-scoped task. The resumed prompt is added to that child timeline.
-- **Effort is only reachable through hooks.** It appears nowhere on the message stream at any depth, and the level Paseo requests is not necessarily the level that runs — a model that does not support it is silently downgraded. A hook firing inside a subagent reports the active post-downgrade level next to its `agent_id`, which is the same id `task_started` calls `task_id`.
-- **Backgrounded subagents emit no frames carrying `parent_tool_use_id` at all.** Everything keyed off that field sees nothing for one; they are visible only because the task protocol announces them.
-- **Only `system/init` and `result` bracket a main-session turn.** Background subagents emit neither on the main stream, while their task frames, their own background jobs' `task_notification`, and `rate_limit_event` arrive with no `parent_tool_use_id`, the same shape as main-session work. `session_state_changed` stays `running` for as long as any background subagent lives (Claude Code 2.1.280), so it cannot open a turn; its `idle` can close one.
-- **Nested ownership comes from the launching sidechain, not `spawn_depth` alone.** A sidechain's Agent or Bash tool call records the direct owner of that `tool_use_id`; the following `task_started` inherits it. This routes a grandchild descriptor and child-owned background notifications without relying on labels or flattening them into the managed parent.
-- **On replay, `<session>/subagents/` holds every descendant beside the root.** Resolve the tree one proven generation at a time: the root transcript admits direct children, then each admitted sidechain transcript admits its children by `toolUseId`. `spawnDepth` orders candidates but does not establish ownership. Unresolved sidecars remain excluded as ambient or unrelated work.
-- **Replay `totalTokens` is a context-size reading, not cumulative spend.** Claude Code finalizes a subagent by summing the _last_ assistant message's usage block and shipping that as `usage.total_tokens`. Summing per-entry usage instead multiplies the cached prefix by the turn count and reports a number several times larger than the live path.
-
-Archived Paseo subagents disappear from the track, by design. To remove one from the track without closing its tab, use the **archive button** on the row — it opens a confirm dialog and archives the subagent on confirm. Provider-owned rows have no individual Paseo lifecycle controls.
-
-The **Archive finished** row at the foot of the panel covers every finished row. It archives idle or errored managed Paseo subagents one at a time, and hides completed, failed, or canceled provider-owned rows in the current app session. Native sessions and timelines are untouched. Running and initializing children remain in the track. If a hidden provider child starts running again, the app brings it back to the track.
-
-To keep the agent alive but remove it from the parent's track, use **detach**. The daemon clears the relationship lifecycle labels, emits the normal agent update, and every client reclassifies the agent from subagent to root/sibling from that updated snapshot.
-
-## Why this shape
-
-The decision was to **decouple "close tab" from "archive" only for subagents**, rather than universally:
-
-- **Closing a tab on a root agent still archives** — preserves the existing UX users are trained on
-- **Closing a tab on a subagent is layout-only** — fixes the lossy "click to read, close to dismiss view, lose the row" flow
-- **Archive button on track rows** — gives subagents an explicit lifecycle gesture in their home surface
-- **Detach button on track rows** — lets a subagent continue independently without killing its work
-- **Cascade archive on parent** — keeps subagents from leaking when the parent is archived
-
-We considered universal decoupling (no tab close ever archives, archive is always explicit) but rejected it: it changes a behavior root-agent users rely on.
-
-## Limitations
-
-### Subagent accumulation under long-lived parents
-
-A parent that spawns many subagents will see the panel's list grow; the pill only counts them. Managed Paseo subagents can be archived individually or with **Archive finished**. That action hides finished provider-owned rows locally; this presentation state resets when the app restarts.
-
-### Cross-client tab dismissal
-
-Closing a subagent's tab on one client doesn't affect other clients' layouts. This is the expected behavior of decoupled tabs and is consistent with how layouts have always worked. Archive remains the global gesture for cross-client cleanup.
-
-## Storage
-
-```
-$PASEO_HOME/agents/{cwd-with-dashes}/{agent-id}.json
-```
-
-`{cwd-with-dashes}` is derived from the agent's filesystem `cwd`. It is not the workspace id; agent storage stays cwd-keyed while workspace identity is the opaque workspace id.
-
-Each agent is a single JSON file. Fields relevant to this doc:
-
-| Field                                        | Type          | Meaning                                                                            |
-| -------------------------------------------- | ------------- | ---------------------------------------------------------------------------------- |
-| `id`                                         | `string`      | Stable identifier                                                                  |
-| `archivedAt`                                 | `string?`     | Soft-delete timestamp (ISO 8601)                                                   |
-| `labels["paseo.parent-agent-id"]`            | `string?`     | Parent agent ID, set automatically for agent-scoped creation and removed by detach |
-| `labels["paseo.open-agent-tab.<client-id>"]` | `string?`     | `"true"` protects an open tab on that client; detach clears every matching label   |
-| `lastStatus`                                 | `AgentStatus` | `initializing` / `idle` / `running` / `error` / `closed`                           |
-
-See [`docs/data-model.md`](./data-model.md) for the full agent record.

docs/agent-stream-performance.md

@@ -1,79 +0,0 @@
-# Agent stream performance
-
-How assistant text gets from a provider to the screen, and why it is paced on the way. Read this before changing `packages/server/src/server/agent/agent-stream-coalescer.ts`, the reducer queue in `packages/app/src/timeline/session-stream-reducers.ts`, or the reveal in `packages/app/src/hooks/use-revealed-text.ts`.
-
-For terminal output, which is a separate pipeline with separate budgets, see [terminal-performance.md](terminal-performance.md).
-
-## The pipeline
-
-```
-provider deltas (every provider streams incrementally)
-  → AgentStreamCoalescer (daemon, leading + trailing, ≤1 message per 60ms per agent)
-  → recordTimeline: one canonical row per flushed item
-  → agent_stream ws message
-  → reducer queue (app, one commit per frame) → session store
-  → source-item plugin transforms → native Markdown blocks / tool grouping
-  → paced reveal (app, per displayed item) → paint
-```
-
-Every provider delivers incremental text, so there is no provider that needs special handling: Claude via `includePartialMessages`, Codex via `agent_message_delta`, ACP agents via `agent_message_chunk`, Pi and OMP via `text_delta`.
-
-## Why the reveal is paced
-
-Arrival is lumpy and there is no fixing that at the source. A 60ms coalescing window carries however many characters the model produced in those 60ms, which swings by an order of magnitude within a single turn. Painting each delta as it lands makes the size of those lumps visible, and that is what reads as jagged.
-
-So arrival sets a _target_ and the reveal rate is derived from the backlog instead. A burst makes the text catch up faster; it does not make the text jump. Shrinking the coalescing window does not fix this — it makes the lumps smaller and more frequent, at the cost of message rate on a daemon loop that already contends with terminal frames and per-message relay encryption.
-
-## Invariants
-
-- **The coalescer is leading + trailing.** The first delta after an idle window flushes synchronously; only the rest of the burst waits for the trailing timer. Reverting to trailing-only adds a full window to the first character of every turn. Same shape and the same reason as `TerminalOutputCoalescer`.
-- **The leading flush adds a canonical row, and that is fine.** A burst's first chunk lands as its own timeline row. `mergeAssistantChunks` / `mergeReasoningChunks` in `timeline-projection.ts` join contiguous same-turn rows, and clients read the projected timeline, so history is unaffected. Tests that assert on raw rows have to account for the extra row; tests that assert on what a client sees do not.
-- **The store holds the full text; only the rendered slice is paced.** Copy, selection, the chat outline, and scroll geometry all read the same string the user can see. Pacing the store instead would leave the bottom anchor chasing a content height that is ahead of the reveal.
-- **Markdown blocks belong to presentation, and every assistant message is a block group.**
-  `agent-stream/presentation.ts` splits a message into one display row per Markdown block, the same
-  way whether it arrived streaming or as fetched history. Splitting in the reducer instead would
-  discard paragraph separators and expose fragments to plugin callbacks, which need the whole source
-  text. Live-head work stays cheap by parsing only the growing last block during append, retaining
-  completed blocks by object identity, and caching the split per source item so a tail change does
-  not re-split history. History was once left whole to keep cross-block Markdown context; that gave
-  one message two shapes depending on how it arrived, and message-addressed features only worked on
-  one of them.
-- **A row id is never a message id.** Block rows are `${messageId}:block:${n}` with
-  `blockGroupId = messageId`, including single-block messages, so nothing can come to rely on the two
-  being equal. `getStreamItemMessageId` in `presentation.ts` is the only way to go from a row to its
-  message, and web rows carry it as `data-message-id` alongside `data-history-row-id`. Anything
-  addressing a message — chat find, scroll-to-message, history reveal, the find expansion that lifts
-  the render cap — uses the message id and must expect several rows to answer to it. Row ids stay for
-  React keys, virtualizer measurement, scroll anchors, and per-row caches like assistant image
-  occurrence keys.
-- **First sight of a text is revealed whole.** Only growth is paced. This is what makes history hydration, timeline replay, a virtualized row remounting on scroll, and an already-finished message all render complete on first paint without a special case for each.
-- **Leaving `phase: "streaming"` snaps the reveal.** A completed turn must never be left holding characters. `layoutStream` sets the phase, so anything outside the live head with an active turn is already complete.
-- **The reducer queue commits on a frame, with a timer as the ceiling.** A frame callback never fires in a hidden tab, so a timer races it and wins when nothing is painting — the store has to keep advancing either way.
-- **A history row re-renders only when its item or layout item identity changes.** The inverted
-  FlatList hands every mounted cell a new `index` and `ref` whenever a row is prepended, so without a
-  memo boundary each coalesced tick re-rendered every mounted row (about 50 on a phone, 100–250 ms of
-  JS per tick). `layoutStream` keeps a layout item's identity when nothing about it changed,
-  `useRevisedHistoryRows` hands a fresh item identity to rows whose tool-call group, expanded state,
-  or breakpoint changed, and `HistoryStreamRow` memoizes on both. Every viewport runs its history
-  through that hook; the web viewport once skipped it and history hosts of a live tool group went
-  stale. A new field on `StreamLayoutItem` must be added to `areLayoutItemsEquivalent`, or sharing
-  silently stops.
-
-## Measuring
-
-- **Smoothness (user-perceived):** `packages/app/e2e/browser/agent-stream-smoothness.spec.ts`, gated behind `PASEO_AGENT_STREAM_PERF_E2E=1`. Drives the mock provider's `bursty-stream` model and reports coefficient of variation of characters painted per frame (smoothness) plus p95 gap between visible updates (stalls). Both numbers are needed: a stalled stream is perfectly smooth.
-- **Reproducing bursty arrival:** the `bursty-stream` model in `mock-load-test-agent.ts` emits uneven runs of tokens separated by idle gaps. Burst sizes come from a seeded generator, so a run repeats exactly.
-- **Rate policy in isolation:** `computeRevealStep` in `packages/app/src/agent-stream/text-reveal.ts` is pure; `text-reveal.test.ts` covers convergence and burst flattening without a renderer.
-
-Healthy numbers (2026-08, Expo web against a local dev daemon, real Claude Haiku agent, ~8.5s samples during active streaming). Setting `TEXT_REVEAL_HORIZON_MS` to 0 makes the reveal paint on arrival, which is how the baseline column was taken:
-
-|                                  | paint on arrival | paced |
-| -------------------------------- | ---------------- | ----- |
-| frames that advanced the text    | 6%               | 87%   |
-| chars-per-frame CV               | 4.11             | 1.86  |
-| gap between visible updates, p50 | 317ms            | 17ms  |
-| gap between visible updates, p95 | 383ms            | 17ms  |
-
-Total characters painted is roughly the same either way — the reveal changes when they land, not how many arrive.
-
-Measure the **total** length across every `assistant-message` element, not the last one. A turn emits many assistant messages, so the tail element keeps changing identity and its length is not monotonic; sampling only the tail reads those handovers as resets and reports almost no growth. `sampleStreamFrames` does this correctly.

docs/android.md

@@ -1,230 +0,0 @@
-# Android
-
-## App variants
-
-Controlled by `APP_VARIANT` in `packages/app/app.config.js` (vanilla Expo, no custom Gradle plugin):
-
-| Variant       | App name    | Package ID       |
-| ------------- | ----------- | ---------------- |
-| `production`  | Paseo       | `sh.paseo`       |
-| `development` | Paseo Debug | `sh.paseo.debug` |
-
-EAS profiles: `development`, `production`, and `production-apk` in `packages/app/eas.json`.
-
-`development` uses Android `debug`.
-
-## Version codes
-
-`packages/app/native-release-version.js` is the single definition of native and F-Droid version-code math. Do not re-derive these numbers anywhere else — a drifted copy produces changelog files that match no published APK, and nothing fails loudly.
-
-The base version code comes from the package version:
-
-```text
-major * 1_000_000 + minor * 1_000 + patch
-```
-
-Prerelease metadata is ignored, so `0.1.102-beta.1` and `0.1.102` both produce `1102`. The same value is used as the iOS `buildNumber` because `packages/app/eas.json` uses EAS's local app version source. Do not re-enable EAS remote version counters or Android `autoIncrement`; F-Droid and other source-based builders need the native build number to be visible in the repo.
-
-The formula reserves three digits each for minor and patch. If either reaches `1000`, change the formula before cutting that release.
-
-## Prerequisites (local dev)
-
-Local Android builds run on macOS (or Linux) and need the Android toolchain, pinned in `.tool-versions` (`java 21`, `android-sdk 21.0`) and wired up by `.mise.toml` (which derives `ANDROID_HOME` and the command-line tool paths from the `android-sdk` entry). With [mise](https://mise.jdx.dev):
-
-```bash
-mise install        # java 21 + android-sdk 21.0 command-line tools
-```
-
-> **Pin a real `android-sdk` version, not `latest`.** The mise `android-sdk` plugin's `latest` resolved to the ancient `1.0` bundle, whose `sdkmanager` (3.6.0) predates the `emulator` package and fails with `Failed to find package emulator`. `21.0` ships a current `sdkmanager`. If you bump it, update only the version in `.tool-versions`; `.mise.toml` derives its paths from that tool entry.
-
-`mise install` only lays down the command-line tools. Install the rest and create an emulator. On Apple Silicon:
-
-```bash
-sdkmanager --licenses
-sdkmanager "platform-tools" "emulator" "platforms;android-35" "build-tools;35.0.0" \
-           "system-images;android-35;google_apis;arm64-v8a"
-avdmanager create avd -n paseo -k "system-images;android-35;google_apis;arm64-v8a" -d pixel_7
-emulator @paseo     # start it; leave running
-```
-
-On an Intel Mac, use the `x86_64` system image:
-
-```bash
-sdkmanager --licenses
-sdkmanager "platform-tools" "emulator" "platforms;android-35" "build-tools;35.0.0" \
-           "system-images;android-35;google_apis;x86_64"
-avdmanager create avd -n paseo -k "system-images;android-35;google_apis;x86_64" -d pixel_7
-emulator @paseo     # start it; leave running
-```
-
-Gradle auto-fetches the platform/build-tools it needs once licenses are accepted, so adjust `android-35` only if it asks for a different level.
-
-## Local build + install
-
-From repo root:
-
-```bash
-npm run android:development    # Debug build
-npm run android:production     # Release build
-npm run android:clear          # Remove generated Android project
-```
-
-For a production-ID release APK that local Android profiling tools can attach to:
-
-```bash
-PASEO_PROFILE_BUILD=1 npm run android:production
-```
-
-This keeps the `sh.paseo` package id, release Hermes bundle, and release optimizations. It adds
-`<profileable android:shell="true" />` and enables local Android trace markers for workspace mounts
-and daemon WebSocket traffic. The markers contain message types and sizes, never payload contents,
-and emit only while a system trace records the `sh.paseo` app (`perfetto -a sh.paseo ...`).
-
-Or from `packages/app`:
-
-```bash
-# Debug
-npx cross-env APP_VARIANT=development expo prebuild --platform android --clean --non-interactive
-npx cross-env APP_VARIANT=development expo run:android --variant=debug
-
-# Release
-npx cross-env APP_VARIANT=production expo prebuild --platform android --clean --non-interactive
-npx cross-env APP_VARIANT=production expo run:android --variant=release
-
-# Clear generated Android project
-rm -rf android
-```
-
-## Running on an emulator against a worktree daemon
-
-`npm run android` builds and installs the dev client, but two connections have to reach your Mac from inside the emulator — Metro (the JS bundle) and the Paseo daemon — and **the emulator does not share the host's loopback**: `localhost` inside the emulator is the emulator itself. Reach the host at `10.0.2.2` (the standard AVD's host alias) for both:
-
-```bash
-REACT_NATIVE_PACKAGER_HOSTNAME=10.0.2.2 \
-  EXPO_PUBLIC_LOCAL_DAEMON=10.0.2.2:$PASEO_SERVICE_DAEMON_PORT \
-  npm run android
-```
-
-- **`REACT_NATIVE_PACKAGER_HOSTNAME=10.0.2.2`** — without it, Expo bakes your Mac's LAN IP into the dev client's Metro URL, which the emulator can't route to, and the app dies with `Failed to connect to /<lan-ip>:8081` before any JS loads.
-- **`EXPO_PUBLIC_LOCAL_DAEMON=10.0.2.2:<port>`** — the client's daemon endpoint (`packages/app/src/runtime/host-runtime.ts`); when unset it defaults to `localhost:6767`, the production daemon. Use `$PASEO_SERVICE_DAEMON_PORT` for a worktree daemon running as a Paseo service, or `6768` for a standalone `npm run dev:server`. It is inlined into the JS bundle at Metro bundle time, so set it on the build command and clear the Metro cache (`npx expo start -c`) if a change doesn't take.
-
-**Alternative — `adb reverse` + `localhost`** (if `10.0.2.2` misbehaves):
-
-```bash
-adb reverse tcp:8081 tcp:8081
-adb reverse tcp:$PASEO_SERVICE_DAEMON_PORT tcp:$PASEO_SERVICE_DAEMON_PORT
-REACT_NATIVE_PACKAGER_HOSTNAME=localhost \
-  EXPO_PUBLIC_LOCAL_DAEMON=localhost:$PASEO_SERVICE_DAEMON_PORT \
-  npm run android
-```
-
-This is the Android counterpart of the iOS local-simulator flow in [development.md](development.md): on iOS the simulator shares the Mac's loopback so `localhost:<port>` works directly; on Android you need `10.0.2.2` or `adb reverse`.
-
-## Inverted timeline selection
-
-Android focus and selection visibility requests must not reposition inverted timelines. The
-`modules/paseo-scroll` package keeps React Native's scroll manager interface and returns zero for
-child-reveal scroll calculations when the vertical scale is inverted. Dragging and explicit scroll
-commands still work; non-inverted scroll views keep Android's default behavior.
-
-Register this package before React Native's core package through its Expo config plugin. Normal
-Android builds use the prebuilt `react-android` library, so patching Java under `node_modules` does
-not change the shipped scroll view. Keep this behavior in the app's compiled native module.
-
-## F-Droid / source-only Android builds
-
-F-Droid builds should set `PASEO_FDROID_BUILD=1` when running Expo prebuild:
-
-```bash
-cd packages/app
-PASEO_FDROID_BUILD=1 APP_VARIANT=production npx expo prebuild --platform android --clean --non-interactive
-cd android
-PASEO_FDROID_BUILD=1 ./gradlew assembleRelease --no-daemon --max-workers=1 -Dorg.gradle.parallel=false
-```
-
-The flag must be present for both prebuild and Gradle because Gradle starts Metro for the release bundle. Keep the source build serial and daemon-free as shown above: compiling every Expo module can exhaust memory when Gradle workers run in parallel. The profile enables source-built Expo modules, excludes the proprietary camera, Firebase notification, and Expo development-client native modules, disables Gradle dependency metadata, and substitutes JavaScript stubs for camera and notifications. The resulting app supports direct and pasted-link pairing but not QR scanning or push notifications.
-
-For a single-ABI APK, pass React Native's architecture property to Gradle:
-
-```bash
-PASEO_FDROID_BUILD=1 ./gradlew assembleRelease \
-  -PreactNativeArchitectures=arm64-v8a \
-  --no-daemon --max-workers=1 -Dorg.gradle.parallel=false
-```
-
-Supported values are `armeabi-v7a`, `arm64-v8a`, `x86`, and `x86_64`. The F-Droid profile filters native libraries to that ABI and changes the APK version code to `baseVersionCode * 10 + abiSuffix`, where the suffixes are ordered `1` through `4` in that same sequence. F-Droid metadata should use four build blocks with `VercodeOperation` entries `10 * %c + 1` through `10 * %c + 4` and pass the matching `reactNativeArchitectures` value in each build command. Builds without a single architecture keep the base version code.
-
-Keep the excluded npm packages installed. Normal builds use them, while the F-Droid profile removes only their Android native modules and config plugins. Paseo always applies `expo-gradle-jvmargs` with `-Xmx4096m` and `-XX:MaxMetaspaceSize=1024m` so local Expo prebuilds have enough Gradle heap whether they use precompiled AARs or source-built Expo modules.
-
-The EAS `production-apk` profile uses the large Android resource class. Release builds compile the native ABIs and run Hermes bundling in the same Gradle invocation; the default worker can exhaust its remaining memory and kill Hermes with exit code 137 even when Gradle's own heap is correctly sized.
-
-### F-Droid store metadata
-
-F-Droid reads the store listing from `fastlane/metadata/android/<locale>/` **at the repo root**. This location provides the best compatibility with the F-Droid release process.
-
-```text
-fastlane/metadata/android/
-├── en-US/                      (F-Droid fallback locale, mandatory)
-│   ├── title.txt               (<=50 chars)
-│   ├── short_description.txt   (<=80 chars)
-│   ├── full_description.txt    (<=4000 chars, limited HTML)
-│   ├── images/
-│   │   ├── icon.png            (512x512)
-│   │   ├── featureGraphic.png  (1024x500)
-│   │   └── phoneScreenshots/   (1.png, 2.png, ...)
-│   └── changelogs/             (generated — see below)
-├── ja/
-└── zh-CN/
-```
-
-Locale directories generally match `packages/app/src/i18n/locales.ts`, but note that `en` becomes `en-US`.
-
-F-Droid changelogs are generated from `CHANGELOG.md`. Run `npm run fdroid:changelogs`; `npm run fdroid:changelogs:check` verifies without writing. It is wired into the npm `version` lifecycle, so a release picks it up automatically and `git add -A` stages the result.
-
-One changelog must be generated per-ABI-split, so each version will create **four** identical version-coded entries. F-Droid caps changelogs at 500 characters, so the generator strips some content and adds a link to the full notes.
-
-Stable sync fails loudly if `CHANGELOG.md` has no entry for the version being cut. That is intentional — the release checklist requires the entry to be committed first, so an abort here means the checklist was skipped.
-
-Because the generator runs off the version in `package.json`, it must run **before** the tag is created: fdroidserver only reads metadata from the tag it builds, so the file for version N has to exist in the commit N points at.
-
-Beta releases are an explicit no-op: they do not create or rewrite F-Droid changelog files. Stable releases and promotions generate the four ABI entries from their final changelog.
-
-### React version lockstep
-
-Keep `react` and `react-dom` pinned to the React version embedded by the current `react-native` release. React Native `0.81.x` embeds `react-native-renderer` `19.1.0`, so `packages/app` must use React `19.1.0`. Bumping React to a newer patch can build successfully but crash at JS startup on Android with `Incompatible React versions`, leaving the app on the native splash screen.
-
-## Screenshots
-
-```bash
-adb exec-out screencap -p > screenshot.png
-```
-
-## Cloud build + submit (EAS)
-
-Stable tag pushes like `v0.1.0` trigger:
-
-- The EAS GitHub app on Expo servers (iOS + Android production builds + store submit). There is no workflow file in this repo for it.
-- `.github/workflows/android-apk-release.yml` on GitHub Actions (APK asset on GitHub Release).
-
-iOS auto-submits to App Store review via a Fastlane lane after EAS uploads to TestFlight. Android auto-submits to the Play Store via EAS-managed credentials.
-
-Beta tags like `v0.1.1-beta.1` only trigger the GitHub APK workflow. They publish a GitHub prerelease APK for testing and do not submit to the stores.
-
-`android-v*` tags also trigger only the GitHub APK workflow — useful when you want to ship an APK without going through stores. The GitHub APK workflow supports `workflow_dispatch` with an existing `tag` input so you can rebuild without cutting a new tag.
-
-### Useful commands
-
-```bash
-cd packages/app
-
-# Recent builds
-npx eas build:list --limit 10 --non-interactive --json | jq '.[] | {platform, status, appVersion, gitCommitHash}'
-
-# Inspect a build (the printed `Logs` URL opens the build's Expo dashboard page,
-# which has a Submissions section showing the auto-submit to the Play Store).
-npx eas build:view <build-id>
-```
-
-The Play Console (Internal testing → Production tracks) is the final confirmation that the binary reached the store.
-
-See [docs/release.md](release.md) for the full mobile-build babysitting flow.

docs/architecture.md

@@ -1,487 +0,0 @@
-# Architecture
-
-Paseo is a client-server system for monitoring and controlling local AI coding agents. The daemon runs on your machine, manages agent processes, and streams their output in real time over WebSocket. Clients (mobile app, CLI, desktop app) connect to the daemon to observe and interact with agents.
-
-Your code never leaves your machine. Paseo is local-first.
-
-## System overview
-
-```
-┌─────────────┐    ┌─────────────┐    ┌─────────────┐
-│  Mobile App  │    │     CLI     │    │ Desktop App │
-│   (Expo)     │    │ (Commander) │    │ (Electron)  │
-└──────┬───────┘    └──────┬──────┘    └──────┬──────┘
-       │                   │                  │
-       │    WebSocket      │    WebSocket     │    Managed subprocess
-       │    (direct or     │    (direct)      │    + WebSocket
-       │     via relay)    │                  │
-       └───────────┬───────┴──────────────────┘
-                   │
-            ┌──────▼──────┐
-            │   Daemon    │
-            │  (Node.js)  │
-            └──────┬──────┘
-                   │
-      ┌────────────┼────────────┬────────────┬────────────┐
-      │            │            │            │            │
-┌─────▼─────┐ ┌───▼────┐ ┌──────▼─────┐ ┌────▼─────┐ ┌────▼────┐
-│  Claude   │ │ Codex  │ │  Copilot   │ │ OpenCode │ │   Pi    │
-│  Agent    │ │ Agent  │ │   Agent    │ │  Agent   │ │ Agent   │
-│  SDK      │ │ Server │ │    ACP     │ │          │ │         │
-└───────────┘ └────────┘ └────────────┘ └──────────┘ └─────────┘
-```
-
-## Components at a glance
-
-- **Daemon:** Local server that spawns and manages agent processes and exposes the WebSocket API.
-- **App:** Cross-platform Expo client for iOS, Android, web, and the shared UI used by desktop.
-- **CLI:** Terminal interface for agent workflows that can also start and manage the daemon.
-- **Desktop app:** Electron wrapper around the web app that bundles and auto-manages its own daemon.
-- **Relay:** Optional encrypted bridge for remote access without opening ports directly.
-
-## Packages
-
-### `packages/server` — The daemon
-
-The heart of Paseo. A Node.js process that:
-
-- Listens for WebSocket connections from clients
-- Manages agent lifecycle (create, run, stop, resume, archive)
-- Streams agent output in real time via a timeline model
-- Provides agent-to-agent tools through a transport-neutral tool catalog, with MCP as one adapter
-- Optionally connects outbound to a relay for remote access
-- Optionally serves the browser web client from the same HTTP server (self-hosting guide: [public-docs/web-ui.md](../public-docs/web-ui.md))
-
-All paths are under `packages/server/src/`.
-
-Desktop and CLI import server capabilities through explicit package subpaths such as
-`@getpaseo/server/daemon-control`, `/configuration`, and `/process`. The root export
-loads daemon bootstrap eagerly, even when a caller only uses a path or process helper.
-Keep process-management and configuration dependencies independent of bootstrap and
-WebSocket message schemas. Shared configuration schemas belong in protocol leaf modules;
-`messages` imports and re-exports them. This prevents every supervising process from
-retaining the daemon's runtime and wire-schema allocations. The server export tests guard
-these dependency trees with tree-shaking disabled to match unbundled production imports.
-
-Project identity is daemon-global rather than session-owned. After registry bootstrap, the daemon's
-project Git observer keeps one non-recursive watch on each lexically equivalent active project root
-and listens only for the root `.git` entry, with a slow rescan as a missed-event fallback. It runs
-for empty projects and without connected clients, then fans metadata changes through the WebSocket
-server to capability-aware sessions. It deliberately does not use the broad recursive working-tree
-watcher or the per-session Git observer: those are checkout/status mechanisms and intentionally do
-not retain non-Git directories.
-
-**Key modules:**
-
-| Module                          | Responsibility                                                                 |
-| ------------------------------- | ------------------------------------------------------------------------------ |
-| `server/bootstrap.ts`           | Daemon initialization: HTTP server, WS server, agent manager, storage, relay   |
-| `server/websocket-server.ts`    | WebSocket connection management, hello handshake, binary frame routing         |
-| `server/session.ts`             | Per-client session state, timeline subscriptions, terminal operations          |
-| `server/directory-sync/`        | Daemon-global latest-state sequences for projects, workspaces, and agents      |
-| `server/workspace-labels/`      | Host-local label catalog, assignment mutations, and explicit subscriptions     |
-| `server/agent/agent-manager.ts` | Agent lifecycle state machine, timeline tracking, subscriber management        |
-| `server/agent/agent-storage.ts` | File-backed JSON persistence at `$PASEO_HOME/agents/`                          |
-| `server/agent/tools/`           | Transport-neutral catalog for workspaces, agents, permissions, and automation  |
-| `server/agent/mcp-server.ts`    | Thin MCP adapter that registers the Paseo tool catalog with the MCP SDK        |
-| `server/agent/providers/`       | Provider adapters (see "Agent providers" below)                                |
-| `server/orchestration-skills/`  | Bundled catalog, host selection, convergence, and skill-directory transactions |
-| `server/relay-transport.ts`     | Outbound relay connection with E2E encryption                                  |
-| `server/schedule/`              | Cron-based scheduled agents                                                    |
-
-### `packages/protocol` — Wire schemas and shared protocol types
-
-The source of truth for WebSocket messages, binary frame codecs, endpoint parsing,
-agent timeline types, provider config schemas, and other values shared by daemon
-and clients. Server, app, CLI, and `@getpaseo/client` all depend on this package;
-it does not depend on the server.
-
-### `packages/client` — Daemon client library and SDK facade
-
-Owns the low-level daemon WebSocket driver plus the higher-level `PaseoClient`
-facade. App and CLI may import the low-level driver from
-`@getpaseo/client/internal/daemon-client` during migration, while new SDK-shaped
-code imports from `@getpaseo/client`.
-
-`PaseoApi` is the capability-only boundary over workspaces, agents, terminals, providers, and config.
-`PaseoClient` adds connection lifecycle. App plugin surfaces borrow an API over their selected
-host's client; plugin subprocesses use the same facade over a host-owned IPC transport. Protocol capability ownership and subscription lifetimes follow
-[the client contract](protocol-compatibility.md#client-capability-ownership).
-
-### `packages/app` — Mobile + web client (Expo)
-
-Cross-platform React Native app that connects to one or more daemons.
-
-- Expo Router navigation (`/h/[serverId]/workspace/[workspaceId]`, `/h/[serverId]/agent/[agentId]`, etc.). The `workspaceId` URL segment is an opaque workspace id, not a directly meaningful filesystem path.
-- `HostRuntimeController` manages saved host connections, reconnection, and per-host runtime state. Direct TCP and relay connections use the ordinary client transport; desktop socket, pipe, and SSH connections cross one Electron-owned transport boundary. SSH only tunnels to an already-running daemon.
-- `runtime/replica-cache` is typed storage behind the directory and timeline owners. It never observes or mutates `SessionStore`.
-- `runtime/directory-sync` owns directory cache selection and network reconciliation. On demand it paints accepted rows for one host, then passes the persisted per-entity cursor through `project.list`, `fetch_workspaces`, and `fetch_agents`; the daemon returns each entity's latest projection when its sequence is newer, plus tombstones.
-- `workspace-labels` owns one sequenced catalog replica per connected host, the deterministic cross-host projection that surfaces spanning hosts use (the filter page, the manager), and the per-host resolution a workspace row's chips use. Two hosts may give one name different colors, so a row resolves against its own host's catalog and a merged answer would be wrong there. Catalogs never synchronize between hosts; assignment creates a missing definition only on the target host. On the daemon, catalog and assignment rewrites share a journaled commit boundary. Startup recovery completes that commit before workspace or catalog publication.
-- `SessionContext` wraps the daemon client for the active session
-- Composer UI and submit/draft behavior live in `packages/app/src/composer/`; screens and panels should integrate it from there instead of dropping composer internals into `components/`, `hooks/`, or `screens/workspace/`
-- Timeline reducers in `timeline/session-stream-reducers.ts` handle compaction, gap detection, sequence-based deduplication
-- Timeline sync correctness is documented in [docs/timeline-sync.md](timeline-sync.md): live streams are for immediacy, `fetch_agent_timeline_request` is authoritative, and catch-up is paged but complete.
-- Voice features: dictation (STT) and voice agent (realtime)
-
-Consumers request directory or timeline data without choosing memory, cache, or network. The owner
-publishes an accepted cache hit and then reconciles it over the existing network path. A miss or an
-invalid row uses that same path. Offline demand still publishes an accepted cache hit and defers
-network reconciliation. Cache loading is demand-driven: opening a chat reads its agent row and
-focused timeline row, plus the workspace and project rows needed by the route; opening a directory
-reads directory rows for that host and establishes its live subscription when connected. Accepted
-cached rows satisfy the same consumer-readiness projection as network rows. Host registry startup and
-host connection do not create directory demand or install replicas. The directory owner retains
-declared surface demand and re-establishes network reconciliation after reconnect; React does not
-track connection generations. Late cache reads cannot replace state already advanced by live or
-authoritative network data. Owners explicitly persist accepted commits; directory rows and their
-checkpoint share one storage transaction. See
-[data-model.md](data-model.md#replica-row-store)
-for the storage shape and [timeline-sync.md](timeline-sync.md#client-replica-lifetime) for timeline
-resume behavior.
-
-The three directory entity types have independent monotonic sequences and share one daemon
-generation. The daemon retains only the latest projection per entity and bounded tombstones, not an
-event log. A missing, expired, or previous-generation cursor receives a full snapshot. Projects are
-independent records; a project with no workspaces does not need a workspace placeholder.
-
-Workspace label definitions use a separate, explicitly subscribed sequence. The list request both
-fetches and grants live updates for that session. A current cursor receives an empty correlated
-catch-up response when nothing changed; idle sessions and unsubscribed sessions receive no label
-traffic. Workspace assignments stay on the workspace directory sequence.
-
-### `packages/cli` — Command-line client
-
-Commander.js CLI with Docker-style commands. Common agent operations are also exposed at the top level (e.g. `paseo ls`, `paseo run`).
-
-- `paseo agent ls/run/import/attach/logs/stop/delete/send/inspect/wait/archive/reload/update/mode`
-- `paseo daemon start/run/stop/restart/status/reload/config/pair/set-password`
-- `paseo terminal ls/create/capture/send-keys/kill`
-- `paseo script ls/start/stop`
-- `paseo schedule create/ls/inspect/update/pause/resume/run-once/logs/delete`
-- `paseo heartbeat create/update/delete`
-- `paseo project create/ls/rename/delete`
-- `paseo workspace create/ls/rename/archive`
-- `paseo permit allow/deny/ls`
-- `paseo provider ls/models`
-- hidden legacy `paseo worktree create/ls/archive` compatibility alias
-- `paseo speech …`
-
-Communicates with the daemon via the same WebSocket protocol as the app.
-
-### `packages/relay` — Relay transport and E2E encryption
-
-Enables remote access when the daemon is behind a firewall.
-
-- Curve25519 establishes the relay-session secret; NaCl `box` protects each payload with XSalsa20-Poly1305
-- The relay is zero-knowledge — it routes encrypted bytes and cannot read content
-- Client and daemon channels with identical API (`createClientChannel`, `createDaemonChannel`)
-- Pairing via QR code transfers the daemon's public key to the client
-- New homes keep relay disabled until pairing consent. `DaemonConfigStore` persists the desired state, while the relay runtime starts or stops the outbound transport live; pairing reads that current state instead of a startup snapshot.
-- Optional E2EE capability negotiation preserves application frame kind: text plaintext uses base64 ciphertext text frames, while binary plaintext uses raw ciphertext binary frames; mixed-version peers remain base64-only
-- Self-hosted relays opt into TLS with `daemon.relay.useTls` or `PASEO_RELAY_USE_TLS=true`; the public (client-facing) TLS setting can be overridden independently via `daemon.relay.publicUseTls` or `PASEO_RELAY_PUBLIC_USE_TLS`
-
-The production relay server lives in [getpaseo/paseo-relay](https://github.com/getpaseo/paseo-relay). It is a distributed Elixir service. The Cloudflare relay implementation in this monorepo is retained as legacy code and is not deployed.
-
-See [SECURITY.md](../SECURITY.md) for the full threat model.
-
-### Paseo Hub
-
-The optional Hub relationship is daemon-outbound and does not use the relay. Its connection,
-authorization, ownership, persistence, and lifecycle contract is documented in [hub.md](hub.md).
-
-### `packages/desktop` — Desktop app (Electron)
-
-Electron wrapper for macOS, Linux, and Windows.
-
-- Can spawn the daemon as a managed subprocess
-- Native file access for workspace integration
-- Same WebSocket client as mobile app
-
-The desktop does not manage agent skills. It retains one compatibility reader for the old
-`skill-selection.json`, imports that preference into its managed local daemon, then deletes the old
-file after the daemon confirms persistence.
-
-**Multi-window (hybrid land-on model).** `createWindow()` in `main.ts` is reusable: `⌘⇧N`/File→New Window, relaunching the app (`second-instance`), and the sidebar "Open in new window" action each open a fresh `BrowserWindow`. Every window shows the full sidebar — there is no per-window project ownership or filtering. "Land on a project" is delivered by a per-`webContents` `PendingOpenProjectStore`: each window pulls its own pending project path on mount (`paseo:get-pending-open-project`) and runs the normal open-project flow, identical to a CLI `paseo <path>` launch.
-
-> **Window-state v1 limitation:** only the _first_ window of a session restores and persists saved geometry (size/position/maximized). Windows opened via ⌘⇧N / second-instance / "Open in new window" open at the default size, OS-cascaded, and do not persist — this avoids every window stacking on the same restored bounds and fighting over the single window-state store. Lifting this needs per-window state keys.
->
-> **In-app browser profile.** Every browser guest uses one stable persistent Electron session, so cookies, authentication, cache, and site storage are shared across tabs, workspaces, and desktop windows and survive tab or app closure. Browser identity is independent of that storage partition: after every `did-attach`, the renderer explicitly registers its browser id, workspace id, and current guest `WebContents` id, and main accepts the registration only when that guest belongs to the calling renderer and the shared profile. Registration is intentionally repeated because reparenting a retained `<webview>` can replace its guest without replacing the DOM element. Settings > General > Clear browser data is the sole profile-deletion path; it clears the shared session and reloads live guests without deleting saved tabs or URLs.
->
-> **In-app browser window opens.** Ordinary link opens, including Shift-clicked links, become Paseo workspace tabs. Script-created opens with popup features or a named window target and POST-backed opens remain secured Electron child windows in the shared browser profile, preserving `window.opener`, `postMessage`, named-window reuse, request bodies, and `window.close()` for OAuth, payment, and similar popup protocols. Unsupported URL schemes are denied before either path.
->
-> **In-app browser ownership.** Each registered guest records its owning host window. The active browser is keyed by `(host window, workspace)`, and application-menu Reload / Force Reload resolve only within the window Electron supplies to the menu callback. A non-null active update must name a browser owned by that host; a null update clears only that host/workspace. Browser automation continues to target explicit browser ids returned by `browser_new_tab` or `browser_list_tabs`.
->
-> **Browser keyboard boundary.** Guest pages receive renderer-published shortcuts first. `Cmd/Ctrl+L` and `Cmd/Ctrl+R` are explicit guest-shell reservations; ordinary Paseo shortcuts run only after the page declines them. The sandboxed guest preload runs in every frame so focused iframes use the same boundary, while Node integration remains disabled. Human guest input disables Electron's menu fallback for plain keys. Agent-generated keys use guest `sendInputEvent` with `skipIfUnhandled`, so an unhandled Enter stops at the guest instead of reaching the host composer. Main selects the preload; it exposes no APIs to guest pages.
-
-```text
-Human key -> guest WebContents
-  |-- Cmd/Ctrl+T/L/R ----------> reserved browser-shell action
-  `-- page keydown
-        |-- page prevents ------> page owns it
-        `-- published shortcut -> guest preload -> IPC(browserId) -> Paseo resolver
-
-Agent browser_keypress -> guest sendInputEvent(skipIfUnhandled)
-  |-- guest handles ------------> page owns it
-  `-- guest does not handle ----> stop; never redispatch to the host window
-```
-
-### `packages/website` — Marketing site
-
-TanStack Router + Cloudflare Workers. Serves paseo.sh.
-
-## WebSocket protocol
-
-All clients speak the same WebSocket protocol over a single connection that mixes JSON text frames and a small binary framing for terminal streams. Schemas live in `packages/protocol/src/messages.ts`.
-
-**Handshake:**
-
-```
-Client → Server:  WSHelloMessage {
-                    type: "hello",
-                    clientId,
-                    clientType: "mobile" | "browser" | "cli" | "mcp",
-                    protocolVersion,
-                    appVersion?,
-                    capabilities?: { voice?, pushNotifications?, ... },
-                  }
-Server → Client:  status message with payload { status: "server_info",
-                    serverId, hostname, version, capabilities?, features }
-```
-
-There is no dedicated welcome message; the server emits one initial `status.server_info` after
-accepting hello. Modern clients negotiate `owned_subscriptions` against
-`features.ownedSubscriptions`. Connecting or attaching a local listener creates no application-data
-demand. A list is a snapshot; adding `subscribe: {}` creates an independent server ID. The client
-correlates the initial reply by request ID, then routes updates by subscription ID.
-
-A logical Session can contain several physical sockets. Each socket owns its capabilities,
-subscriptions and ongoing operations; the final JSON/binary send boundary requires that source's
-request or subscription provenance. Domain modules own filtering, bootstrap and resource teardown.
-The shared ownership boundary only tracks source and lifetime. Releasing a subscription acknowledges
-its teardown; reconnect creates new server IDs for surviving client handles. See
-[protocol compatibility](protocol-compatibility.md) for the legacy boundary.
-
-**Top-level WS envelopes** are `hello`, `recording_state`, `ping`/`pong`, and `session` (which wraps the rich union of session messages).
-
-Client liveness checks use the top-level JSON `ping`/`pong` envelope, not a session RPC or RFC6455 control ping. Current clients ping every 10 seconds, beginning one interval after connecting. The first ping claims an application-ownership lease for that physical socket, all later inbound activity renews it, and the daemon forcibly terminates the socket if the lease expires. A legacy or raw socket that never sends an application ping never enters this lease and is not closed for omitting one. Session RPC timeouts are operation failures, not proof that the socket is dead. A subscription bootstrap timeout closes its source to clear any unknown server-owned registration; the failed handle is released before other surviving handles reconnect.
-
-Every physical send path enforces an 8 MiB outbound high-water mark, including JSON broadcasts, binary terminal frames, and the encrypted relay adapter's asynchronous queue. This sits above the terminal stream's 4 MiB soft backpressure threshold, leaving room for snapshot catch-up before the hard cutoff. JSON is serialized once per broadcast after sockets already at the limit are removed, then its exact byte length is checked for every remaining socket. A frame that would cross the limit is not sent; that physical socket is forcibly terminated without disturbing other sockets attached to the same logical session. Multiple tabs and simultaneous direct and relay paths may legitimately share a client id.
-
-Client session RPC waits default to 60s so slow relay or mobile networks do not turn a live but delayed daemon response into a false operation failure. Keep connect timeouts, app-level grace windows, explicit diagnostic latency probes, liveness ping timers, and genuinely long-running RPCs separate from this default.
-
-New session RPCs use dotted names with `.request` and `.response` suffixes, such as `checkout.forge.set_auto_merge.request` and `checkout.forge.set_auto_merge.response`. See [rpc-namespacing.md](rpc-namespacing.md) for the convention and migration rules for older flat RPC names.
-
-**Notable session message types:**
-
-- `agent_update` — Agent state changed (status, title, labels)
-- `agent_stream` — New timeline event from a running agent
-- `workspace_update`, `script_status_update`, `workspace_setup_progress` — Workspace state
-- `agent_permission_request` / `agent_permission_resolved` — Tool-call permission flow
-- `agent_deleted`, `agent_archived`, `agent_status`, `agent_list`
-- `checkout_status_update`, `checkout_diff_update`, and the full `checkout_*` request/response set for git operations
-
-Agent snapshots optionally carry the daemon-owned active turn identity, and turn lifecycle stream events
-optionally carry the same `turnId`. New clients use these fields when present and normalize an old daemon's
-status once at the directory boundary rather than maintaining a second activity model.
-
-- Terminal subscribe/input/capture commands
-- Voice/dictation streaming events (`dictation_stream_*`, `assistant_chunk`, `audio_output`, `transcription_result`)
-- Request/response pairs for fetch, list, create, etc., correlated by `requestId`; failures use `rpc_error`
-
-`directory_suggestions_request` is one daemon-owned filesystem search capability. The daemon
-configures the same `searchDirectoryEntries` engine with a root, output format, path-query policy,
-entry-kind filters, match mode, blank-query behavior, and hidden-directory traversal policy. A
-request without `cwd` searches the host home for absolute project paths; a request with `cwd`
-searches that workspace and returns relative entries. Clients may prepend their small host-scoped
-recent-project list for bare queries, but must not parse filesystem query syntax or re-filter a
-correlated daemon response. The legacy `directories` response field remains a projection of the
-typed `entries` list.
-
-**Binary frames (terminal stream protocol):**
-
-Terminal I/O is sent as binary WebSocket frames decoded by `decodeTerminalStreamFrame` in `shared/binary-frames/terminal.ts`. The layout is:
-
-- 1-byte opcode: `Output (0x01)`, `Input (0x02)`, `Resize (0x03)`, `Snapshot (0x04)`
-- 1-byte slot: terminal slot id
-- variable payload: bytes for output/input, JSON-encoded `{ rows, cols }` for resize, terminal snapshot for snapshot
-
-Terminal PTY size is last-interacting-client-wins. A client claims the PTY size only when its terminal viewport genuinely changes size or the user focuses/taps the terminal. Passive rendering work — attaching, restoring visibility, font settling, renderer refits, or just looking at a visible terminal — must not send a resize frame. The server does not broadcast resize ownership; the resized PTY redraws through normal output, and every attached client renders that output in its own local viewport.
-
-There is also a separate file-transfer binary frame format in the same directory, used for download/upload streams.
-File downloads keep the existing `FileBegin`/`FileChunk`/`FileEnd` framing and stream 256 KiB chunks
-from one stable file handle. Each transfer awaits completion of its own physical WebSocket send before
-reading the next chunk; it is scoped to the requesting physical socket and does not queue unrelated
-messages or transfers.
-
-### Compatibility rules
-
-- WebSocket schemas are append-only. Add fields, do not remove fields, and never make optional fields required.
-- New wire enum values must be gated at serialization with `session.supports(CLIENT_CAPS.someCapability)`.
-- Capabilities belong to the physical source socket. `session.supports(...)` reads the requesting or observing source at the domain projection boundary; one socket must not borrow a sibling's capabilities.
-
-Example: adding a new enum value
-
-```ts
-// 1. Add CLIENT_CAPS.newThing = "new_thing"
-// 2. Let new clients advertise it in WS hello
-// 3. Keep the shared producer schema strict
-// 4. Gate the new emitted value: session.supports(CLIENT_CAPS.newThing) ? "new_value" : "old_value"
-```
-
-### Creation ownership
-
-Creation is owned by the daemon across socket lifetimes. A workspace request can include
-its initial agent and prompt. Workspace readiness is published before provider startup;
-the app keeps its existing disk-ready navigation and observes the remaining creation.
-Callbacks do not advance the workflow. Resource reservations in acknowledgement are
-identities, not ready workspace records.
-
-The creation journal (`server/creation/`) owns identity and execution for both legacy and
-modern creation RPCs. Requesting progress never selects a different journal. Existing
-agent receipts are imported at this boundary; message delivery receipts remain separate.
-It keeps cumulative milestones and permanent IDs under an operation kind and idempotency
-key. Reconnect subscribes to that key; retries
-join active work or reuse committed stages. A persisted resource alone cannot prove
-that a provider accepted its initial prompt. Interrupted side effects with no conclusive
-receipt return an unknown outcome instead of being repeated.
-
-Agent registration commits creation. Rejecting the first prompt is a turn error on that
-agent; reporting creation failure leaves an orphaned agent and invites another Create.
-Receipt replay must not resend the prompt.
-
-`packages/client/src/creation/` owns capability selection and legacy orchestration.
-Callers always pass the initial prompt to agent creation. On an older host, the client
-adapts keyed creation to the legacy create/send sequence; it cannot continue that
-sequence after the client process disappears. Explicitly requested IDs or receipts
-that an old host cannot honor produce an unsupported error. Keep these adapters inside
-the client package, as an exception to the default no-fallback feature policy.
-
-Creation executes through the existing Session capabilities. Connection-owned delivery
-controls observation only: detaching a socket or cleaning up its Session does not cancel
-accepted creation. Updates require an explicit subscription and go only to that socket;
-reconnect uses the shared subscription owner. Legacy consumers, including Hub, keep their
-existing response contract.
-
-## Agent lifecycle
-
-The lifecycle states are defined in `shared/agent-lifecycle.ts`:
-
-```
-initializing → idle ⇄ running
-        ↓       ↓        ↓
-              error
-                ↓
-              closed
-```
-
-- `initializing` — provider session is being created
-- `idle` — has a live session, awaiting the next prompt
-- `running` — provider is currently producing a turn
-- `error` — last attempt failed; session is still attached
-- `closed` — terminal state, no live session
-
-`ManagedAgent` is a discriminated union over those lifecycle tags. Notes:
-
-- **AgentManager** is the source of truth for agent state and broadcasts updates to all subscribers
-- Timeline sequence allocation is append-only with epochs (each run starts a new epoch). The one
-  permitted in-place enrichment adds a provider message id to the manager-owned row for an accepted
-  prompt; it preserves the row's sequence, content, and timestamp. Storage uses sequence numbers for
-  client-side dedup; the default fetch page is 200 items.
-- Timeline row `timestamp` values are canonical daemon-owned timestamps. Providers may supply original replay timestamps, but clients must not guess timestamp trust or hide time UI based on local clock heuristics.
-- Events stream to connected clients in real time; correctness is backed by authoritative timeline fetches and paged-to-completion catch-up.
-- Agent state persists to `$PASEO_HOME/agents/{cwd-with-dashes}/{agent-id}.json`. Timeline rows are runtime memory; provider history is the durable transcript authority and resumed agents rebuild from it. That storage path is derived from `cwd`, not from workspace id.
-
-## Right-sidebar boundary: directory-backed vs workspace-owned
-
-Two workspaces can share the same `cwd` (e.g. a `directory` workspace and a `local_checkout` workspace on the same folder, or several workspaces opened against one checkout). Model B keeps these distinct: they share everything the directory determines, but nothing the workspace owns. The right-sidebar surfaces split cleanly along this line, and the split is enforced purely by **what each piece of state is keyed by**.
-
-**Directory-backed (shared by same-`cwd` workspaces) — keyed by `(serverId, cwd)`, never by `workspaceId`:**
-
-| Surface                 | Key                                                      | Source                                                  |
-| ----------------------- | -------------------------------------------------------- | ------------------------------------------------------- |
-| Git status              | `checkoutStatusQueryKey(serverId, cwd)`                  | `packages/app/src/git/query-keys.ts`                    |
-| Git diff                | `checkoutDiffQueryKey(serverId, cwd, mode, baseRef, ws)` | `packages/app/src/git/query-keys.ts`                    |
-| Forge change request    | `checkoutPrStatusQueryKey(serverId, cwd)`                | `packages/app/src/git/query-keys.ts`                    |
-| Change request timeline | `prPaneTimelineQueryKey({ serverId, cwd, prNumber })`    | `packages/app/src/git/pull-request-panel/query-keys.ts` |
-| File preview content    | `["workspaceFile", serverId, cwd, path]`                 | `packages/app/src/components/file-pane.tsx`             |
-| File explorer listings  | fetched via `listDirectory(workspaceRoot, path)`         | `packages/app/src/hooks/use-file-explorer-actions.ts`   |
-
-**Workspace-owned (independent per workspace) — keyed by `workspaceId` (falling back to `cwd` only when no `workspaceId` exists):**
-
-| State                        | Key builder / store                                | Source                                                        |
-| ---------------------------- | -------------------------------------------------- | ------------------------------------------------------------- |
-| Review draft comments        | `buildReviewDraftKey`                              | `packages/app/src/review/store.ts`                            |
-| Working diff comparison      | `workingDiffComparisonKey` (in-memory)             | `packages/app/src/git/working-diff-comparison/state.ts`       |
-| Composer attachments         | `buildWorkspaceAttachmentScopeKey`                 | `packages/app/src/attachments/workspace-attachments-store.ts` |
-| File explorer nav/open state | `fileExplorer` map keyed `workspace:{workspaceId}` | `packages/app/src/hooks/use-file-explorer-actions.ts`         |
-| File explorer expanded paths | `expandedPathsByWorkspace[workspaceStateKey]`      | `packages/app/src/stores/panel-store/state.ts`                |
-
-`diff-pane.tsx` is the canonical wiring site: it passes `{ serverId, cwd }` to the git queries and `{ serverId, workspaceId, cwd }` to the draft/comparison/attachment scope keys.
-
-**Do not "fix" the sharing away.** Re-keying a directory-backed query by `workspaceId` makes same-`cwd` workspaces diverge (two windows onto the same git tree showing different diffs). Re-keying owned state (drafts, expanded paths) by `cwd` makes them leak between distinct workspaces on the same folder. The `workspaceId`-keyed builders carry a `// workspaceId is opaque; do not parse this key back into a path.` comment — the opaque-id fallback to `cwd` exists only for old payloads without a `workspaceId`, not as a content-sharing mechanism.
-
-One deliberate non-violation: `AgentFileExplorerState.directories`/`files` cache directory listings inside the `workspaceId`-keyed explorer map. Same-`cwd` workspaces therefore keep duplicate caches, but they can never diverge — both fetch the identical directory via `listDirectory(workspaceRoot, …)`. This is duplication, not leakage, and is left as-is.
-
-## Agent providers
-
-Each provider implements the `AgentClient` interface in `agent/agent-sdk-types.ts`. Provider implementations live in `agent/providers/`.
-
-The built-in, user-facing providers are Claude Code, Codex, Copilot, OpenCode, Pi, and OMP. Additional adapters exist in the same directory for ACP-compatible agents and internal use:
-
-| Provider           | Wraps                                | Session format                                     |
-| ------------------ | ------------------------------------ | -------------------------------------------------- |
-| Claude (`claude/`) | Anthropic Agent SDK                  | `~/.claude/projects/{cwd}/{session-id}.jsonl`      |
-| Codex              | Codex AppServer (`codex-app-server`) | `~/.codex/sessions/{date}/rollout-{ts}-{id}.jsonl` |
-| Copilot            | GitHub Copilot via ACP               | Provider-managed                                   |
-| OpenCode           | OpenCode server / CLI                | Provider-managed                                   |
-| Cursor             | ACP wrapper (`acp-agent`)            | Provider-managed                                   |
-| Generic ACP        | ACP wrapper                          | Provider-managed                                   |
-| Pi                 | Local Pi RPC process                 | Provider-managed                                   |
-| Mock load test     | In-process fake                      | In-memory                                          |
-
-All providers:
-
-- Handle their own authentication (Paseo does not manage API keys)
-- Support session resume via persistence handles
-- Map tool calls to a normalized `ToolCallDetail` type
-- Expose provider-specific modes (plan, default, full-access)
-
-Providers that can accept native tool definitions should set `supportsNativePaseoTools` and read `launchContext.paseoTools`. The daemon then passes the shared Paseo tool catalog directly and removes the internal Paseo MCP server from that provider launch config. Providers that only support MCP continue to receive the same tools through the MCP fallback at `/mcp/agents`.
-
-## Data flow: running an agent
-
-1. Client sends `CreateAgentRequestMessage` with config (prompt, cwd, provider, model, mode)
-2. Session routes to `AgentManager.create()`
-3. AgentManager creates a `ManagedAgent`, initializes provider session
-4. Provider runs the agent → emits `AgentStreamEvent` items
-5. Events append to the agent timeline, broadcast to all subscribed clients
-6. Tool calls are normalized to `ToolCallDetail` (shell, read, edit, write, search, etc.)
-7. Permission requests flow: agent → server → client → user decision → server → agent
-
-## Storage
-
-`$PASEO_HOME` defaults to `~/.paseo`. The most important files:
-
-```
-$PASEO_HOME/
-├── agents/{cwd-with-dashes}/{agent-id}.json   # Agent record
-├── projects/projects.json                      # Project registry
-├── projects/workspaces.json                    # Workspace registry
-├── projects/icons/                             # Custom project icon images
-├── schedules/                                  # Scheduled-agent definitions and runs
-├── config.json                                 # Daemon config (mutable)
-├── daemon-keypair.json                         # Daemon identity for relay/E2EE
-├── push-tokens.json                            # Mobile push tokens
-├── paseo.pid                                   # Supervisor identity and published bound endpoint
-└── daemon.log                                  # Daemon trace logs (rotated)
-```
-
-The supervisor alone publishes its ready worker's endpoint in `paseo.pid`, clears it before respawn, and fails if any worker exits before first readiness. CLI home selection trusts only that live record; config expresses desired state, never an endpoint fallback. POSIX home stop signals the captured supervisor without TCP. Windows graceful stop and ordinary RPCs trust the published endpoint. This metadata is not cryptographic listener ownership: edited endpoints, copied identities, PID reuse, and address takeover races remain outside that guarantee. A stale heartbeat never permits reclaiming a live lock.
-
-Worker restart retains supervisor arguments/environment and rereads the configuration file. Updating a package and observing its new worker version do not refresh the running supervisor code; the launcher owns full-process replacement. See [CLI lifecycle contracts](../public-docs/cli.md#daemon-management).
-
-## Deployment models
-
-1. **Local daemon** (default): `paseo daemon start` on `127.0.0.1:6767`
-2. **Managed desktop**: Electron uses the server package’s local-instance lifecycle capability for sanitized launch, published readiness, and captured-PID stop. Only a matching `{pid, startedAt}` from a spawn in the current Desktop session authorizes automatic stop or binary replacement. Preexisting instances, including legacy `desktopManaged` records, are attach-only. Keep-running survivors attach in the next session. Explicit attached Stop requires a confirmation naming the captured home/PID. Ordinary Restart uses the worker RPC on every app platform.
-3. **Remote + relay**: Daemon behind firewall, relay bridges with E2E encryption

docs/browser-capture-harness.md

@@ -1,123 +0,0 @@
-# Browser Capture Harness
-
-The desktop capture harness is the real-Electron verification path for browser screenshots.
-It validates the compositor behavior that unit tests cannot see:
-
-- the resident automation `<webview>` starts in the production parking state;
-- the parked guest remains paintable and has a copyable viewport frame;
-- a never-presented resident webview guest defaults to 1280x800 logical pixels;
-- multiple resident webviews are parked as an overlapping stack without per-capture
-  stacking changes;
-- a newly attached resident webview whose first useful frame is delayed can be captured
-  by retrying until the frame appears;
-- both viewport `capturePage` and full-page CDP screenshots return real pixels from
-  the permanent production parking state;
-- parked guests remain capturable with Chromium background throttling enabled;
-- the real-Electron host-composer sentinel proves guest Enter cannot submit a focused
-  host composer;
-- the automation group loads the compiled production keyboard boundary and guest
-  preload, then proves that initial page window handlers get first refusal, unhandled
-  shortcuts synchronously suppress editable browser defaults before crossing the host
-  boundary, shortcuts marked unavailable in editable targets retain the browser field's
-  native behavior, handlers registered after preload still get first refusal, focused
-  iframes share the same boundary, digit wildcard shortcuts cross, and background automation
-  stays in the guest.
-
-Run it with the repo Electron:
-
-```bash
-npm run capture-harness --workspace=@getpaseo/desktop
-```
-
-Build the desktop main process before the automation group so its production guest
-preload is available:
-
-```bash
-npm run build:main --workspace=@getpaseo/desktop
-PASEO_CAPTURE_HARNESS_GROUP=automation npm run capture-harness --workspace=@getpaseo/desktop
-```
-
-Run the shared browser profile fixture with:
-
-```bash
-PASEO_CAPTURE_HARNESS_GROUP=browser-profile npm run capture-harness --workspace=@getpaseo/desktop
-```
-
-On macOS, test native titlebar dragging after scrolling with:
-
-```bash
-PASEO_CAPTURE_HARNESS_GROUP=titlebar-drag npm run capture-harness --workspace=@getpaseo/desktop
-```
-
-This group needs Xcode Command Line Tools and Accessibility permission for the
-terminal running it. It sends real mouse input to its test window and checks
-window movement, including button clicks and a portal over the titlebar. Leave
-the mouse idle during this group. It reads the app's production CSS and writes
-screenshots and window bounds to the output directory.
-
-The browser profile group runs two Electron processes in sequence. It verifies that each
-renderer-side `did-attach` identity maps to the correct main-process guest, that two live
-tabs share cookies and local storage through one persistent session, and that the data is
-still present after the first Electron process exits and the second starts.
-
-The automation group uses a real guest webview to verify the page-side ref contract:
-ARIA-like snapshot text includes headings, static text, and controls; refs survive
-`pushState` when the element still matches; same-URL rerenders stale old refs; and a
-file-input ref can be resolved to a CDP backend node id for upload. It also verifies
-page-context evaluation, including passing a resolved ref element as the function argument.
-Keyboard containment runs last because the host-composer sentinel intentionally leaves
-native focus in the host. It reuses an existing fixture button: adding a test-only control
-changes the inline fixture geometry exercised by the earlier actionability checks.
-
-On macOS the harness process must set `app.setActivationPolicy("accessory")` and
-hide the Dock icon before creating any window. `showInactive()` only prevents window
-focus; a normal Electron app launch can still activate the app and steal focus.
-Harness windows are then created hidden, positioned in a screen corner, skipped from
-the taskbar where Electron supports it, and revealed with `showInactive()` from
-`ready-to-show`. Do not replace this with `show()`, `focus()`, or `app.focus()`:
-the compositor only needs visible inactive windows, and harness runs must not steal
-focus from the person using the machine.
-
-The harness writes PNG evidence and `results.json` to:
-
-```text
-packages/desktop/capture-harness/out/
-```
-
-A passing run prints `PASS` lines for the production P1 default-throttling parking state,
-including fresh, settled, 75-second soak, multi-tab, viewport, and full-page checks. The
-PNG sizes may be device-pixel scaled; on a Retina display the 1280x800 logical viewport
-is usually saved as 2560x1600.
-
-The existing `npm run test:e2e:browser-tabs --workspace=@getpaseo/desktop` journey
-verifies that a hidden window stops guest animation, captures fresh viewport pixels,
-and resumes animation after restoring the window. Its artifacts include the screenshot
-and animation measurements. Full-page content correctness remains separately tracked in
-[the full-page repetition bug](https://github.com/getpaseo/paseo/issues/3196).
-
-## Mechanism
-
-Electron captures copy from the guest web contents' compositor surface. A resident
-webview parked with `display:none`, offscreen coordinates, or `opacity:0` can lose its
-copyable surface. Each production webview keeps one permanent body-level surface. Presenting
-or parking changes that surface's geometry without reparenting the webview. The parking state
-uses `left:0`, `top:0`, `width:1px`, `height:1px`, `overflow:hidden`, `opacity:1`, and
-`pointer-events:none`. The webview stays at its resolved logical viewport, defaulting to
-1280x800 before first presentation, with `display:inline-flex` at `left:0`, `top:0`.
-Presentation resolves responsive guests to the pane's exact pixel dimensions after the surface
-has visible bounds. Do not apply percentage guest sizing against the parked surface: Electron
-exposes the 1x1 parking geometry as a real guest resize before expanding it again.
-
-The permanent browser host and `overlay-root` are explicit sibling paint planes. The browser
-plane stays below the overlay plane regardless of body insertion order; menus keep their relative
-layering inside `overlay-root`. Activating a presented browser also focuses its registered guest
-`WebContents` in main so macOS assigns keyboard first-responder ownership to the page.
-
-There is no renderer prep/restore handshake or lifetime background-throttling override.
-Screenshot capture temporarily enables frame production inside the shared serialized queue,
-restores the previous throttling policy on success or failure, and retains a 5-second capture budget.
-The browser tool takes one viewport frame through Electron's frame subscription and releases the
-subscription on completion or cancellation. A resized resident guest can produce fresh pixels
-while `capturePage()` leaves its surface-copy request pending; waiting for animation frames or
-retrying the copy does not repair that state. Full-page screenshots retain the CDP path with layout
-metrics and screenshot clip.

docs/coding-standards.md

@@ -1,116 +0,0 @@
-# Coding Standards
-
-The core instinct: AI-generated code hedges — it covers every case, layers over instead of cutting in, scatters uncertainty everywhere, wraps in case. A senior engineer commits — to a shape, a boundary, a name, a happy path, a type — and lets everything else fall into place. Every rule below catches a different form of indecision.
-
-For testing rules, see [testing.md](testing.md).
-
-## Core principles
-
-- **Zero complexity budget** — every abstraction must justify itself with a specific, current benefit.
-- **YAGNI** — build features and abstractions only when needed. A function called once is indirection, not abstraction.
-- **No "while I'm at it" cleanups** — make the change you came for. Drive-by edits hide in the diff.
-- **Functional and declarative** over object-oriented.
-- **`function` declarations** over arrow function assignments.
-- **`interface`** over `type` when both work.
-- **No `index.ts` barrel files** that only re-export — they create indirection and circular-dep risk. Import from the source.
-
-## Shell scripts
-
-- Bash scripts always use `#!/usr/bin/env bash`. Never hard-code `/bin/bash` or `/usr/bin/bash`; those paths are not portable to environments such as NixOS.
-
-## Comments and noise
-
-- Delete any comment where removing it loses zero information. Comments explain _why_, not _what_.
-- No tutorial comments explaining language features (`// Use destructuring to...`).
-- No decorative section dividers (`// ===== Helpers =====`). Use files and modules to organize, not ASCII art.
-- No hedging comments (`// might need to revisit`, `// should work for most cases`). If you're unsure, investigate.
-- No commented-out code. Git remembers.
-- No `console.log` / `debugger` left behind. No `TODO: implement` stubs — if it needs to exist, write it.
-
-## Confidence: commit to a shape
-
-- Validate at boundaries (network, IPC, user input, file I/O), trust types internally. After the parse, the value is what its type says.
-- Every `?.` and `??` past the validation boundary is unconfident code — either the boundary should resolve it, or the type should reflect reality.
-- No defensive checks for conditions the type system already rules out (`if (!agent) return` on a non-nullable parameter).
-- No `try/catch` "just in case." If you can't say what you're catching and why, don't catch.
-- Optionality is a design decision, not a migration shortcut. Distinct valid states → discriminated union. Intentionally empty → explicit `null`. Keep optionality at real boundaries.
-
-## Types
-
-- No `any`. No `as` casts to bypass errors. No `@ts-ignore` / `@ts-expect-error`. Narrow with `if` / schema validation; let the compiler check harder, not less.
-- If a Zod schema exists, the TypeScript type is `z.infer<typeof schema>`. Never hand-write a parallel type.
-- One canonical type per concept. Layer-specific views are `Pick` / `Omit`, not duplicated fields.
-- Name multi-property object shapes — no inline `Array<{ ... }>` or `Promise<{ ... }>` in signatures, returns, or generic args.
-- Use string literal unions, not raw `string`, when the value is one of a known set. Catches typos at compile time.
-- Object parameters past the obvious-name threshold: 3+ args, any boolean arg, any optional arg → object. `(thing, true, false, true)` is unreadable at the call site.
-- Make impossible states impossible — discriminated unions over `{ isLoading; error?; data? }` bags.
-
-## Errors
-
-- Throw typed error classes that carry the fields a caller would want to read. Plain `Error("Provider X not found")` collapses structured info into a string.
-- Catch blocks branch on `instanceof` for what they can handle; rethrow the rest. No `catch (e) { return null }`.
-- Separate user-facing copy from log/debug strings — don't make one string serve telemetry, logs, and the UI.
-- Fail explicitly. If the caller asked for X and X isn't available, throw — don't silently substitute Y.
-- Every fallible user action owns explicit pending, success, and failure UI. Console logs and unverified platform alerts do not satisfy this contract. See [testing.md](testing.md#fallible-user-actions).
-- A capability advertised to a client means the current runtime can perform the action, not merely that its RPC handler exists. If an unavailable action needs explanatory UI, send the runtime fact or reason separately and keep the server-side refusal fail-closed.
-
-## Density
-
-- Nested ternaries are forbidden. A single ternary is fine only when both branches are a single identifier or trivial access (`x ? a : b`).
-- Boolean expressions with 2+ clauses or mixed concerns → name the conditions.
-- Object literals assemble pre-computed values; don't pack branching and lookups into property positions.
-- Operations wrapping operations (`Object.fromEntries(arr.filter(...).map(...))`, `Math.max(...xs.map(...))`) → break into named intermediates.
-- Max 3 levels of nesting (callbacks, JSX, control flow). Above that, extract.
-
-## Structure and modules
-
-- A directory is a module, not a namespace. One intentional public surface; internal files stay internal.
-- Path is part of the name — prefer `provider/registry.ts` over `provider/provider-registry.ts`. If the filename has to do double duty, deepen the path.
-- Filenames ending in `-utils`, `-helpers`, `-manager`, `-handler`, `-controller`, `-formatter`, `-builder` are a smell — the path didn't carry enough domain.
-- Boundary returns answer the caller's question (`getActiveAgents()`), not "here's my storage" (`getAgents().filter(...)` repeated everywhere).
-- One adapter means a hypothetical seam; two adapters means a real one. Don't define a port until something actually varies across it.
-- Pass-through modules fail the deletion test — if removing the module makes callers go straight to what they wanted, delete it.
-- Centralize policy. The same discriminator (`plan`, `provider`, `kind`, `status`) branched in 3+ files → policy table, not another `else if` per case.
-- New features get a home before implementation. A feature smeared across 5 shared files is the same slop as a flat-peer namespace.
-- Don't drop new files at the nearest root just because placement is unclear — say so and ask.
-
-## Refactoring is a bolt-on test
-
-- A change should look like a thoughtful edit to existing code, not a new layer next to it. New coordinator wrapping a coordinator, new flag bypassing the normal path, new helper duplicating an existing selector — stop and reshape instead.
-- Refactors preserve behavior by default. No removing features to simplify code without explicit approval.
-- Have a verification plan _before_ refactoring — name the invariants, confirm a test holds them, write one if not. See [testing.md](testing.md).
-- Migrate all callers and remove old paths in the same refactor. No fallback behavior unless explicitly designed.
-
-## React
-
-- `useEffect` is for synchronizing with external systems (DOM, network, timers, subscriptions). Not for transforming React state. Derived state → compute in render or `useMemo`.
-- No effect cascades — chains of effects setting state that triggers more effects almost always want React Query or a reducer.
-- `useRef` is for DOM refs and non-rendering identities (timer IDs, AbortController, latest-callback caches). If the value affects what renders next, it's state — model it explicitly with `useReducer` and a discriminated union.
-- Server state goes through React Query. Manual `useState` + `useEffect` + `isLoading` + `error` for fetched data is always worse.
-- Components render and dispatch — they don't compute transitions. Two-plus interacting `useState`s → extract a reducer.
-- Never define components inside other components. Module-scope only.
-- Subscribe narrowly: select primitives from stores, pass `status` not `agent`, use `useShallow` / deep-equal when returning derived arrays/objects.
-- Collection rows do not independently subscribe to a high-frequency global store. The collection owner selects structurally shared indexes once, derives a keyed row model with `useMemo`, and passes entries to rows. This keeps retained hidden collections current without running one selector per row on every store update.
-- Equality functions prevent React renders; they do not prevent selector callbacks from running. A selector attached to a hot store must be O(1) when its relevant source references have not changed.
-- Retained native panels use `RetainedPanel`. If an existing gesture/layout wrapper must own visibility, wrap its contents in `RetainedPanelActivity` instead. Keep keyed panel roots in a stable sibling order, include the newly active panel in the same render, centralize subscriptions, and gate genuine effects through `useRetainedPanelActive`. Follow the [native ownership constraints and chat suspension boundary](mobile-panels.md) when stopping hidden rendering.
-- Infinite animations are subscriptions. Start them only while their retained panel is active, and cancel a shared clock when its final active consumer leaves. Synchronized animations use one clock per animation family and feed active instances through local shared values; retained hidden instances stay mounted but unsubscribed. Match state updates to the actual visual cadence; do not run every style worklet at 60 fps when the rendered value changes only a few times per second.
-- Stable references for props that cross `memo` boundaries or feed dependency arrays. Static literals at module scope `as const`; derived with `useMemo`; handlers with `useCallback` only when there's a memoized beneficiary.
-- Use stable ids for `key`, never array index for reorderable/filterable lists.
-- Context for stable values (theme, auth). Store with selectors for state that changes.
-
-### Retained panel measurements
-
-Inactive retained panels use `display: none`, so DOM and layout APIs report zero width and height. A non-positive measurement means the surface is not rendered; it is never a valid compact layout.
-
-- Suspend geometry-derived updates while either measured dimension is non-positive. Preserve the last valid state until the surface reports positive geometry again.
-- Enforce the rule at the measurement boundary shared by every trigger. Guarding only an `onLayout` or `ResizeObserver` callback still lets effects, content changes, and imperative remeasurement publish hidden geometry.
-- Test the hide-and-reveal path through a real retained surface. Settled assertions do not catch stale geometry painted during the first returned frames.
-
-## Naming
-
-- Names describe meaning, not mechanics. `submitForm` over `handleOnClickButtonSubmit`. `running` over `filteredArrayOfRunningAgents`.
-- The right length is the shortest unambiguous in context. Inside `AgentManager`, methods are `start`, `stop`, `list`.
-- Match the surrounding code's vocabulary. If the codebase uses `getX`, don't introduce `fetchX` / `retrieveX` for the same shape.
-- Don't leak implementation into names — `getAgent`, not `queryPostgresForAgent`. If swapping the impl would force a rename, the name is wrong.
-- Booleans read as yes/no questions: `isX`, `hasX`, `canX`. Avoid negative booleans (`isNotConnected`).
-- `data`, `result`, `info`, `manager`, `temp` are smells — say what the thing _is_.

docs/custom-providers.md

@@ -1,834 +0,0 @@
-# Custom Provider Configuration
-
-Paseo supports configuring custom agent providers through `config.json` (located at `$PASEO_HOME/config.json`, typically `~/.paseo/config.json`). You can extend built-in providers with different API backends, add ACP-compatible agents, set custom binaries, disable providers, and create multiple profiles for the same underlying provider.
-
-Provider definitions live under `agents.providers` in config.json:
-
-```json
-{
-  "version": 1,
-  "agents": {
-    "providers": {
-      "provider-id": { ... }
-    }
-  }
-}
-```
-
-Provider IDs must be lowercase alphanumeric with hyphens (`/^[a-z][a-z0-9-]*$/`).
-
-Each provider catalog refresh waits up to 2 minutes. If a provider loads many plugins or a large
-agent catalog during startup, raise the limit in milliseconds:
-
-```json
-{
-  "agents": {
-    "catalogRefreshTimeoutMs": 180000
-  }
-}
-```
-
-The limit applies independently to every provider refresh and covers availability plus the entire
-catalog probe. `PASEO_PROVIDER_REFRESH_TIMEOUT_MS` sets it when the config field is absent.
-
-## Provider options
-
-Set provider defaults in `agents.providers.<id>.options`. At agent creation, use
-`providerOptions` on the wire or `config.options` in the SDK. Both are opaque
-`Record<string, unknown>` values: the provider owns validation and application.
-Claude, Codex, and OpenCode reject unknown keys with a key-specific creation error.
-Providers without option handling ignore the record.
-
-The daemon deep-merges the agent's options over the provider defaults at each
-session launch or resume. Plain objects merge recursively; arrays, scalars, and
-`null` replace the base value. Only the agent's own options are persisted, so edits
-to provider defaults apply on the next launch or resume. A profile inherits its
-base provider's options unless it sets its own options record.
-
-```json
-{
-  "agents": {
-    "providers": {
-      "codex": {
-        "options": { "sandbox_mode": "read-only", "approval_policy": "never" }
-      }
-    }
-  }
-}
-```
-
-See the [SDK provider options guide](../public-docs/sdk/provider-options.md) for
-per-agent examples and provider-specific keys.
-
----
-
-## Table of Contents
-
-- [Extending a built-in provider](#extending-a-built-in-provider)
-- [Z.AI (Zhipu) coding plan](#zai-zhipu-coding-plan)
-- [Alibaba Cloud (Qwen) coding plan](#alibaba-cloud-qwen-coding-plan)
-- [Codex with a custom OpenAI-compatible endpoint](#codex-with-a-custom-openai-compatible-endpoint)
-- [Multiple profiles for the same provider](#multiple-profiles-for-the-same-provider)
-- [Custom binary for a provider](#custom-binary-for-a-provider)
-- [Disabling a provider](#disabling-a-provider)
-- [ACP providers](#acp-providers)
-- [Provider override reference](#provider-override-reference)
-
----
-
-## Extending a built-in provider
-
-Use `extends` to create a new provider entry that inherits from a built-in provider (claude, codex, copilot, opencode, pi, omp). The new provider gets its own entry in the provider list, with its own label, environment, and model definitions.
-
-```json
-{
-  "agents": {
-    "providers": {
-      "my-claude": {
-        "extends": "claude",
-        "label": "My Claude",
-        "description": "Claude with custom API endpoint",
-        "env": {
-          "ANTHROPIC_API_KEY": "sk-ant-...",
-          "ANTHROPIC_BASE_URL": "https://my-proxy.example.com/v1"
-        }
-      }
-    }
-  }
-}
-```
-
-Required fields for custom providers:
-
-- `extends` — which built-in provider to inherit from (or `"acp"`)
-- `label` — display name in the UI
-
-See [Codex with a custom OpenAI-compatible endpoint](#codex-with-a-custom-openai-compatible-endpoint) below for the dedicated Codex example.
-
----
-
-## Z.AI (Zhipu) coding plan
-
-[Z.AI](https://z.ai) is a Chinese AI company (Zhipu AI) that offers an Anthropic-compatible API endpoint. Their GLM Coding Plan provides flat-rate access to GLM models through Claude Code's Anthropic API protocol. These are **not** Anthropic Claude models — they are Zhipu's own GLM models exposed through an Anthropic-compatible API.
-
-### Setup
-
-1. Register at [z.ai](https://z.ai) and subscribe to a coding plan
-2. Create an API key from the Z.AI dashboard
-3. Add a provider entry in config.json:
-
-```json
-{
-  "agents": {
-    "providers": {
-      "zai": {
-        "extends": "claude",
-        "label": "ZAI",
-        "env": {
-          "ANTHROPIC_AUTH_TOKEN": "<your-zai-api-key>",
-          "ANTHROPIC_BASE_URL": "https://api.z.ai/api/anthropic",
-          "API_TIMEOUT_MS": "3000000"
-        },
-        "disallowedTools": ["WebSearch"],
-        "models": [
-          { "id": "glm-4.5-air", "label": "GLM 4.5 Air" },
-          { "id": "glm-5-turbo", "label": "GLM 5 Turbo", "isDefault": true },
-          { "id": "glm-5.1", "label": "GLM 5.1" }
-        ]
-      }
-    }
-  }
-}
-```
-
-### Available models
-
-| Model         | Tier                |
-| ------------- | ------------------- |
-| `glm-5.1`     | Advanced (flagship) |
-| `glm-5-turbo` | Advanced            |
-| `glm-4.7`     | Standard            |
-| `glm-4.5-air` | Lightweight         |
-
-### Notes
-
-- `ANTHROPIC_AUTH_TOKEN` is used instead of `ANTHROPIC_API_KEY` — this is the z.ai API key
-- The `API_TIMEOUT_MS` env var extends the request timeout (z.ai can be slower than direct Anthropic)
-- If you get auth errors, run `/logout` inside Claude Code before switching to the z.ai provider
-- Web search (`WebSearch` tool) is an Anthropic-only server-side feature — third-party endpoints don't support it. Add `"disallowedTools": ["WebSearch"]` to avoid errors.
-- Automated setup is also available: `npx @z_ai/coding-helper`
-- Official docs: [docs.z.ai/devpack/tool/claude](https://docs.z.ai/devpack/tool/claude)
-
----
-
-## Alibaba Cloud (Qwen) coding plan
-
-[Alibaba Cloud Model Studio](https://www.alibabacloud.com/en/campaign/ai-scene-coding) offers a coding plan that routes Claude Code requests to Qwen models through an Anthropic-compatible API. Like z.ai, these are **not** Anthropic Claude models.
-
-### Setup
-
-1. Go to the [Coding Plan page](https://modelstudio.console.alibabacloud.com/ap-southeast-1/?tab=globalset#/efm/coding_plan) on Alibaba Cloud Model Studio (Singapore region)
-2. Subscribe to the Pro plan ($50/month)
-3. Obtain your plan-specific API key (format: `sk-sp-xxxxx`) — this is different from a standard Model Studio key
-4. Add a provider entry in config.json:
-
-```json
-{
-  "agents": {
-    "providers": {
-      "qwen": {
-        "extends": "claude",
-        "label": "Qwen (Alibaba)",
-        "env": {
-          "ANTHROPIC_AUTH_TOKEN": "sk-sp-<your-coding-plan-key>",
-          "ANTHROPIC_BASE_URL": "https://coding-intl.dashscope.aliyuncs.com/apps/anthropic"
-        },
-        "disallowedTools": ["WebSearch"],
-        "models": [
-          { "id": "qwen3.5-plus", "label": "Qwen 3.5 Plus", "isDefault": true },
-          { "id": "qwen3-coder-next", "label": "Qwen 3 Coder Next" },
-          { "id": "kimi-k2.5", "label": "Kimi K2.5" }
-        ]
-      }
-    }
-  }
-}
-```
-
-### API endpoints
-
-| Mode                            | Base URL                                                    |
-| ------------------------------- | ----------------------------------------------------------- |
-| Coding plan (subscription)      | `https://coding-intl.dashscope.aliyuncs.com/apps/anthropic` |
-| Pay-as-you-go (no subscription) | `https://dashscope-intl.aliyuncs.com/apps/anthropic`        |
-
-For pay-as-you-go, use `ANTHROPIC_API_KEY` with a standard Model Studio key (`sk-xxxxx`) instead of `ANTHROPIC_AUTH_TOKEN`.
-
-### Available models
-
-**Recommended for coding plan:**
-
-| Model              | Notes                       |
-| ------------------ | --------------------------- |
-| `qwen3.5-plus`     | Vision capable, recommended |
-| `qwen3-coder-next` | Optimized for coding        |
-| `kimi-k2.5`        | Vision capable              |
-| `glm-5`            | Zhipu GLM                   |
-| `MiniMax-M3`       | MiniMax                     |
-
-**Additional models (pay-as-you-go):**
-`qwen3-max`, `qwen3.5-flash`, `qwen3-coder-plus`, `qwen3-coder-flash`, `qwen3-vl-plus`, `qwen3-vl-flash`
-
-### Notes
-
-- API keys must be created in the **Singapore region**
-- The coding plan is for personal use only in interactive coding tools
-- Web search (`WebSearch` tool) is an Anthropic-only server-side feature — third-party endpoints don't support it. Add `"disallowedTools": ["WebSearch"]` to avoid errors.
-- Official docs: [alibabacloud.com/help/en/model-studio/claude-code-coding-plan](https://www.alibabacloud.com/help/en/model-studio/claude-code-coding-plan)
-
----
-
-## Codex with a custom OpenAI-compatible endpoint
-
-Codex talks to OpenAI's Responses API by default. Custom providers that extend `"codex"` can point Codex at any OpenAI-compatible endpoint (OpenRouter, LiteLLM, vLLM, llama.cpp server, an internal gateway, etc.) by setting `OPENAI_BASE_URL` and `OPENAI_API_KEY` in the provider `env`.
-
-Paseo passes those variables through to the Codex app-server process **and** maps them into Codex's thread config under `model_provider` / `model_providers`, because Codex reads provider routing from config rather than from `OPENAI_BASE_URL` alone.
-
-### Setup
-
-```json
-{
-  "agents": {
-    "providers": {
-      "my-codex": {
-        "extends": "codex",
-        "label": "My Codex",
-        "description": "Codex via custom OpenAI-compatible endpoint",
-        "env": {
-          "OPENAI_API_KEY": "sk-...",
-          "OPENAI_BASE_URL": "https://custom-relay.example.com"
-        },
-        "models": [{ "id": "custom-model", "label": "Custom Model", "isDefault": true }]
-      }
-    }
-  }
-}
-```
-
-### What Paseo wires up
-
-Under the hood, for each custom Codex provider Paseo injects this into Codex's config:
-
-```toml
-model_provider = "my-codex"
-
-[model_providers.my-codex]
-name = "My Codex"
-base_url = "https://custom-relay.example.com/v1"
-wire_api = "responses"
-env_key = "OPENAI_API_KEY"
-requires_openai_auth = false
-```
-
-- `base_url` — taken from `OPENAI_BASE_URL`. If it does not already end in `/v1`, Paseo appends `/v1`. Trailing slashes are stripped.
-- `wire_api` — always `"responses"` (OpenAI Responses API protocol).
-- `env_key` — set to `"OPENAI_API_KEY"` when that env var is present and non-empty, so Codex reads the key from the same env var Paseo passes through.
-- `requires_openai_auth` — forced to `false` when `OPENAI_API_KEY` is provided, so Codex skips its built-in OpenAI login flow.
-
-### Notes
-
-- The endpoint must speak the OpenAI **Responses API**, not just chat completions. Many gateways (OpenRouter, LiteLLM) support both — pick the Responses-compatible route.
-- Set `models` explicitly. Custom endpoints expose their own model IDs (`anthropic/claude-opus-4-7`, `qwen/qwen3-coder`, `local/llama`, etc.), and Paseo does not discover them automatically for Codex.
-- To run multiple endpoints side-by-side, define multiple entries that each extend `"codex"` with different IDs, labels, and env. Each appears as its own provider in the app.
-- If you only want to override the binary (e.g. a nightly Codex build) without changing the endpoint, omit `OPENAI_BASE_URL` and use `command` instead — see [Custom binary for a provider](#custom-binary-for-a-provider).
-
----
-
-## Multiple profiles for the same provider
-
-You can create multiple entries that extend the same built-in provider. Each gets its own entry in the provider list with independent credentials, models, and environment.
-
-"Profile" here means a provider alias, and it is not an **Agent profile** — that is a named bundle of provider, model, mode, thinking option and features, stored under `daemon.agentProfiles`. See [glossary.md](glossary.md) for all four senses of the word.
-
-Example: two different Anthropic accounts as separate profiles:
-
-```json
-{
-  "agents": {
-    "providers": {
-      "claude-work": {
-        "extends": "claude",
-        "label": "Claude (Work)",
-        "description": "Work Anthropic account",
-        "env": {
-          "ANTHROPIC_API_KEY": "sk-ant-work-..."
-        }
-      },
-      "claude-personal": {
-        "extends": "claude",
-        "label": "Claude (Personal)",
-        "description": "Personal Anthropic account",
-        "env": {
-          "ANTHROPIC_API_KEY": "sk-ant-personal-..."
-        }
-      }
-    }
-  }
-}
-```
-
-Each profile appears as a separate provider in the Paseo app. You can select which one to use when launching an agent.
-
-You can also combine profiles with model overrides to pin specific models per profile:
-
-```json
-{
-  "agents": {
-    "providers": {
-      "claude-fast": {
-        "extends": "claude",
-        "label": "Claude (Fast)",
-        "models": [{ "id": "claude-sonnet-4-6", "label": "Sonnet 4.6", "isDefault": true }]
-      },
-      "claude-smart": {
-        "extends": "claude",
-        "label": "Claude (Smart)",
-        "models": [{ "id": "claude-opus-4-6", "label": "Opus 4.6", "isDefault": true }]
-      }
-    }
-  }
-}
-```
-
----
-
-## Custom binary for a provider
-
-Override the command used to launch any provider with the `command` field. This is an array where the first element is the binary and the rest are arguments.
-
-### Override a built-in provider's binary
-
-```json
-{
-  "agents": {
-    "providers": {
-      "claude": {
-        "command": ["/opt/claude-nightly/claude"]
-      }
-    }
-  }
-}
-```
-
-### Use a custom wrapper script
-
-```json
-{
-  "agents": {
-    "providers": {
-      "claude": {
-        "command": ["/usr/local/bin/my-claude-wrapper", "--verbose"]
-      }
-    }
-  }
-}
-```
-
-### Custom binary on a derived provider
-
-```json
-{
-  "agents": {
-    "providers": {
-      "my-codex": {
-        "extends": "codex",
-        "label": "Codex (Custom Build)",
-        "command": ["/home/user/codex-dev/target/release/codex"]
-      }
-    }
-  }
-}
-```
-
-The `command` array completely replaces the default command for that provider. The binary must exist on the system — Paseo checks for its availability and will mark the provider as unavailable if not found.
-
-### OMP profiles and Pi-compatible forks
-
-OMP ships as a first-class built-in provider option. It is disabled by default; enable it with:
-
-```json
-{
-  "agents": {
-    "providers": {
-      "omp": { "enabled": true }
-    }
-  }
-}
-```
-
-Custom OMP profiles should extend `omp`. They inherit the OMP adapter's `rpc-ui` approvals, native Paseo host tools, provider-managed subagents, and import behavior:
-
-```json
-{
-  "agents": {
-    "providers": {
-      "omp-work": {
-        "extends": "omp",
-        "label": "Oh My Pi (Work)",
-        "command": ["omp"],
-        "env": {
-          "XDG_CONFIG_HOME": "~/.config/omp-work",
-          "XDG_STATE_HOME": "~/.local/state/omp-work"
-        },
-        "options": {
-          "sessionDir": "~/.local/state/omp-work/omp/agent/sessions",
-          "rpcTimeoutMs": 60000,
-          "smolModel": "openai/gpt-5-mini",
-          "slowModel": "anthropic/claude-opus-4-1",
-          "planModel": "openai/o3"
-        }
-      }
-    }
-  }
-}
-```
-
-`options.sessionDir` is used only for importing sessions that were started outside Paseo. If `command` or XDG env vars move OMP's state directory, set `options.sessionDir` to the resulting OMP JSONL session directory; launching and resuming still go through the configured command. OMP waits 20 seconds for its initial `ready` frame and 60 seconds for later control-plane RPCs by default. `options.rpcTimeoutMs` overrides both deadlines.
-
-For other providers that keep Pi's `--mode rpc` API but write sessions somewhere else, extend `pi`, replace the command, and provide the JSONL session directory:
-
-```json
-{
-  "agents": {
-    "providers": {
-      "my-pi-fork": {
-        "extends": "pi",
-        "label": "My Pi Fork",
-        "command": ["my-pi-fork"],
-        "options": {
-          "sessionDir": "~/.my-pi-fork/sessions",
-          "rpcTimeoutMs": 60000
-        }
-      }
-    }
-  }
-}
-```
-
-This session directory is also import-only. Launching and resuming still go through the configured command, so this example resumes with `my-pi-fork --mode rpc --session <session-file>`. `options.rpcTimeoutMs` overrides the 60-second Pi control-plane RPC deadline.
-
----
-
-## Disabling a provider
-
-Set `enabled: false` to hide a provider from the provider list. The provider will not appear in the app or CLI.
-
-```json
-{
-  "agents": {
-    "providers": {
-      "copilot": { "enabled": false },
-      "codex": { "enabled": false }
-    }
-  }
-}
-```
-
-This works for both built-in and custom providers. To re-enable, set `enabled: true` or remove the `enabled` field entirely. Most providers are enabled by default; OMP is intentionally disabled by default and requires `enabled: true`.
-
----
-
-## ACP providers
-
-The [Agent Client Protocol (ACP)](https://agentclientprotocol.com) is an open standard for communication between editors and AI coding agents — think LSP but for AI agents. Any agent that supports ACP can be added to Paseo as a custom provider.
-
-ACP agents communicate over JSON-RPC 2.0 on stdio. Paseo spawns the agent process and talks to it through stdin/stdout.
-
-Paseo also ships an in-app ACP provider catalog for common agents, including CodeWhale, Cursor, DeepAgents, DimCode, Gemini CLI, Hermes, Qwen Code, and Kimi Code. Catalog entries create the same `extends: "acp"` provider config shown below.
-
-### Adding a generic ACP provider
-
-Set `extends: "acp"` and provide a `command`:
-
-```json
-{
-  "agents": {
-    "providers": {
-      "my-agent": {
-        "extends": "acp",
-        "label": "My Agent",
-        "command": ["my-agent-binary", "--acp"],
-        "env": {
-          "MY_API_KEY": "..."
-        }
-      }
-    }
-  }
-}
-```
-
-Required fields for ACP providers:
-
-- `extends: "acp"`
-- `label`
-- `command` — the command to spawn the agent process (must support ACP over stdio)
-
-Paseo tools such as subagent creation come from the shared internal tool catalog. ACP providers receive those tools through the MCP fallback by default because ACP exposes `mcpServers`, not Paseo's native tool catalog. Some ACP adapters cannot create sessions when `mcpServers` is non-empty. Disable injected MCP for those providers with `options.supportsMcpServers: false`:
-
-```json
-{
-  "agents": {
-    "providers": {
-      "my-agent": {
-        "extends": "acp",
-        "label": "My Agent",
-        "command": ["my-agent", "acp"],
-        "options": {
-          "supportsMcpServers": false
-        }
-      }
-    }
-  }
-}
-```
-
-ACP agents execute filesystem operations in their own environment by default,
-while terminal operations run through Paseo on the host. To customize which
-operations Paseo handles, configure client capabilities in provider options:
-
-```json
-{
-  "agents": {
-    "providers": {
-      "container-agent": {
-        "extends": "acp",
-        "label": "Container Agent",
-        "command": ["container-agent", "acp"],
-        "options": {
-          "clientCapabilities": {
-            "fs": {
-              "readTextFile": false,
-              "writeTextFile": false
-            },
-            "terminal": false
-          }
-        }
-      }
-    }
-  }
-}
-```
-
-When an agent runs in a container or remote environment that manages its own
-terminal, set `terminal: false` to keep command execution inside the agent
-container. When delegating filesystem operations to Paseo (`fs.readTextFile: true`
-or `fs.writeTextFile: true`), ensure the agent and Paseo share equivalent
-absolute workspace paths.
-
-### Generic ACP diagnostics
-
-Paseo diagnostics for `extends: "acp"` providers report the configured command, resolved launcher binary, version output, ACP `initialize`, ACP `session/new`, model count, modes, and final status.
-
-For package-runner commands such as `npx -y @google/gemini-cli --acp`, the version probe keeps the package spec and runs `npx -y @google/gemini-cli --version`. This diagnoses the actual agent package instead of only proving that `npx` exists.
-
-ACP probes use short timeouts and browser-suppression environment variables so agents that enter an auth/browser flow fail as a diagnostic error instead of hanging the provider screen.
-
-### Example: Google Gemini CLI
-
-[Gemini CLI](https://github.com/google-gemini/gemini-cli) supports ACP via the `--acp` flag.
-
-1. Install: `npm install -g @google/gemini-cli` or see [Gemini CLI docs](https://github.com/google-gemini/gemini-cli)
-2. Authenticate with Google (Gemini CLI handles its own auth)
-3. Add to config.json:
-
-```json
-{
-  "agents": {
-    "providers": {
-      "gemini": {
-        "extends": "acp",
-        "label": "Google Gemini",
-        "command": ["gemini", "--acp"]
-      }
-    }
-  }
-}
-```
-
-Ref: [Gemini CLI ACP mode docs](https://github.com/google-gemini/gemini-cli/blob/main/docs/cli/acp-mode.md)
-
-### Example: Hermes (Nous Research)
-
-[Hermes](https://github.com/NousResearch/hermes-agent) is an open-source coding agent by Nous Research with persistent memory and multi-provider LLM support. It supports ACP via the `acp` subcommand.
-
-1. Install: `curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash`
-2. Install ACP support: `pip install -e '.[acp]'`
-3. Configure Hermes credentials in `~/.hermes/`
-4. Add to config.json:
-
-```json
-{
-  "agents": {
-    "providers": {
-      "hermes": {
-        "extends": "acp",
-        "label": "Hermes",
-        "description": "Nous Research self-improving AI agent",
-        "command": ["hermes", "acp"]
-      }
-    }
-  }
-}
-```
-
-Ref: [Hermes ACP docs](https://hermes-agent.nousresearch.com/docs/user-guide/features/acp)
-
-### How ACP providers work in Paseo
-
-When you launch an agent with an ACP provider:
-
-1. Paseo spawns the process using the configured `command`
-2. Sends an `initialize` JSON-RPC request over stdin
-3. The agent responds with its capabilities, available modes, and models
-4. Paseo creates a session and sends prompts through the ACP protocol
-5. The agent streams responses, tool calls, and permission requests back over stdout
-
-Every ACP provider exposes an **Auto Accept** toggle. Enable it per session to let Paseo approve
-ACP permission requests without surfacing each prompt. If the provider sends no allow option,
-Paseo leaves the request for you to answer. Unattended agents enable Auto Accept unless you
-explicitly disable it.
-
-Models and modes are discovered dynamically at runtime from the agent process. If you want to override the model list (e.g., to curate which models appear in the UI), use the `models` field:
-
-```json
-{
-  "agents": {
-    "providers": {
-      "my-agent": {
-        "extends": "acp",
-        "label": "My Agent",
-        "command": ["my-agent", "--acp"],
-        "models": [
-          { "id": "fast-model", "label": "Fast", "isDefault": true },
-          { "id": "smart-model", "label": "Smart" }
-        ]
-      }
-    }
-  }
-}
-```
-
-Profile models (defined in config.json) completely replace runtime-discovered models when present.
-
-If you want to keep runtime-discovered models and add or relabel a few entries, use `additionalModels` instead.
-
-Example: add an experimental model while keeping every model the provider discovers at runtime:
-
-```json
-{
-  "agents": {
-    "providers": {
-      "my-agent": {
-        "extends": "acp",
-        "label": "My Agent",
-        "command": ["my-agent", "--acp"],
-        "additionalModels": [
-          { "id": "experimental-model", "label": "Experimental", "isDefault": true }
-        ]
-      }
-    }
-  }
-}
-```
-
-Example: relabel a discovered model without replacing the full list:
-
-```json
-{
-  "agents": {
-    "providers": {
-      "my-agent": {
-        "extends": "acp",
-        "label": "My Agent",
-        "command": ["my-agent", "--acp"],
-        "additionalModels": [{ "id": "provider/model-id", "label": "My Preferred Label" }]
-      }
-    }
-  }
-}
-```
-
-When an `additionalModels` entry has the same `id` as a discovered model, it updates that model in place.
-
----
-
-## Provider override reference
-
-Every entry under `agents.providers` accepts these fields:
-
-| Field              | Type                      | Required          | Description                                                        |
-| ------------------ | ------------------------- | ----------------- | ------------------------------------------------------------------ |
-| `extends`          | `string`                  | Yes (custom only) | Built-in provider ID to inherit from, or `"acp"`                   |
-| `label`            | `string`                  | Yes (custom only) | Display name in the UI                                             |
-| `description`      | `string`                  | No                | Short description shown in the UI                                  |
-| `command`          | `string[]`                | Yes (ACP only)    | Command to spawn the agent process                                 |
-| `env`              | `Record<string, string>`  | No                | Environment variables to set for the agent process                 |
-| `options`          | `Record<string, unknown>` | No                | Provider-specific options such as `supportsMcpServers: false`      |
-| `models`           | `ProviderProfileModel[]`  | No                | Static model list (overrides runtime discovery)                    |
-| `additionalModels` | `ProviderProfileModel[]`  | No                | Static model additions (merged with runtime discovery or `models`) |
-| `disallowedTools`  | `string[]`                | No                | Tool names to disable for this provider (e.g. `["WebSearch"]`)     |
-| `enabled`          | `boolean`                 | No                | Set to `false` to hide the provider (default: `true`)              |
-| `order`            | `number`                  | No                | Sort order in the provider list                                    |
-
-### Model definition
-
-Each entry in the `models` array:
-
-| Field             | Type               | Required | Description                           |
-| ----------------- | ------------------ | -------- | ------------------------------------- |
-| `id`              | `string`           | Yes      | Model identifier sent to the provider |
-| `label`           | `string`           | Yes      | Display name in the UI                |
-| `description`     | `string`           | No       | Short description                     |
-| `isDefault`       | `boolean`          | No       | Mark as the default model selection   |
-| `thinkingOptions` | `ThinkingOption[]` | No       | Available thinking/reasoning levels   |
-
-### Thinking option
-
-| Field         | Type      | Required | Description                         |
-| ------------- | --------- | -------- | ----------------------------------- |
-| `id`          | `string`  | Yes      | Thinking option identifier          |
-| `label`       | `string`  | Yes      | Display name                        |
-| `description` | `string`  | No       | Short description                   |
-| `isDefault`   | `boolean` | No       | Mark as the default thinking option |
-
-### Claude settings.json model discovery
-
-The built-in `claude` provider appends concrete model IDs from `~/.claude/settings.json` to its first-party Claude model list. Paseo reads the top-level `model` field and these `env` keys: `ANTHROPIC_MODEL`, `ANTHROPIC_SMALL_FAST_MODEL`, `ANTHROPIC_DEFAULT_FABLE_MODEL`, `ANTHROPIC_DEFAULT_OPUS_MODEL`, `ANTHROPIC_DEFAULT_SONNET_MODEL`, and `ANTHROPIC_DEFAULT_HAIKU_MODEL`.
-
-This lets users who already configured Claude Code for Bedrock, OpenRouter, ollama, Z.AI, or another Anthropic-compatible gateway select the exact model ID in Paseo. Explicit model IDs are passed unchanged to Claude Code, even when the same string is a compatibility alias for a built-in model. When `agents.providers.claude.models` is set it **replaces** both the hardcoded first-party Claude list and any settings.json-discovered entries; use `agents.providers.claude.additionalModels` to keep the first-party list and append curated entries on top.
-
-### Gotcha: `extends: "claude"` with third-party endpoints
-
-When a custom provider extends `"claude"` but points `ANTHROPIC_BASE_URL` at a non-Anthropic API (Z.AI, Alibaba/Qwen, proxies), the Claude Agent SDK may try to use Anthropic-only server-side tools like `WebSearch`. Third-party APIs don't support these tools, causing errors.
-
-Use `disallowedTools` to disable unsupported tools:
-
-```json
-{
-  "agents": {
-    "providers": {
-      "my-proxy": {
-        "extends": "claude",
-        "label": "My Proxy",
-        "env": {
-          "ANTHROPIC_BASE_URL": "https://my-proxy.example.com/v1"
-        },
-        "disallowedTools": ["WebSearch"]
-      }
-    }
-  }
-}
-```
-
-### Valid `extends` values
-
-Built-in providers: `claude`, `codex`, `copilot`, `opencode`, `pi`, `omp`
-
-Special value: `acp` — creates a generic ACP provider (requires `command`)
-
-### Full example
-
-A config.json with multiple custom providers:
-
-```json
-{
-  "version": 1,
-  "agents": {
-    "providers": {
-      "copilot": { "enabled": false },
-
-      "zai": {
-        "extends": "claude",
-        "label": "ZAI",
-        "env": {
-          "ANTHROPIC_AUTH_TOKEN": "<zai-api-key>",
-          "ANTHROPIC_BASE_URL": "https://api.z.ai/api/anthropic",
-          "API_TIMEOUT_MS": "3000000"
-        },
-        "disallowedTools": ["WebSearch"],
-        "models": [
-          { "id": "glm-4.5-air", "label": "GLM 4.5 Air" },
-          { "id": "glm-5-turbo", "label": "GLM 5 Turbo", "isDefault": true },
-          { "id": "glm-5.1", "label": "GLM 5.1" }
-        ]
-      },
-
-      "qwen": {
-        "extends": "claude",
-        "label": "Qwen (Alibaba)",
-        "env": {
-          "ANTHROPIC_AUTH_TOKEN": "sk-sp-<coding-plan-key>",
-          "ANTHROPIC_BASE_URL": "https://coding-intl.dashscope.aliyuncs.com/apps/anthropic"
-        },
-        "disallowedTools": ["WebSearch"],
-        "models": [
-          { "id": "qwen3.5-plus", "label": "Qwen 3.5 Plus", "isDefault": true },
-          { "id": "qwen3-coder-next", "label": "Qwen 3 Coder Next" }
-        ]
-      },
-
-      "gemini": {
-        "extends": "acp",
-        "label": "Google Gemini",
-        "command": ["gemini", "--acp"]
-      },
-
-      "hermes": {
-        "extends": "acp",
-        "label": "Hermes",
-        "command": ["hermes", "acp"]
-      }
-    }
-  }
-}
-```

docs/data-model.md

@@ -1,631 +0,0 @@
-# Data Model
-
-## Project identity
-
-Projects are allocated for the exact root selected by the caller, normalized lexically with `path.resolve` (never `realpath`). New project IDs are opaque `prj_<16 hex>` values. Existing remote-shaped or path-shaped IDs are retained as readable compatibility records and are never rekeyed. An active exact root is idempotent; archived-only matches do not resurrect an old project. Workspace `projectId` is stable membership: reconciliation may update git-derived kind and branch metadata, but never rehomes a workspace or changes a project's root, ID, or default name.
-
-`projectKey` is a persisted, opaque equivalence key used only to group the same logical project
-across hosts. It is separate from the host-local `projectId`; today's producer prefers a normalized
-Git remote and otherwise uses the local project root. Consumers never derive it from live Git.
-Creation persists it with the project, and normal boot reconciliation fills it for
-older records where the field is absent—there is no migration.
-
-`kind` and `projectKey` are mutable metadata, not identity. Workspace reconciliation watches active project roots and
-updates those fields and `updatedAt` when Git facts change, preserving the project's ID, root path,
-names, and workspace foreign keys. Attached workspaces are independently refreshed
-from their own cwd, so an explicit project root never implies a workspace checkout. Empty projects
-are observed too.
-
-The workspace registry model defines placement once: initial directory/worktree construction,
-mutable reconciliation fields, and the persisted-to-wire checkout projection. Its update policy
-preserves `displayName` and `baseBranch`. `WorkspaceProvisioningService` owns the corresponding
-registry writes, so directory opens, agent imports, and worktree creation all enter through that
-service instead of constructing records independently. The workspace record is then the durable
-placement authority: `cwd` is the exact execution directory, while `worktreeRoot` is the backing
-checkout root. They intentionally differ for an exact subproject inside a worktree. Archive,
-restore, branch auto-name, and descriptor flows consume those persisted facts rather than
-rediscovering ownership from a directory that may already be gone. Reconciliation may refresh
-mutable placement facts, but never changes `projectId`, `cwd`, `displayName`, or `baseBranch`.
-Workspace archive runs lifecycle teardown from the exact `cwd` but removes only the backing
-`worktreeRoot` after its last active reference disappears. Worktree recovery recreates that backing
-checkout from `mainRepoRoot`, then restores the relative path from `worktreeRoot` to `cwd`.
-
-Paseo uses **file-based JSON persistence** instead of a traditional database. All data is validated at runtime with Zod schemas. Most stores write atomically (write to temp file, then rename); a few still use plain `writeFile` — see each section. There is no schema-versioning/migration framework — schemas rely on optional fields with defaults for forward compatibility, with a small amount of inline normalization in `persisted-config.ts` for legacy provider/speech entries.
-
-All server-side stores live under `$PASEO_HOME` (defaults to `~/.paseo`).
-
-## Store Surface Rules
-
-Store APIs own persistence atomicity and should not make services coordinate raw reads and writes. A good store method maps cleanly to one SQL statement or one SQL transaction, even when the current implementation is JSON files. If a caller needs a queue, lock, read-merge-write loop, or uniqueness race workaround, that behavior belongs behind the store surface.
-
----
-
-## Directory layout
-
-```
-$PASEO_HOME/
-├── config.json                          # Daemon configuration
-├── server-id                            # Stable daemon identifier (plain text, "srv_<base64url>")
-├── daemon-keypair.json                  # E2EE keypair for relay (mode 0600)
-├── paseo.pid                            # Daemon PID lock file
-├── local-credential                     # Per-run local client credential (mode 0600)
-├── daemon.log                           # Default log file (path configurable)
-├── agents/
-│   └── {sanitized-cwd}/
-│       └── {agentId}.json               # One file per agent
-├── schedules/
-│   └── {scheduleId}.json                # One file per schedule
-├── projects/
-│   ├── projects.json                    # Project registry
-│   ├── workspaces.json                  # Workspace registry
-│   ├── workspace-labels.json            # Shared host-local label catalog
-│   ├── workspace-labels.transaction.json # Recoverable catalog/assignment compound commit
-│   └── icons/                           # Host-local custom project icon images
-├── runtime/
-│   └── managed-processes/
-│       └── {recordId}.json              # Helper processes owned by Paseo; reconciled on daemon bootstrap
-├── plugins/
-│   ├── sources.json                      # Managed kind and Git acquisition remote
-│   └── {pluginId}/{uuid}/                # Git checkout or npm package/lockfile/dependency tree
-└── push-tokens.json                     # Expo push notification tokens
-```
-
-The `agents/{sanitized-cwd}/` directory name is derived from the agent's `cwd` by stripping the filesystem root and replacing path separators with `-` (Windows drive letters become a `C-` style prefix). Persistent server stores write atomically by writing a temp file in the target directory and then renaming it into place.
-
----
-
-## 1. Agent Record
-
-**Path:** `$PASEO_HOME/agents/{project-dir}/{agentId}.json`
-
-Each agent is stored as a separate JSON file, grouped by project directory.
-
-| Field                | Type                                     | Description                                                                                                                                                                                                                                                                                                                                                                         |
-| -------------------- | ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `id`                 | `string`                                 | UUID, primary key                                                                                                                                                                                                                                                                                                                                                                   |
-| `provider`           | `string`                                 | Agent provider (`"claude"`, `"codex"`, `"opencode"`, etc.)                                                                                                                                                                                                                                                                                                                          |
-| `cwd`                | `string`                                 | Working directory the agent operates in                                                                                                                                                                                                                                                                                                                                             |
-| `workspaceId`        | `string?`                                | Owning workspace id — the single source of ownership. Every agent is stamped with one at create time; legacy cwd-only records are backfilled once by `migrations/backfill-workspace-id.migration.ts` (the only place a cwd→id mapping exists). Runtime code never infers ownership or status from cwd: status is computed per `workspaceId`, and same-cwd siblings are independent. |
-| `createdAt`          | `string` (ISO 8601)                      | Creation timestamp                                                                                                                                                                                                                                                                                                                                                                  |
-| `updatedAt`          | `string` (ISO 8601)                      | Last update timestamp                                                                                                                                                                                                                                                                                                                                                               |
-| `lastActivityAt`     | `string?` (ISO 8601)                     | Last activity timestamp                                                                                                                                                                                                                                                                                                                                                             |
-| `lastUserMessageAt`  | `string?` (ISO 8601)                     | Last user message timestamp                                                                                                                                                                                                                                                                                                                                                         |
-| `title`              | `string?`                                | User-visible title                                                                                                                                                                                                                                                                                                                                                                  |
-| `labels`             | `Record<string, string>`                 | Key-value labels (default `{}`). Paseo uses `paseo.parent-agent-id` for parentage and client-scoped `paseo.open-agent-tab.*` labels while managed subagent tabs are open — see [agent-lifecycle.md](./agent-lifecycle.md)                                                                                                                                                           |
-| `lastStatus`         | `AgentStatus`                            | One of: `"initializing"`, `"idle"`, `"running"`, `"error"`, `"closed"`. `closed` means the record is resumable but has no live provider runtime; archive remains represented separately by `archivedAt`.                                                                                                                                                                            |
-| `lastModeId`         | `string?`                                | Last active mode ID                                                                                                                                                                                                                                                                                                                                                                 |
-| `config`             | `SerializableConfig?`                    | Agent session configuration (see below)                                                                                                                                                                                                                                                                                                                                             |
-| `runtimeInfo`        | `RuntimeInfo?`                           | Live runtime state (see below)                                                                                                                                                                                                                                                                                                                                                      |
-| `features`           | `AgentFeature[]?`                        | Provider-reported features (toggles/selects)                                                                                                                                                                                                                                                                                                                                        |
-| `persistence`        | `PersistenceHandle?`                     | Handle for resuming sessions                                                                                                                                                                                                                                                                                                                                                        |
-| `lastError`          | `string?` (nullable)                     | Last error message, if any                                                                                                                                                                                                                                                                                                                                                          |
-| `requiresAttention`  | `boolean?`                               | Whether the agent needs user attention                                                                                                                                                                                                                                                                                                                                              |
-| `attentionReason`    | `"finished" \| "error" \| "permission"?` | Why attention is needed                                                                                                                                                                                                                                                                                                                                                             |
-| `attentionTimestamp` | `string?` (ISO 8601)                     | When attention was flagged                                                                                                                                                                                                                                                                                                                                                          |
-| `internal`           | `boolean?`                               | Whether this is a system-internal agent                                                                                                                                                                                                                                                                                                                                             |
-| `archivedAt`         | `string?` (ISO 8601)                     | Soft-delete timestamp                                                                                                                                                                                                                                                                                                                                                               |
-
-### Nested: SerializableConfig
-
-| Field              | Type                       | Description                  |
-| ------------------ | -------------------------- | ---------------------------- |
-| `title`            | `string?`                  | Configured title             |
-| `modeId`           | `string?`                  | Configured mode              |
-| `model`            | `string?`                  | Configured model             |
-| `thinkingOptionId` | `string?`                  | Thinking/reasoning level     |
-| `featureValues`    | `Record<string, unknown>?` | Feature preference overrides |
-| `extra`            | `Record<string, any>?`     | Provider-specific config     |
-| `systemPrompt`     | `string?`                  | Custom system prompt         |
-| `mcpServers`       | `Record<string, any>?`     | MCP server configurations    |
-
-### Nested: RuntimeInfo
-
-| Field              | Type                       | Description                    |
-| ------------------ | -------------------------- | ------------------------------ |
-| `provider`         | `string`                   | Active provider                |
-| `sessionId`        | `string?`                  | Active session ID              |
-| `model`            | `string?`                  | Active model                   |
-| `thinkingOptionId` | `string?`                  | Active thinking option         |
-| `modeId`           | `string?`                  | Active mode                    |
-| `extra`            | `Record<string, unknown>?` | Provider-specific runtime data |
-
-### Nested: PersistenceHandle
-
-| Field          | Type                   | Description                                                           |
-| -------------- | ---------------------- | --------------------------------------------------------------------- |
-| `provider`     | `string`               | Provider that owns the session                                        |
-| `sessionId`    | `string`               | Session ID for resumption                                             |
-| `nativeHandle` | `any?`                 | Provider-specific handle (Codex thread ID, Claude resume token, etc.) |
-| `metadata`     | `Record<string, any>?` | Extra metadata                                                        |
-
-### Nested: AgentFeature (discriminated union on `type`)
-
-**Toggle:**
-
-| Field         | Type       |
-| ------------- | ---------- |
-| `type`        | `"toggle"` |
-| `id`          | `string`   |
-| `label`       | `string`   |
-| `description` | `string?`  |
-| `tooltip`     | `string?`  |
-| `icon`        | `string?`  |
-| `value`       | `boolean`  |
-
-**Select:**
-
-| Field         | Type                  |
-| ------------- | --------------------- |
-| `type`        | `"select"`            |
-| `id`          | `string`              |
-| `label`       | `string`              |
-| `description` | `string?`             |
-| `tooltip`     | `string?`             |
-| `icon`        | `string?`             |
-| `value`       | `string \| null`      |
-| `options`     | `AgentSelectOption[]` |
-
----
-
-## Runtime-only Terminal Sessions
-
-Terminals are live daemon state, not persisted JSON records. A terminal carries a `workspaceId` while it is running; workspace-scoped terminal lists include only terminals with the matching `workspaceId`. Legacy live terminals without an owner remain visible to unscoped terminal reads but contribute to no workspace status.
-
-Terminal activity contributes to the workspace status bucket **per `workspaceId`**: a working terminal drives `running` onto the workspace it carries only. Same-`cwd` siblings are untouched; terminal visibility is likewise `workspaceId`-scoped.
-
----
-
-## 2. Daemon Configuration
-
-**Path:** `$PASEO_HOME/config.json`
-
-Single file, validated with `PersistedConfigSchema`.
-
-`agents.skills.selection` is the daemon host's orchestration-skill preference. Missing means
-`{ mode: "all" }`. Installed state is not persisted; the daemon derives it from the shared
-`~/.agents/skills` and Claude skill directories and keeps config plus filesystem convergence behind
-one serialized owner. Codex discovers the shared directory. Updates retire unchanged files from
-Paseo-managed copies in `~/.codex/skills`, preserving user edits and untracked files.
-
-`paseo reload` reads and validates this file once inside the daemon. That snapshot drives resolution,
-classification, application, and reload bookkeeping. `DaemonConfigStore` owns applying runtime-safe
-fields and their removal/default semantics; session handlers and the CLI only relay the structured
-result. Normal config patches persist only the requested fields, so launch overrides and resolved
-defaults never leak into the file. Startup-only fields remain compared with the daemon's launch
-snapshot so a mixed edit can apply its live subset and still name the paths that require restart.
-
-```
-{
-  version: 1,
-  daemon: {
-    listen: "127.0.0.1:6767",
-    hostnames: true | string[],   // legacy alias `allowedHosts` is migrated on load
-    trustedProxies: true | string[], // defaults to ["loopback"]; Express proxy names/CIDRs
-    mcp: { enabled: boolean, injectIntoAgents: boolean },
-    git: { maxProcessesPerSecond: number, maxProcessConcurrency: number },
-    appendSystemPrompt: string,    // appended to supported provider system/developer prompts
-    terminalProfiles: TerminalProfile[],  // named shell commands; omitted means DEFAULT_TERMINAL_PROFILES
-    agentProfiles: AgentProfile[],        // named agent launch bundles; omitted means none
-    cors: { allowedOrigins: string[] },
-    relay: { enabled: boolean, endpoint: string, publicEndpoint: string, useTls: boolean, publicUseTls: boolean }, // new homes materialize enabled: false
-    auth: { password: string }    // bcrypt hash, optional
-  },
-  app: {
-    baseUrl: string
-  },
-  worktrees?: {
-    root?: string            // optional root for new worktrees; defaults to $PASEO_HOME/worktrees
-    servicePorts?: {         // optional dynamic service port allocation policy
-      range?: string         // inclusive range, e.g. "3000-4000"
-      portScript?: string    // executable that receives service/workspace context and prints one TCP port
-    }
-  },
-  providers: {
-    openai: {
-      apiKey?: string,
-      baseUrl?: string,
-      stt?: { apiKey?: string, baseUrl?: string },
-      tts?: { apiKey?: string, baseUrl?: string }
-    },
-    local: { modelsDir: string }
-  },
-  agents: {
-    skills?: {
-      selection?: { mode: "all" } | { mode: "custom", skills: string[] }
-    },
-    // ProviderOverrideSchema; legacy entries with `command: { mode, ... }` are migrated to the
-    // current shape on load via `migrateProviderSettings`. Custom provider IDs must declare
-    // `extends` (one of the built-ins or `"acp"`) and `label`. See `provider-launch-config.ts`.
-    providers: Record<providerId, ProviderOverride>,
-    metadataGeneration: {
-      providers: [{ provider, model?, thinkingOptionId? }]
-    }
-  },
-  pluginsEnabled: boolean,
-  plugins: Record<pluginId, { source: "directory", path: string, enabled?: boolean }>,
-  features: {
-    dictation: { enabled, stt: { provider, model, language, confidenceThreshold } },
-    voiceMode: { enabled, llm, stt: { provider, model, language }, turnDetection, tts: { provider, model, voice, speakerId, speed } }
-  },
-  log: {
-    level, format,
-    console: { level, format },
-    file: { level, path, rotate: { maxSize, maxFiles } }
-  }
-}
-```
-
-All fields are optional with sensible defaults.
-
-Managed plugins appear as directory sources in `config.json`; it owns the active path and enabled
-state. `plugins/sources.json` is written atomically and stores only managed kind and the Git acquisition
-remote. Installed revision, package/subdirectory identity and ownership root come from retained
-artifacts and the fixed managed layout; [managed source ownership](plugins.md#managed-source-ownership)
-explains their authority. An update prepares a new directory before replacing the active path and
-removing the previous version. Old record fields are accepted at the store boundary and ignored;
-there is no startup migration or persistent update policy.
-
-### Profile lists
-
-`terminalProfiles` and `agentProfiles` are both whole-list fields: a config patch replaces the
-array, never merges entries, so a client sends the complete next list on every add, edit, reorder
-and remove. List order is the display order.
-
-Absent and empty mean different things for terminal profiles — omitting the key falls back to
-`DEFAULT_TERMINAL_PROFILES`, while `[]` means the user removed them all. Agent profiles have no
-defaults, so both mean none.
-
-`PersistedConfigSchema` parses strictly, so a daemon that predates a field drops it on write
-rather than storing something it cannot describe. That is why the client gates the agent profiles
-UI on `server_info.features.agentProfiles` instead of letting a save appear to succeed against an
-older daemon.
-
-### Agent provider Paseo tools
-
-`agents.providers` is keyed by the exact provider ID used to launch the agent. The built-in IDs are
-`claude`, `codex`, `copilot`, `opencode`, `pi`, and `omp`. Custom provider IDs are their literal
-configuration keys, such as `my-claude` or `zai`, not the provider named by `extends`.
-
-Each entry may include a Paseo-tool policy:
-
-```json
-{
-  "agents": {
-    "providers": {
-      "my-claude": {
-        "extends": "claude",
-        "label": "My Claude",
-        "paseoTools": {
-          "enabled": true,
-          "disabledTools": ["browser_evaluate"]
-        }
-      }
-    }
-  }
-}
-```
-
-Absent `paseoTools`, or absent fields within it, means Paseo tools are enabled and all tools are
-allowed. `enabled: false` disables the provider's Paseo catalog; `disabledTools` lists exact tool
-IDs to omit. The policy covers the core and browser catalog, not the voice-only `speak` tool.
-Browser tools also require `daemon.browserTools.enabled` and a connected browser host.
-This policy controls the catalog presented to an agent. It is not an authorization boundary for
-agents that can access the host through a shell.
-
-`daemon.mcp.injectIntoAgents` is the global override. When it is `false`, no provider receives
-Paseo tools; otherwise the provider policy applies. Provider and global policy are resolved when a
-session is created, resumed, imported, or reloaded, so configuration changes affect the next
-session rather than an already-running one.
-
-`agents.metadataGeneration.providers` controls the preferred structured-generation fallback order for daemon-side metadata tasks such as commit messages, PR text, branch names, and generated agent titles. Entries are tried first in the configured order, then Paseo falls through to dynamically discovered defaults and finally the current selection when available.
-
-### Git process limits
-
-Git process limits are global to one daemon. The start-rate limit defaults to `64` processes per
-second, and the concurrency limit defaults to `8`:
-
-```json
-{
-  "daemon": {
-    "git": {
-      "maxProcessesPerSecond": 64,
-      "maxProcessConcurrency": 8
-    }
-  }
-}
-```
-
-`maxProcessesPerSecond` limits Git process starts in any one-second interval. The allowance can
-start as a burst; it does not wait for earlier processes to exit. `maxProcessConcurrency` limits
-the number of Git processes that have started but not exited. Every Git command uses both limits,
-including initial workspace reads, filesystem-triggered refreshes, background checks, and explicit
-requests.
-
-Environment variables override `config.json`:
-
-| Environment variable                 | Setting                  |
-| ------------------------------------ | ------------------------ |
-| `PASEO_GIT_MAX_PROCESSES_PER_SECOND` | `maxProcessesPerSecond`  |
-| `PASEO_GIT_MAX_PROCESS_CONCURRENCY`  | `maxProcessConcurrency`  |
-| `PASEO_GIT_CONCURRENCY`              | Legacy concurrency alias |
-
-`PASEO_GIT_MAX_PROCESS_CONCURRENCY` wins when it and the legacy alias are both set. Run `paseo reload`
-after changing `config.json`. Environment changes require a daemon restart; the launch environment
-remains authoritative during reload.
-
-`agents.metadataGeneration.providers` controls the preferred structured-generation fallback order for daemon-side metadata tasks such as commit messages, PR text, branch names, and generated agent titles. Entries are tried first in the configured order, then Paseo falls through to dynamically discovered defaults and finally the current selection when available.
-
-Local speech model ids are intentionally narrow: STT uses `parakeet-tdt-0.6b-v2-int8`, TTS uses `kokoro-en-v0_19`, and turn detection uses the bundled Silero VAD model.
-
-Set these to select OpenAI instead of local speech:
-
-| Env var                        | Applies to                      |
-| ------------------------------ | ------------------------------- |
-| `PASEO_VOICE_STT_PROVIDER`     | Voice mode STT provider         |
-| `PASEO_DICTATION_STT_PROVIDER` | Composer dictation STT provider |
-| `PASEO_VOICE_TTS_PROVIDER`     | Voice mode TTS provider         |
-
-OpenAI speech can be configured under `providers.openai`. STT and TTS resolve independently, so they can point at different endpoints:
-
-```json
-{
-  "providers": {
-    "openai": {
-      "stt": {
-        "apiKey": "sk-...",
-        "baseUrl": "https://stt.example.com/v1"
-      },
-      "tts": {
-        "apiKey": "sk-...",
-        "baseUrl": "https://api.openai.com/v1"
-      }
-    }
-  }
-}
-```
-
-`providers.openai.stt` is used for both composer dictation and voice mode speech-to-text; `providers.openai.tts` is used for voice mode text-to-speech. The equivalent env vars are `OPENAI_STT_API_KEY`/`OPENAI_STT_BASE_URL` and `OPENAI_TTS_API_KEY`/`OPENAI_TTS_BASE_URL`. Each feature falls back to `providers.openai.apiKey`/`providers.openai.baseUrl`, then `OPENAI_API_KEY`/`OPENAI_BASE_URL`, when its own fields are unset. These settings apply only to Paseo OpenAI speech features, not to Codex or other OpenAI-backed tools.
-
-Paseo uses these paths under the configured OpenAI base URL:
-
-- dictation STT: `/v1/audio/transcriptions`
-- voice mode STT: `/v1/audio/transcriptions`
-- voice mode TTS: `/v1/audio/speech`
-
----
-
-## 3. Schedule
-
-**Path:** `$PASEO_HOME/schedules/{id}.json`
-
-One file per schedule. ID is 8 hex characters.
-
-| Field       | Type                                  | Description                      |
-| ----------- | ------------------------------------- | -------------------------------- |
-| `id`        | `string`                              | 8-char hex ID                    |
-| `name`      | `string?`                             | Human-readable name              |
-| `prompt`    | `string`                              | The prompt to send               |
-| `cadence`   | `ScheduleCadence`                     | Timing (see below)               |
-| `target`    | `ScheduleTarget`                      | What to run (see below)          |
-| `status`    | `"active" \| "paused" \| "completed"` | Current state                    |
-| `createdAt` | `string` (ISO 8601)                   |                                  |
-| `updatedAt` | `string` (ISO 8601)                   |                                  |
-| `nextRunAt` | `string?` (ISO 8601)                  | Next scheduled execution         |
-| `lastRunAt` | `string?` (ISO 8601)                  | Last execution time              |
-| `pausedAt`  | `string?` (ISO 8601)                  | When paused                      |
-| `expiresAt` | `string?` (ISO 8601)                  | Auto-expire time                 |
-| `maxRuns`   | `number?`                             | Max executions before completing |
-| `runs`      | `ScheduleRun[]`                       | Execution history                |
-
-### Nested: ScheduleCadence (discriminated union on `type`)
-
-- `{ type: "cron", expression: string, timezone?: string }` — canonical cadence for new writes; absent `timezone` means UTC
-- `{ type: "every", everyMs: number }` — legacy rolling interval, still readable and executable during the compatibility window
-
-### Nested: ScheduleTarget (discriminated union on `type`)
-
-- `{ type: "agent", agentId: string }` — send to existing agent
-- `{ type: "new-agent", config: { provider, cwd, modeId?, model?, thinkingOptionId?, title?, providerOptions?, featureValues?, systemPrompt?, mcpServers? } }` — create a new agent
-
-### Nested: ScheduleRun
-
-| Field          | Type                                   | Description             |
-| -------------- | -------------------------------------- | ----------------------- |
-| `id`           | `string`                               | Run ID                  |
-| `scheduledFor` | `string` (ISO 8601)                    | Intended execution time |
-| `startedAt`    | `string` (ISO 8601)                    |                         |
-| `endedAt`      | `string?` (ISO 8601)                   |                         |
-| `status`       | `"running" \| "succeeded" \| "failed"` |                         |
-| `agentId`      | `string?` (UUID)                       | Agent used for this run |
-| `output`       | `string?`                              | Agent output text       |
-| `error`        | `string?`                              | Error message if failed |
-
----
-
-## 4. Project Registry
-
-**Path:** `$PASEO_HOME/projects/projects.json`
-
-Array of project records.
-
-| Field                | Type                        | Description                                                                                                                                |
-| -------------------- | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
-| `projectId`          | `string`                    | Host-local primary key; new records use opaque `prj_<16 hex>` IDs                                                                          |
-| `projectKey`         | `string \| null`            | Persisted opaque cross-host grouping key; reconciliation backfills absent values                                                           |
-| `rootPath`           | `string`                    | Exact lexically normalized selected root; never realpathed                                                                                 |
-| `kind`               | `"git" \| "non_git"`        | Mutable Git observation about `rootPath`, never a membership key                                                                           |
-| `displayName`        | `string`                    | Selected-root basename, stable across remote and Git changes                                                                               |
-| `customName`         | `string \| null`            | User-set override layered over `displayName`. Null means "use the derived name".                                                           |
-| `customIconRevision` | `string \| null`            | Identifies the host-local custom icon stored under `projects/icons/`. Null means the icon is discovered by scanning the project directory. |
-| `createdAt`          | `string` (ISO 8601)         |                                                                                                                                            |
-| `updatedAt`          | `string` (ISO 8601)         |                                                                                                                                            |
-| `archivedAt`         | `string \| null` (ISO 8601) | Soft-delete timestamp; required nullable                                                                                                   |
-
-Uploading a file and pasting a website or image URL are two ways of _acquiring_ the same custom
-icon. The client fetches URL imports and sends their bytes through the upload RPC. The daemon never
-receives or fetches the URL; it validates the uploaded bytes, stores them, and records a new
-`customIconRevision`. Going back to automatic deletes the stored image, as does removing the
-project.
-
-Active exact roots are idempotent using lexical platform-equivalence semantics. Existing legacy
-remote-shaped and path-shaped IDs remain readable, including duplicate roots; reconciliation never
-merges them, transfers names, archives them, or moves workspace foreign keys. An explicit
-workspace `projectId` is authoritative when it names an active project, regardless of cwd
-containment. Archived-only exact-root records are not resurrected by explicit add/open; a fresh
-opaque project is allocated instead. Agent restore is separate and restores the agent's existing
-workspace together with its owning project.
-
----
-
-## 5. Workspace Registry
-
-**Path:** `$PASEO_HOME/projects/workspaces.json`
-
-Array of workspace records. A workspace is a specific working directory within a project.
-
-| Field                          | Type                                                         | Description                                                                                                                                                                                   |
-| ------------------------------ | ------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `workspaceId`                  | `string`                                                     | Opaque stable identifier (`wks_<hex>`), generated independently of the directory. MUST NOT be treated as a path; compare by exact equality. Use the `cwd` field for directory access.         |
-| `projectId`                    | `string`                                                     | FK to Project.projectId; the workspace's stable project membership                                                                                                                            |
-| `cwd`                          | `string`                                                     | Exact execution directory selected for agents, files, scripts, and setup                                                                                                                      |
-| `kind`                         | `"local_checkout" \| "worktree" \| "directory"`              | Mutable checkout classification                                                                                                                                                               |
-| `displayName`                  | `string`                                                     | The human name (the generated/derived title). Decoupled from `branch` by construction.                                                                                                        |
-| `title`                        | `string \| null`                                             | User-set name override layered over `displayName`. Null means "use `displayName`".                                                                                                            |
-| `branch`                       | `string \| null`                                             | The current Git branch for git-backed workspaces. Separate from `displayName`/`title`; a background branch refresh never rewrites the name.                                                   |
-| `worktreeRoot`                 | `string \| null`                                             | Backing checkout/worktree root. May differ from `cwd` for exact subprojects and remains persisted after the worktree is deleted so restore can reproduce the placement.                       |
-| `baseBranch`                   | `string \| null`                                             | Comparison base retained across archive and restore. Branch-off creation stores the resolved ref; legacy and PR-checkout records hold a bare name. Null means no recorded base.               |
-| `isPaseoOwnedWorktree`         | `boolean`                                                    | Whether Paseo owns and may remove/recreate the backing `worktreeRoot`                                                                                                                         |
-| `mainRepoRoot`                 | `string \| null`                                             | Main repository root for worktree checkouts, independent of both exact `cwd` and backing `worktreeRoot`                                                                                       |
-| `createdAt`                    | `string` (ISO 8601)                                          |                                                                                                                                                                                               |
-| `updatedAt`                    | `string` (ISO 8601)                                          |                                                                                                                                                                                               |
-| `archivedAt`                   | `string \| null` (ISO 8601)                                  | Soft-delete; required nullable                                                                                                                                                                |
-| `autoArchivedChangeRequestUrl` | `string \| null`                                             | Change request whose merged state triggered auto-archive. Restore replaces it with the current merged change request, when present, so repeated snapshots cannot archive the workspace again. |
-| `labels`                       | `string[]?`                                                  | Normalized display names assigned from this host's shared label catalog. Missing means unlabelled.                                                                                            |
-| `pinnedAt`                     | `string \| null` (ISO 8601)                                  | Pinned-to-top-of-sidebar timestamp; null means "not pinned"                                                                                                                                   |
-| `untrustedSource`              | `{ kind: "change_request", forge, number, headRepository }?` | Provenance captured when a cross-repository change request creates the workspace. Missing means repository automation is allowed; explicit setup removes the field.                           |
-
-> **Opaque-ID invariant:** `workspaceId` is opaque identity, never a filesystem path. Filesystem and git operations take `cwd`/`workspaceDirectory` only — never the id. A compatibility-only first-materialization bootstrap still groups pre-registry agent records by path and Git remote so existing installs retain their legacy records. That grouping never runs against a live registry, and its keys are not runtime project or workspace identity.
-
-### Workspace label catalog
-
-**Path:** `$PASEO_HOME/projects/workspace-labels.json`
-
-The catalog is shared by every workspace on one host. A definition contains a display name and one
-of the ten identity colour names (`WORKSPACE_LABEL_COLORS` in
-`packages/protocol/src/workspace-labels.ts`); trimmed, collapsed, case-insensitive name identity is
-unique within that file. Definitions have no portable ID or principal owner and remain after their
-last assignment. Editing a label takes a new name, a new colour, or both in one commit, so the two
-fields cannot land half-applied. Workspaces store label names, so a rename and a delete rewrite
-workspace assignments through one serialized compound commit while a recolour is catalog-only; a
-rename onto a name the host already has is refused rather than merged. A prepared
-`workspace-labels.transaction.json` contains both before and after images. The daemon writes the
-catalog and workspace files, then atomically changes the transaction to committed; that phase
-change is the durable commit point. Recovery rolls prepared transactions back before either
-directory is served. A committed marker proves both data files were already written, so recovery
-only loads the current catalog and retries marker cleanup; it never reapplies stale workspace
-after-images over later registry mutations. A request rejected before the commit point therefore
-cannot take effect after restart. If the live daemon cannot determine or restore the durable state,
-the workspace registry freezes every write and later label mutations fail with
-`workspace_label_storage_uncertain` until daemon restart performs recovery. Reads remain available,
-but may reflect the last acknowledged cache until restart. Workspace directory and catalog updates
-publish only after the commit point; publication failure does not roll durable state back.
-
-`projectId` is still a real FK: workspace records should have a matching project record. Read-only
-history surfaces tolerate transient orphaned workspaces by omitting those rows so one bad FK cannot
-blank the whole History screen, but mutation paths should repair or remove the orphaned state rather
-than treating it as valid.
-
----
-
-## 6. Push Token Store
-
-**Path:** `$PASEO_HOME/push-tokens.json`
-
-```json
-{
-  "tokens": ["ExponentPushToken[...]", ...]
-}
-```
-
-Simple set of Expo push notification tokens. Loaded with permissive parsing (filters non-string entries). Persisted with atomic temp-file rename.
-
----
-
-## 7. Daemon meta files
-
-These small files are not validated as full Zod schemas but are persisted under `$PASEO_HOME` for daemon identity and runtime coordination.
-
-| Path                  | Format                                                         | Notes                                                                             |
-| --------------------- | -------------------------------------------------------------- | --------------------------------------------------------------------------------- |
-| `server-id`           | Plain text, e.g. `srv_<base64url>`                             | Stable per-`$PASEO_HOME` daemon ID. Overridable via `PASEO_SERVER_ID` env.        |
-| `daemon-keypair.json` | `{ v: 2, publicKeyB64, secretKeyB64 }` (libsodium box keypair) | E2EE relay identity. Written with mode `0600`. Regenerated if file is unreadable. |
-| `paseo.pid`           | JSON `{ pid, startedAt, ... }`                                 | PID lock; prevents two daemons sharing one `$PASEO_HOME`.                         |
-| `local-credential`    | 32 random bytes encoded as base64url text                      | Rotated before each listen and deleted on shutdown; mode `0600`.                  |
-| `daemon.log`          | Pino log output                                                | Default location; path/rotation configurable via `log.file` in `config.json`.     |
-
----
-
-## Client-side stores (App)
-
-These live in React Native `AsyncStorage` or browser `IndexedDB`, not on the daemon filesystem.
-
-### Keying convention: directory-backed vs workspace-owned
-
-Right-sidebar client state splits on whether it is determined by the directory or owned by the workspace (two workspaces can share one `cwd`). The split is enforced by the cache key, so changing a key changes the sharing semantics — see [architecture.md](architecture.md#right-sidebar-boundary-directory-backed-vs-workspace-owned) for the full table.
-
-- **Directory-backed** (shared by same-`cwd` workspaces): keyed by `(serverId, cwd)`. Git status/diff, GitHub PR status, PR timeline, file preview content. These are TanStack Query caches, not persisted stores.
-- **Workspace-owned** (independent per workspace): keyed by `workspaceId`, with `cwd` used only as a fallback when no `workspaceId` is present. Review draft comments (`@paseo:review-draft-store`), diff-mode overrides (in-memory), workspace composer attachments, and file-explorer nav/expand state. The `workspaceId` part of these keys is **opaque** — never parse it back into a path.
-
-### Replica row store
-
-The durable client replica uses IndexedDB on browser/Electron and expo-sqlite on native. Rows use the
-compound key `(serverId, kind, id)`; kinds are `agent`, `workspace`, `project`, `timeline`, and
-`checkpoint`. Directory entities have individual rows, timelines use the agent id, and the checkpoint
-uses the singleton id.
-
-The store is a typed persistence boundary. It returns values to directory and timeline owners and
-accepts their explicit commits; it never reads or writes UI state. Reads are scoped to the requested
-host, kinds, and ids. Opening a cached workspace uses exact workspace and project keys rather than a
-directory scan. One invalid row is deleted and returned as a miss without affecting other rows.
-An invalid directory row and its affected checkpoint cursor are repaired in one transaction, so a
-later launch cannot accept a checkpoint for a partial baseline. Directory changes and their
-checkpoint are also applied in one transaction.
-
-The cache is capped at 32 MiB and evicts whole hosts in least-recently-written order. Budget
-bookkeeping may scan opaque row sizes during a deferred write, never during host registry startup or
-before a requested cache row can paint. The row store is not encrypted. A cached timeline can contain
-source code, prompts, and tool output; encrypted-at-rest storage is a separate security decision.
-
-### Draft Store
-
-**AsyncStorage key:** `paseo-drafts` (version 2)
-
-```typescript
-{
-  drafts: Record<draftKey, {
-    input: { text: string, images: AttachmentMetadata[] },
-    lifecycle: "active" | "abandoned" | "sent",
-    updatedAt: number,     // epoch ms
-    version: number        // optimistic concurrency
-  }>,
-  createModalDraft: DraftRecord | null
-}
-```
-
-### Attachment Store (Web)
-
-**IndexedDB database:** `paseo-attachment-bytes`, object store: `attachments`
-
-Stores binary attachment blobs keyed by attachment ID.
-
-### AttachmentMetadata
-
-| Field         | Type      | Description                    |
-| ------------- | --------- | ------------------------------ |
-| `id`          | `string`  | Unique attachment ID           |
-| `mimeType`    | `string`  | MIME type                      |
-| `storageType` | `string`  | Storage backend identifier     |
-| `storageKey`  | `string`  | Key within the storage backend |
-| `createdAt`   | `number`  | Epoch ms                       |
-| `fileName`    | `string?` | Original filename              |
-| `byteSize`    | `number?` | Size in bytes                  |

docs/design.md

@@ -1,290 +0,0 @@
-# Design
-
-Tokens — every color, font size, weight, spacing step, radius, icon size — live in `packages/app/src/styles/theme.ts`.
-
----
-
-## 1. Character
-
-Paseo is minimal, spacious, quiet, confident. Whitespace is deliberate. Nothing crowds, nothing decorates, nothing apologizes. A row, a label, a control. That is the bar.
-
-The app is calm so the user's work is not. Every visual decision serves either _act on this_ or _understand this_ — never _look at this_.
-
-Consistency comes from component reuse, not from hand-matching styles across surfaces. A row in the projects list, a row in settings, and a row in a modal are the same component, not three implementations that happen to look alike. When two surfaces do the same semantic thing in two different ways, one of them is wrong.
-
----
-
-## 2. Component reuse
-
-A semantic element used in three or more places is a primitive. One of a kind is a screen.
-
-Primitives live in `packages/app/src/components/ui/` and `packages/app/src/components/headers/`. Card and row layout live in `packages/app/src/styles/settings.ts`. Section structure lives in `packages/app/src/screens/settings/settings-section.tsx`.
-
-A pressable styled to look like a button is wrong; the button is `<Button>` (`packages/app/src/components/ui/button.tsx`). A bare `<Text>` styled to look like a section header is wrong; the section header is `<SettingsSection>` (`packages/app/src/screens/settings/settings-section.tsx`). A custom `Modal` for a confirmation is wrong; the confirmation is `confirmDialog` (`packages/app/src/utils/confirm-dialog.ts`). A hand-rolled overflow menu is wrong; the menu is `<DropdownMenu>` (`packages/app/src/components/ui/dropdown-menu.tsx`). A hand-rolled status pill is wrong; the pill is `<StatusBadge>` (`packages/app/src/components/ui/status-badge.tsx`). A circle pinned over a scrolling surface is wrong; the floating action is `<FloatingActionButton>` (`packages/app/src/components/ui/floating-action-button.tsx`), one per surface, and the surface reserves `FLOATING_ACTION_BUTTON_CLEARANCE` below its content so the button never traps the last row.
-
-Before adding a new component, read `components/ui/`. The primitive usually exists.
-
----
-
-## 3. Hierarchy
-
-Hierarchy is conveyed through weight and color, not size. Most interface text is `fontSize.base`; compact metadata and hints use `fontSize.sm`. The distinction between a row's primary line and its secondary line is `foreground` versus `foregroundMuted`.
-
-The authored interface ramp uses a 14px base. New native installs default to 15px; web and desktop default to 14px. The Appearance **Interface size** setting is the rendered `fontSize.base` value and scales the rest of the UI ramp proportionally. Primary readable content has its own `fontSize.content`, which defaults to 16px on native and 15px on web and desktop. It owns message bodies, composer input, Markdown, and PR prose. Controls, navigation, metadata, tool chrome, code, diffs, editors, and terminals stay on their interface or code tokens. **Code size** remains independent.
-
-Weight has three tiers, applied by role:
-
-- **Screen titles** — the title in app chrome — use `<ScreenTitle>` (`packages/app/src/components/headers/screen-title.tsx`), which renders `fontSize.base` at weight `400` on compact and `300` on desktop. The New workspace hero is the only larger product title; it uses `fontSize["2xl"]` (`packages/app/src/screens/new-workspace-screen.tsx`).
-- **Structural labels** use `fontWeight.medium`. This applies to section labels above a stack of rows (`packages/app/src/components/agent-list.tsx:519-523`, `packages/app/src/components/keyboard-shortcuts-dialog.tsx:63-67`), form field labels above an input inside a modal (`packages/app/src/components/add-host-modal.tsx:19-23`, `packages/app/src/components/pair-link-modal.tsx:24-28`), the title at the top of a modal/sheet/dialog (`packages/app/src/components/adaptive-modal-sheet.tsx:90-94`, `packages/app/src/components/ui/combobox.tsx:1607-1611`, `packages/app/src/components/welcome-screen.tsx:48-53`), action button labels in tight components such as the sidebar callout actions (`packages/app/src/components/sidebar-callout.tsx:218-221`), and inline data emphasis on dense metadata rows (`packages/app/src/components/git-diff-pane.tsx:2322-2327`, `packages/app/src/components/file-explorer-pane.tsx:1115-1122`).
-- **Content** uses `fontWeight.normal`. This applies to settings rows (`packages/app/src/styles/settings.ts`), sidebar primary list-item titles (`packages/app/src/components/sidebar-workspace-list.tsx:2680-2686`, `packages/app/src/components/agent-list.tsx:572-578`), `<Button>` text (`packages/app/src/components/ui/button.tsx:80-84`), `<StatusBadge>` text (`packages/app/src/components/ui/status-badge.tsx:56-60`), and `<SidebarCallout>` titles (`packages/app/src/components/sidebar-callout.tsx:175-180`).
-
-The rule, condensed: text that _names_ a surface or a group is `medium`. Text that lives _inside_ a surface or a group is `normal`. Top-of-screen titles are `<ScreenTitle>`, which is lighter still.
-
-Foreground is for the thing being acted on: row titles, section headings, the selected sidebar item. `foregroundMuted` is for context: hints, descriptions, secondary metadata, idle sidebar items, placeholders, status text.
-
-`foregroundExtraMuted` is reserved for passive chrome that must sit behind muted text, such as an always-visible window control. Use the solid token instead of lowering SVG opacity; per-path opacity makes overlapping icon strokes render unevenly. Interactive hover and pressed states return to `foreground`.
-
-Accent is the one CTA per surface. A `<Button variant="default">` filled with `accent` appears at most once on a page. Most pages have zero — settings is mostly toggles and text, the workspace pane is mostly content, the chat composer is the input itself.
-
-Destructive is a color, not a click. Restart-daemon and remove-host are `<Button variant="outline">` in the row trailing slot; the destructive surface only appears inside the `confirmDialog` (`packages/app/src/screens/settings/host-page.tsx:541-547`). Workspace archive opens a confirm dialog before any red appears (`packages/app/src/components/sidebar-workspace-list.tsx`). Red appears after the user has indicated intent.
-
----
-
-## 4. Buttons
-
-The button is `<Button>` (`packages/app/src/components/ui/button.tsx`). It has five variants. Each has one job.
-
-`default` is the one primary action on a surface — filled with `accent`. At most one per page. The primary slot inside an `<AdaptiveModalSheet>` and the highlighted action on the welcome screen are the canonical uses.
-
-`secondary` is the paired action when two actions carry equal weight — filled with `surface3`. The component default is `secondary`, which matches its frequency in the codebase.
-
-`outline` is the low-frequency action that lives on a row — transparent with `borderAccent`. Restart, Remove, Update on host detail (`packages/app/src/screens/settings/host-page.tsx:585-594`).
-
-`ghost` is structural and non-committal — no border, no fill. Back arrows, header toggles, "Load more" footers (`packages/app/src/screens/sessions-screen.tsx:54-63`), more-affordances. Ghost is used when the affordance is part of the chrome, not a decision.
-
-Header and toolbar controls use `interactionHighlight` for hovered, pressed, open, and selected
-backgrounds. It is a translucent semantic fill so the same control works over the main surface and
-the sidebar. Apply it as `backgroundColor`; setting `opacity` on the control also fades its content.
-
-`destructive` is filled with `destructive`. It only appears inside a confirm. The button on the page is `outline`; the destructive button is the confirm button inside the dialog.
-
-Sizes: `xs` for ultra-tight inline triggers. `sm` for any button sitting in a row. `md` is the page default. `lg` is reserved for large standalone CTAs.
-
-Sizes are a shared contract across control kinds, defined once in `control-geometry.ts`: `xs` = 28px tall with `fontSize.sm` labels, `sm` = 32px with `fontSize.base`, `md`/`lg` = 44px with `fontSize.base`. `<SegmentedControl>` (`packages/app/src/components/ui/segmented-control.tsx`) takes the same `xs`/`sm`/`md` sizes — a segmented control next to a `<Button>` of the same size always matches in height, label size, and corner radius. Its segments run one padding step tighter than a button, because the gap between segments already reads as padding. The selected segment is a `surface3` fill with `foreground` text, not an inverted one — inverting it inside thin chrome puts a white slab in the toolbar. Thin chrome such as the file toolbar uses `xs`; settings rows use `sm`. Never shrink a control's font or padding locally to fit a context — if the context needs a smaller control, the size tier is missing or the wrong one is in use.
-
-A `<Pressable>` wrapping a `<Text>` is a sixth variant. It is wrong. `<Button>` accepts `style`, `textStyle`, `leftIcon`, `disabled`, `size`, and `variant`.
-
----
-
-## 5. Borders
-
-Borders group, separate, or rarely emphasize.
-
-A logical block of related rows lives inside a card — one border around the whole group. The card primitive is `settingsStyles.card`; the keyboard-shortcuts dialog uses the same shape inline (`packages/app/src/components/keyboard-shortcuts-dialog.tsx:68-73`). The border defines what belongs together.
-
-Rows after the first inside a card carry `settingsStyles.rowBorder` — a single top border. The first row never has one. The same divider pattern appears in the keyboard-shortcuts dialog rows (`packages/app/src/components/keyboard-shortcuts-dialog.tsx:74-83`). Rows do not need their own background to feel separated.
-
-A list that is itself the page content — sidebar items in `sidebar-workspace-list.tsx`, the workspace list, the agent list (`packages/app/src/components/agent-list.tsx`) — uses spacing and surface, not borders, to separate items. Rows-in-a-card is an interior pattern; lists-as-pages are not.
-
-Pane chrome — the workspace pane header, the file-explorer header, the diff pane header — uses a single bottom border to separate the header from the content (`packages/app/src/components/git-diff-pane.tsx:2328-2331`). One border, no shadow.
-
-`borderAccent` is reserved for the outline button. Inputs use `border`. Single-thing borders are wrong; a single bordered element is either a card with one row (use the card) or it does not need a border.
-
----
-
-## 6. Pickers
-
-Five primitives. The pick is determined by option count, the need to search, and how the picker is anchored.
-
-`<DropdownMenu>` is for a small fixed set anchored to a trigger. Theme picker, kebab menus on workspace and project rows (`packages/app/src/components/sidebar-workspace-list.tsx:684-770`), row "more" menus. Items can be async (`status: "pending"`) and can include destructive entries. Under ~10 options where the user knows what they're looking for.
-
-`<Combobox>` is for a large or searchable list. Host switcher in the sidebar footer, model selector in the composer, branch switcher in the workspace header (`packages/app/src/components/branch-switcher.tsx`). The user types to find the option, or the list is long enough to scroll.
-
-`<ContextMenu>` is for right-click and long-press on a target. The row is the trigger; there is no visible affordance. Used for incidental actions on workspace rows in the sidebar (`packages/app/src/components/sidebar-workspace-list.tsx`).
-
-`<AdaptiveModalSheet>` is for a focused task. Multi-field forms (`packages/app/src/components/add-host-modal.tsx`, `packages/app/src/components/pair-link-modal.tsx`, `packages/app/src/components/project-picker-modal.tsx`), confirmations with detail, anything that earns a backdrop. Bottom sheet on compact, centered card on desktop. Raw `Modal` is wrong for any of these.
-
-`<AdaptiveModalSheet>` owns the presentation. Its content inset — the gutter that puts sheet content on the same rails as the sheet header — and compact bottom safe-area padding are the sheet's, not the caller's. A caller declares layout intent through `contentStyle` and never branches on form factor to add its own margins. If a sheet's first snap point is shorter than its header, content, and safe-area clearance, raise that snap point rather than moving the sheet container.
-
-`confirmDialog` is for destructive yes/no and imperative confirmation. Promise-based: `await confirmDialog({ destructive: true, ... })`. Anything where a wrong click loses work.
-
-Three themes is `DropdownMenu`. Thirty hosts is `Combobox`. A label and a value is `AdaptiveModalSheet`. "Are you sure?" is `confirmDialog`.
-
----
-
-## 7. Density and rhythm
-
-Settings detail pages, the projects detail page, and any list+detail content sit inside a centered, max-width 720 column (`packages/app/src/screens/settings-screen.tsx`, `packages/app/src/screens/projects-screen.tsx`). Lines stay readable, the eye does not have to track wide horizontal distances. Form modals carry their own narrower content frame (`packages/app/src/components/add-host-modal.tsx`).
-
-Workspace and chat surfaces use the full width — these are working surfaces, not reading surfaces. The composer carries `MAX_CONTENT_WIDTH` from `packages/app/src/constants/layout.ts` to keep lines readable while letting the workspace pane fill the rest.
-
-Sections sit apart. `<SettingsSection>` owns its own bottom margin; the next thing is wrapped in another `<SettingsSection>`. The agent-list `sectionHeading` carries the same `marginTop`/`marginBottom` rhythm (`packages/app/src/components/agent-list.tsx:511-517`). Adding `marginBottom` to a section is wrong.
-
-A section or group explains itself through the `info` prop on `<SettingsSection>` or `<SettingsGroup>` — an info icon beside the header that opens a tooltip (`packages/app/src/components/settings/headings/settings-info-tip.tsx`). A muted paragraph between the header and the card is wrong: it sits in the section's own gap, so it reads as a second heading rather than as prose belonging to the header. Explanatory copy that describes one row belongs to that row, as `settingsStyles.rowHint` inside the card.
-
-Cards inside a section sit closer than sections. Rows inside a card touch — only the divider separates them. The rhythm is page → spacious; section → spacious; card → tight.
-
-Rows have generous vertical padding: roughly 16px of content plus 16px of vertical padding for settings rows, 8–12px for sidebar list items where many rows must fit. Compressing rows below the established density to fit more on the screen is wrong. Too many rows means more cards or more sections, not smaller rows.
-
-The whitespace is the design.
-
----
-
-## 8. Alignment
-
-Things align to their glyphs, not to their boxes. A row's leading icon, its title, and the label of the button in its trailing slot sit on the same rails — the ink lines up, not the padding, not the touch target, not the hover background.
-
-Pick the rails from the content, then hold them. A settings card establishes a leading rail at the icon's left edge and a trailing rail at the last glyph's right edge; every row in that card uses the same two. A row whose icon is absent still starts its title on the leading rail. Indentation is a new rail, not an arbitrary offset.
-
-The pressable is bigger than the glyph, and that is fine. Hit areas grow outward from the aligned content — they never move it. A button that looks two pixels off because its padding is asymmetric is misaligned even though its box is correct.
-
-Optical alignment beats arithmetic when a glyph disagrees with its bounding box. Icons with visual weight on one side, chevrons, and single-character labels usually need a small nudge to look centered. Trust the eye, then leave a comment saying the offset is optical.
-
-One row off the rail makes the whole card look unconsidered.
-
----
-
-## 9. Responsiveness
-
-Compact-first. The small case is designed; the large case adds chrome around it.
-
-The list+detail pattern is canonical and reused across surfaces. The settings shell (`packages/app/src/screens/settings-screen.tsx`) and the projects screen (`packages/app/src/screens/projects-screen.tsx`) implement it identically:
-
-- On compact: full-screen list with `<BackHeader>` at the top. Tapping a row pushes a full-screen detail with its own `<BackHeader>` that returns to the list.
-- On desktop: a 320px sidebar on the left holds the list with `surfaceSidebar` background. The content pane on the right holds the selected detail with `<ScreenHeader>`, `<HeaderIconBadge>`, and `<ScreenTitle>`.
-
-The branching is one `useIsCompactFormFactor()` check at the top of the screen component. The list and the detail are the same components in both layouts; only the framing changes.
-
-The workspace screen (`packages/app/src/screens/workspace/workspace-screen.tsx`) follows a different but parallel rule: tabs collapse on compact, panes split on desktop. The sidebar (`packages/app/src/components/left-sidebar.tsx`) is overlaid on compact and pinned on desktop.
-
-On a narrow desktop route, app navigation yields to the rendered content topology when the remaining width cannot preserve its center target: Settings keeps its 320px list + 400px detail split, and a workspace Explorer keeps its current visible width plus a 400px center pane. That is a topology decision at the app container, not a second compact breakpoint. Temporary width clamps are render-only; widening restores the user's saved sidebar widths.
-
-Electron window controls are top-corner obstructions, not a compact-layout condition. Rendered surfaces declare which top corners they physically occupy; only those corners receive clearance. Full-window overlays redeclare both corners. A focused split pane owns both corners; if focus restoration temporarily exposes the full split tree, the split boundary reserves one top strip instead of assigning a control rectangle to an arbitrarily narrow leaf. The 720px desktop breakpoint preserves the default 320px sidebar and target 400px center width when the Explorer is closed; it is product policy, not an obstruction gate.
-
-Windows and Linux controls are fixed window chrome, outside scrolling header content. A tab rail that reaches them ends at their obstruction and shows the shared overflow fade. On macOS, the Explorer toggle occupies a fixed top-right window slot so opening and closing Explorer does not move the pointer target.
-
-A new list+detail feature copies the settings shell. A new workspace-shaped feature copies the workspace shell. Inventing a third shape happens in design review, not in a PR.
-
----
-
-## 10. Copy and voice
-
-Sentence case. "Pair a device", "Danger zone", "Restart daemon", "Inject Paseo tools", "No sessions yet", "Load more". Proper nouns retain casing — Paseo, Beta, Stable, Local. Title case is wrong.
-
-No trailing periods on row titles, labels, or buttons. No trailing period on a single-clause hint: "What happens when you press Enter while the agent is running" (`packages/app/src/screens/settings-screen.tsx:271-272`). Periods exist inside multi-sentence prose: "Restarts the daemon process. The app will reconnect automatically."
-
-Empty-state strings are short noun phrases or short sentences: "No projects yet", "Select a project", "No sessions yet" (`packages/app/src/screens/sessions-screen.tsx:74-76`), "Host not found".
-
-Buttons are imperative: Save, Cancel, Restart, Remove, Update, Install update, Add host, Load more. In-flight labels are present-participle with a literal three-dot ellipsis: "Saving...", "Restarting...", "Removing...", "Loading...".
-
-Error copy is direct. "Unable to remove host" (`packages/app/src/screens/settings/host-page.tsx:697`), not "Sorry, we couldn't remove the host." Recovery instructions are concrete: "Wait for it to come online before restarting." Errors describe state; they do not editorialize.
-
-Terminology:
-
-- Workspace, never "checkout".
-- Host, except where the user-facing concept is the daemon process itself ("Restart daemon").
-- Project, not "repo" or "repository".
-- Provider, not "model provider".
-- Session and agent are distinct: a session is a historical entry in `sessions-screen.tsx`; an agent is a live entity in the workspace.
-
----
-
-## 11. States
-
-Loading is inline by default. `<LoadingSpinner size={14} color={foregroundMuted} />` sits next to the thing it relates to (`packages/app/src/screens/settings/providers-section.tsx:227-231`). Page-level loading is a centered `<LoadingSpinner size="large">` (`packages/app/src/screens/sessions-screen.tsx:69-72`). Card-level loading is a single short line, not a spinner. In-row dropdown items use `<DropdownMenuItem status="pending" pendingLabel="Removing...">`; the menu item handles its own pending state.
-
-Screen-level empty states use a centered, muted noun phrase and at most one ghost button (`packages/app/src/screens/sessions-screen.tsx`). Sidebar list empty states use a quiet bordered card with a left-aligned `sm` title, a muted `sm` description, and `xs` `<Button>` actions. Use `secondary` for the primary action and `outline` for a secondary action (`packages/app/src/components/sidebar/empty-states.tsx`). Keep both forms short and free of illustrations.
-
-Inline errors are a single sentence in `palette.red[300]` `xs`, sitting under the field or inside the card it relates to (`packages/app/src/screens/settings/providers-section.tsx:115-119`).
-
-Page-level alerts — informational notices, success confirmations, warnings, or recoverable errors that need a small visible block on the page — use `<Alert>` (`packages/app/src/components/ui/alert.tsx`). Variants: `default`, `info`, `success`, `warning`, `error`. The chrome is quiet by design: a 1px tinted border, transparent background, a small variant-tinted icon, the title in the variant accent, the description in `foregroundMuted`. Actions go in the `children` slot as `<Button variant="outline" size="sm">` — recovery actions are low-frequency and outline keeps them quiet alongside the alert's accent (`packages/app/src/screens/project-settings-screen.tsx`). One `<Alert>` at a time per region.
-
-Sidebar callouts — cross-cutting alerts that apply across the whole app, like worktree setup, Rosetta install, and desktop update available — register through `useSidebarCallouts()` and render in the left sidebar via `<SidebarCallout>` (`packages/app/src/components/sidebar-callout.tsx`). The chrome (top-border-only, full-width action buttons) is tuned for that ~280px column. Canonical sources: `packages/app/src/components/worktree-setup-callout-source.tsx`, `packages/app/src/desktop/updates/rosetta-callout-source.tsx`, `packages/app/src/desktop/updates/update-callout-source.tsx`. Never import `<SidebarCallout>` into a page — that's what `<Alert>` is for.
-
-Imperative errors are `Alert.alert("Error", "Unable to ...")` (the React Native `Alert` API, not this component) for failures that interrupt the flow and have no place on the page.
-
-Disabled state is `opacity: theme.opacity[50]` on the outer pressable. Color changes for disabled state are wrong; a disabled button is the same button, dimmer.
-
-Partial failure (a list mostly fine but one source errored) is a bordered banner above the list, listing each failure in red-300 `xs` (`packages/app/src/screens/projects-screen.tsx:151-159`). The list still renders.
-
-State surfaces at the smallest scope it affects. Field error stays under the field; page error is a banner; flow-stopping error is an `Alert`.
-
-Changing state must not move the layout. A row that grows when its badge arrives, a card that reflows when a count resolves, a list that jumps as data streams in — all wrong. Reserve the space the loaded state will need, so the skeleton, the spinner, and the content occupy the same box. A surface that shifts under the user stops feeling calm.
-
----
-
-## 12. List rows
-
-The row anatomy is a content column with an optional trailing slot. Inside a card the row is `settingsStyles.row`. Inside a sidebar list the row carries its own padding and `borderRadius.lg` per item (`packages/app/src/components/sidebar-workspace-list.tsx:2614-2625`).
-
-Rows that drill into a detail lead with a chevron in the trailing slot (`ChevronRight`, `iconSize.sm`, `foregroundMuted`). The whole row is the `<Pressable>`. Pair-device row (`packages/app/src/screens/settings/host-page.tsx:644-668`), provider row (`packages/app/src/screens/settings/providers-section.tsx:92-132`), project row in the projects list. A fixed right chevron means navigation. An expandable row uses a trailing right chevron that rotates down when expanded (`SettingsCollapsibleRow`); pressing the row reveals its child rows in place.
-
-Kebab menus (`<DropdownMenu>` with `<MoreVertical size={14} />` trigger) are for actions on the row, not navigation. Trigger style: `padding: 2`, `borderRadius: 4`, hover background `surface2`. Menu position: `align="end"`. Items use `<DropdownMenuItem leading={<Icon size={14} color={foregroundMuted} />} ...>`. Visibility is `isHovered || isTouchPlatform` — hover-revealed on web, always visible on native (`packages/app/src/components/sidebar-workspace-list.tsx:684-770`).
-
-A row may carry both a chevron and a kebab when both navigation and row-level actions apply. Chevron sits at the end; kebab sits before it.
-
-Switches and segmented controls also sit in the trailing slot. A row that both navigates and toggles is a `<Pressable>` with a `<Switch>` in the trailing slot — the switch calls `event.stopPropagation()` so the row press does not fire (`packages/app/src/screens/settings/providers-section.tsx:92-132`). Sidebar items that hold a status dot, a count, and a kebab follow the same rule (`packages/app/src/components/sidebar-workspace-list.tsx`).
-
-Selected state on rows in a desktop list+detail uses `surfaceSidebarHover` as the background (`packages/app/src/screens/projects-screen.tsx`). Selected state on rows in the sidebar list uses `surface2` (`packages/app/src/components/agent-list.tsx:563-571`).
-
----
-
-## 13. Status pills and badges
-
-There is exactly one token per status signal — `statusSuccess`, `statusDanger`, `statusWarning`, `statusMerged` — and every status surface uses it: PR state icons, CI check icons and pies, diff stats, file-change icons, status pills, usage bars. A surface does not get a quieter or louder variant because of where it sits. If a dense list feels loud, that is a density or weight problem; fix the density, not the color. The tokens are generated, not hand-picked — see the rule in `packages/app/src/styles/theme.ts` and regenerate rather than nudging one value. The level is set by the densest consumer, the sidebar workspace list.
-
-Status **dots** are the one exception, and they are a family of their own — `statusDotSuccess`, `statusDotDanger`, `statusDotWarning`, `statusDotRunning`, read only by `getStatusDotColor` (`packages/app/src/utils/status-dot-color.ts`). Same hues and the same generation rule, but their own band: 90% of gamut chroma against the status family's 55–60%. A dot is a few points of solid color with no shape to read and no label attached, and the running one pulses, so at the status band's chroma the dots read dimmer than the metadata beside them — backwards, since the dot is the row's state. Lightness is set by hue separation rather than by distance from the surface: at 6pt four dark hues on a light surface all read as one dark blob no matter how much contrast they have. So the light band runs as bright as the contrast floor allows at L=0.62, the last step where all four clear 3:1 against the sidebar's `surface2`; the dark band sits at L=0.72, where danger turns pink above. All four move together; regenerate the set, never one hue.
-
-Status pills use the status token for text on the shared `surface3` and `border` shell. The neutral shell keeps the signal legible without manufacturing translucent colors outside the theme. The `<StatusBadge>` primitive (`packages/app/src/components/ui/status-badge.tsx`) is canonical; a pill never reaches into `palette`.
-
-Status dots — the small filled circles next to a host or agent name — are `borderRadius.full` filled with the status token. Which token a given agent state maps to is owned by `getStatusDotColor` (`packages/app/src/utils/status-dot-color.ts`); a row, a group header, and a project icon all call it rather than restating the mapping. They sit in the trailing slot of a sidebar row or as a leading marker on a status pill.
-
-Identity badges — the project icon, the sidebar host badge, and the PR-panel participant avatar — do not use the theme palette. They draw from the fixed ten-color identity table in `packages/app/src/styles/identity-colors.ts`, whose hexes are held to one contrast band so a color identifies rather than ranks. Project icons and PR avatars use it as a fill with a white letter — that is `identityColor`, one theme-independent hex per identity. Host badges use it as a _foreground_ on both the glyph and the label, which is a different contrast problem that the fill table cannot solve: no single hex clears 4.5:1 against both a near-white and a dark sidebar. Foregrounds therefore come from `identityForeground(name, colorScheme)`, one set per scheme, hue unchanged. That set is generated on the **status family's** lightness and chroma fraction, because a meta row puts a host badge beside a CI check and a diff stat, and two families at different lightness make the brighter one shout. Change the status band and this one changes with it. A host with no color assigned falls back to `foregroundMuted`. The table is theme-independent by design; do not fork it per theme, and do not add hexes to it without recomputing the band.
-
-New status pills use `<StatusBadge>`. Identity, shortcut, and interactive link badges remain separate because color does not encode status there.
-
----
-
-## 14. Forbidden
-
-- `fontWeight.medium` on row titles, body text, button labels, badge text, or `<SidebarCallout>` titles. Medium is reserved for the structural-label tier described in §3 — section labels, modal/sheet titles, dense metadata emphasis, and tight action labels. Anything else is `normal`. `<ScreenTitle>` is responsive `400/300` and is never overridden.
-- `<Pressable>` wrapping `<Text>` to make a button. `<Button>` exists.
-- Bare `<Text>` for a section header inside settings. `<SettingsSection>` exists.
-- A muted paragraph between a section header and its card. Section-level explanation is the header's `info` tooltip (§7).
-- A "Settings" CTA on a detail page. Detail pages are settings; settings is reached from the sidebar, the host entry, or a row's kebab menu.
-- The word "checkout" in UI strings or identifiers. The term is "workspace".
-- New color tokens or hardcoded hex outside the palette. The identity color table is the documented exception (§13), not a license.
-- Placeholder text dimmed beyond `foregroundMuted`. No extra opacity, no italics, no ghost-text.
-- `onPointerEnter` and `onPointerLeave`. They do not fire on native iOS. Hover uses Pressable's `onHoverIn`/`onHoverOut` gated with `isHovered || isCompact || isNative`.
-- Raw DOM APIs without an `isWeb` guard.
-- Spacing values outside the scale. `padding: 20` and `gap: 10` are wrong.
-- Color changes for disabled state. Opacity only.
-- Destructive actions without `confirmDialog`. Restart, remove, and future destructive actions are confirmed. Archive workspace is confirmed only when its worktree backing reports uncommitted changes or unpushed commits; otherwise it archives immediately.
-- Bespoke status pills. `<StatusBadge>` is the pill primitive.
-- Raw `Modal` for a focused task. `<AdaptiveModalSheet>` is the modal primitive.
-- Importing `ActivityIndicator` directly. `<LoadingSpinner>` is the loading primitive.
-
----
-
-## 15. Canonical surfaces by pattern
-
-| Pattern                                             | Reference                                                                                                                                                                                                                                                                                                |
-| --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| List+detail (compact stack, desktop sidebar+pane)   | `packages/app/src/screens/settings-screen.tsx`, `packages/app/src/screens/projects-screen.tsx`                                                                                                                                                                                                           |
-| Detail card+row                                     | `packages/app/src/screens/settings/host-page.tsx`, `packages/app/src/screens/settings/providers-section.tsx`                                                                                                                                                                                             |
-| Section grouping inside a card list                 | `packages/app/src/screens/settings/settings-section.tsx`                                                                                                                                                                                                                                                 |
-| Form modal (label + input fields, primary + cancel) | `packages/app/src/components/add-host-modal.tsx`, `packages/app/src/components/pair-link-modal.tsx`, `packages/app/src/components/project-picker-modal.tsx`                                                                                                                                              |
-| Destructive confirmation                            | `confirmDialog` invoked from `packages/app/src/screens/settings/host-page.tsx:541-547`                                                                                                                                                                                                                   |
-| Centered hero / first-run                           | `packages/app/src/components/welcome-screen.tsx`                                                                                                                                                                                                                                                         |
-| Sidebar list (workspaces, hosts)                    | `packages/app/src/components/sidebar-workspace-list.tsx`, `packages/app/src/components/left-sidebar.tsx`                                                                                                                                                                                                 |
-| Live list of items with sections (agents)           | `packages/app/src/components/agent-list.tsx`                                                                                                                                                                                                                                                             |
-| Historical list (sessions)                          | `packages/app/src/screens/sessions-screen.tsx`                                                                                                                                                                                                                                                           |
-| Workspace pane (multi-tab, split)                   | `packages/app/src/screens/workspace/workspace-screen.tsx`                                                                                                                                                                                                                                                |
-| Composer / message input                            | `packages/app/src/components/composer.tsx`, `packages/app/src/components/message-input.tsx`                                                                                                                                                                                                              |
-| Pane chrome with single bottom border               | `packages/app/src/components/git-diff-pane.tsx`, `packages/app/src/components/file-explorer-pane.tsx`, `packages/app/src/components/terminal-pane.tsx`                                                                                                                                                   |
-| Page-level alert (info / success / warning / error) | `packages/app/src/components/ui/alert.tsx`, `packages/app/src/screens/project-settings-screen.tsx`                                                                                                                                                                                                       |
-| Sidebar callout (cross-cutting alert)               | `packages/app/src/components/sidebar-callout.tsx`, `packages/app/src/contexts/sidebar-callout-context.tsx`, `packages/app/src/components/worktree-setup-callout-source.tsx`, `packages/app/src/desktop/updates/rosetta-callout-source.tsx`, `packages/app/src/desktop/updates/update-callout-source.tsx` |
-| Searchable picker                                   | `packages/app/src/components/ui/combobox.tsx`, `packages/app/src/components/branch-switcher.tsx`                                                                                                                                                                                                         |
-| Trigger-anchored menu                               | `packages/app/src/components/ui/dropdown-menu.tsx` (used in `sidebar-workspace-list.tsx`, theme picker)                                                                                                                                                                                                  |
-| Right-click / long-press menu                       | `packages/app/src/components/ui/context-menu.tsx` (used in `sidebar-workspace-list.tsx`)                                                                                                                                                                                                                 |
-| Headers (back, screen, menu)                        | `packages/app/src/components/headers/back-header.tsx`, `screen-header.tsx`, `menu-header.tsx`                                                                                                                                                                                                            |

docs/development.md

@@ -1,647 +0,0 @@
-# Development
-
-## Prerequisites
-
-- Node.js (see `.tool-versions` for exact version)
-- npm workspaces (comes with Node)
-
-## Running the dev server
-
-```bash
-npm run dev:server
-npm run dev:app
-npm run dev:desktop
-```
-
-Root checkout dev is intentionally split across terminals:
-
-- `npm run dev:server` runs the daemon on `127.0.0.1:6768`.
-- `npm run dev:app` runs Expo on `http://localhost:8081` and connects to the dev daemon.
-- `npm run dev:desktop` runs its own Electron-flavored Expo server on the first free port from `8082` through `8089`. It never claims port `8081`.
-
-Desktop dev launches its desktop-managed daemon with `PASEO_NODE_ENV=development`,
-so development-only providers such as Mock Load Test are available. Packaged
-desktop launches always force the daemon to production mode.
-
-The web and desktop dev launchers pass the current Git branch to Metro as
-`EXPO_PUBLIC_PASEO_DEV_BUILD_LABEL`. The expanded desktop sidebar shows it in
-the titlebar row. Production builds leave the variable unset and show no label.
-
-`npm run dev` is only a shorthand for `npm run dev:server`. Keep `127.0.0.1:6767` for the packaged app and production-style `~/.paseo` state.
-
-## Nix desktop package
-
-The flake exposes `packages.<system>.desktop` on Linux and macOS:
-
-```bash
-nix build .#desktop
-```
-
-Linux produces the `paseo-desktop` launcher and desktop entry. macOS produces
-`Applications/Paseo.app` plus the `paseo-desktop` launcher. Both use the nixpkgs
-Electron runtime and the checkout's built daemon, client, and renderer rather
-than downloading a published desktop release.
-
-### PASEO_HOME
-
-`PASEO_HOME` is the directory that holds runtime state (agents, worktrees, workspace config, sockets, daemon log). Resolution rules:
-
-- The **server itself** (e.g. when launched by the desktop app or `npm run start`) defaults to `~/.paseo` (see `packages/server/src/server/paseo-home.ts`).
-- **Repo dev scripts** default to `$ROOT/.dev/paseo-home`, where `$ROOT` is the current checkout or worktree root. This keeps all dev state scoped to the checkout instead of the packaged desktop app.
-- **`npm run cli -- ...`** runs through the same dev-home wrapper as the dev scripts, so the in-repo CLI automatically targets the current checkout's `.dev/paseo-home` and configured dev daemon endpoint.
-- **Paseo-created worktrees** seed `$PASEO_WORKTREE_PATH/.dev/paseo-home` from `$PASEO_SOURCE_CHECKOUT_PATH/.dev/paseo-home` by copying durable JSON metadata. Runtime files like pid files, sockets, and logs are not copied.
-- **This repo's worktree setup** also best-effort seeds `packages/app/ios` and the newest `.dev/ios-build` entry from the source checkout so iOS simulator services can reuse native project and Xcode cache state when it is safe enough to do so.
-
-Override knobs:
-
-```bash
-PASEO_HOME=~/.paseo-blue npm run dev          # explicit home
-PASEO_DEV_SEED_HOME=/path/to/home npm run dev # seed from a different source home
-PASEO_DEV_RESET_HOME=1 npm run dev            # clear and reseed the derived worktree home
-```
-
-### Daemon endpoints
-
-- Stable daemon launched by the desktop app: `localhost:6767`.
-- Root checkout dev daemon: `localhost:6768`.
-- Root checkout Expo: `http://localhost:8081`.
-- Root checkout desktop dev Expo: first free port from `8082` through `8089`.
-- `npm run dev` (Windows): `localhost:6767` for the daemon.
-
-In Paseo-managed worktree services, use the injected service environment rather than hardcoded root checkout ports.
-
-### Expo Router
-
-Route ownership, startup restore, and native blank-screen gotchas live in
-[expo-router.md](expo-router.md). Read it before changing `packages/app/src/app`,
-startup routing, remembered workspace restore, or active workspace selection.
-
-### iOS simulator preview service
-
-Paseo worktrees expose the native iOS dev app through the `ios-simulator` service in `paseo.json`. The service URL serves the simulator preview at `/.sim`, so the preview link is `${PASEO_URL}/.sim`.
-
-**Prerequisites (macOS only).** The service shells out to the Apple toolchain, so beyond the `npm ci` that worktree setup runs you must install:
-
-- **Xcode** (the full app, not just the Command Line Tools) — install it from the Mac App Store, or from `developer.apple.com/download` for a specific version. It provides `xcodebuild` and `xcrun simctl`; accept its license and let first-run component installation finish before starting the service.
-- **An iOS Simulator runtime with at least one iPhone device type**. Recent Xcode versions may not bundle a runtime — add one via Xcode → Settings → Components (older Xcode: "Platforms"). The service targets `iPhone 16 Pro` by default (override with `PASEO_IOS_DEVICE_TYPE`) and falls back to any iPhone; it fails with `No iPhone simulator device type is installed` when none exist.
-- **Homebrew** — CocoaPods itself installs automatically: `expo prebuild` runs `pod install` on a cold worktree, and when the CocoaPods CLI is missing the runner installs it for you. It tries `gem install cocoapods` first and falls back to Homebrew (`brew install cocoapods`), so having Homebrew available lets that fallback succeed without a manual step.
-
-`serve-sim`, Expo, and Metro come from `npm ci`, and CocoaPods installs itself on the first prebuild as described above.
-
-The service is designed for concurrent worktrees: it derives a deterministic simulator identity from the worktree path, uses the worktree's assigned `PASEO_PORT`, pins `serve-sim` to that simulator UDID, and only tears down that worktree's helper/simulator state. It must not rely on the globally booted simulator or any fixed Metro port.
-
-Worktree setup best-effort seeds the generated iOS project and newest native build cache from the source checkout before the service runs. The service still validates the native project by running Expo prebuild and Xcode; the seed only avoids paying all setup/build cost from a cold worktree every time.
-
-Starting the service must not create, focus, reveal, or leave behind macOS Simulator.app windows — a guard hides Simulator.app every 250ms, so the native window vanishes if you focus it. The user-visible surface is the interactive `/.sim` preview: a `serve-sim` stream (60 FPS MJPEG + a WebSocket control channel) that Metro mounts at `basePath: "/.sim"` (`packages/app/metro.config.cjs`) and that forwards taps and gestures, so first-launch prompts like "Open in PaseoDebug?" are answered there, not in the native window. Open the `${PASEO_URL}/.sim` link the service prints — not `serve-sim`'s raw stream port (`:3100`), which is view-only. Because the stream sits behind the daemon proxy it is convenient for remote viewing but laggy up close; for fast local dev at the Mac, use the native simulator path below.
-
-**Troubleshooting.** If `xcrun simctl` fails with `unable to find utility "simctl"`, the active developer directory is still the Command Line Tools even though Xcode is installed. Point it at Xcode: `sudo xcode-select -s /Applications/Xcode.app/Contents/Developer`, then confirm with `xcrun --find simctl`.
-
-### Running the iOS app on a local simulator
-
-For fast, native, interactive iOS dev at the Mac — as opposed to the remote `/.sim` preview above — skip the service and build the dev client directly:
-
-```bash
-npm run ios        # → expo run:ios (packages/app): builds and launches the app in the real Simulator.app
-```
-
-`expo run:ios` starts its own Metro and gives you the normal Simulator.app window (full speed, native touch, no stream).
-
-**Pointing the app at a daemon.** The client resolves its local daemon from `EXPO_PUBLIC_LOCAL_DAEMON` (`packages/app/src/runtime/host-runtime.ts`); when unset it falls back to `localhost:6767`, the production `~/.paseo` daemon. To target a worktree's dev daemon instead, set it on the build command:
-
-```bash
-EXPO_PUBLIC_LOCAL_DAEMON=localhost:${PASEO_SERVICE_DAEMON_PORT} npm run ios   # worktree daemon running as a Paseo service
-EXPO_PUBLIC_LOCAL_DAEMON=localhost:6768 npm run ios                          # standalone `npm run dev:server`
-```
-
-The iOS simulator shares the Mac's loopback, so `localhost:<port>` reaches the host daemon directly.
-
-**Gotcha — `EXPO_PUBLIC_*` is inlined into the JS bundle at Metro bundle time, not read at runtime.** Set it in the same shell that starts Metro. If the app still connects to the old daemon, Metro served a cached bundle; re-bundle clean with `cd packages/app && EXPO_PUBLIC_LOCAL_DAEMON=… npx expo start -c` and reload the app.
-
-### Desktop renderer profiling
-
-`npm run dev:desktop` starts Electron with Chromium remote debugging enabled so
-renderer CPU profiles can be captured through CDP. By default it passes
-`--remote-debugging-port=0`, so Chromium atomically asks the OS for an available
-port and prints the selected DevTools endpoint. Set
-`PASEO_ELECTRON_REMOTE_DEBUGGING_PORT` when a QA workflow requires a validated,
-fixed port.
-
-Desktop dev also scopes Electron `userData` to the current dev root. This prevents
-desktop-only environment inherited by terminals opened inside Paseo from coupling
-a new worktree instance to the parent desktop instance's profile or single-instance
-lock.
-
-The desktop workspace script `exec`s the dev runner so the terminal owns the runner
-PID. Terminal shutdown reaches the runner as `SIGHUP`; the runner stops Metro and
-asks Electron to quit through its normal app lifecycle. Do not add an npm wrapper or
-detach Electron: either change leaves an orphan holding the worktree's single-instance
-lock and broken output pipes.
-
-With desktop dev running, verify the real BrowserWindow, titlebar clearance, fullscreen
-transition, and 751-pixel settings split with:
-
-```bash
-npm run verify:electron-cdp --workspace=@getpaseo/desktop
-```
-
-The verifier reads the same `EXPO_PORT` and
-`PASEO_ELECTRON_REMOTE_DEBUGGING_PORT` environment names as desktop dev. Set an
-explicit remote-debugging port for verifier runs, and set both when testing an
-isolated instance on non-default ports.
-
-When running a dedicated Electron QA instance against a non-default Expo port, set
-`EXPO_DEV_URL` explicitly. Desktop main defaults to `http://localhost:8081`, so
-`PASEO_PORT=57928` alone starts Metro on 57928 but Electron still loads 8081.
-
-### React render profiling
-
-The app has a gated React render profiler in
-`packages/app/src/utils/render-profiler.tsx`. Wrap the component boundary you want
-to measure with `RenderProfile`, then open the app with `?renderProfile=1`. When
-the query param is absent, `RenderProfile` returns children directly and records
-nothing.
-
-Captured samples are exposed on `globalThis.__PASEO_RENDER_PROFILE__`. Call
-`globalThis.__PASEO_RESET_RENDER_PROFILE__?.()` after warm-up and before the
-interaction you want to measure. If a memo comparator or subscription boundary
-needs explanation, call `recordRenderProfileReasons(id, reasons)` while profiling;
-reason counts are exposed on `globalThis.__PASEO_RENDER_PROFILE_REASONS__`.
-
-Use this workflow for any render investigation:
-
-1. Add stable `RenderProfile` boundaries around the suspected root and expensive
-   children. Keep IDs specific enough to compare before and after.
-2. Reproduce against real app state, not toy fixtures, whenever practical.
-3. Record an idle baseline first. If idle is noisy, fix or account for that
-   before optimizing the interaction.
-4. Warm up the route, reset profiler samples, run the exact interaction, then
-   compare `actualDuration`, render counts, and per-commit samples.
-5. When a memo boundary still renders, record reasons before changing code. Do
-   not guess from object identity alone.
-6. Keep changes that move the measured profile. Remove probes or memo wrappers
-   that do not move the number.
-
-What this caught during the workspace tab investigation:
-
-- A large apparent workspace cost was real interaction work, not daemon noise;
-  the idle baseline stayed near zero.
-- The expensive stream rerender was mostly prop identity churn from pane context
-  callbacks and capability objects, not new stream data.
-- Stabilizing provider actions at the pane boundary helped because every mounted
-  panel consumes that context.
-- Comparing value-shaped capability flags beat preserving object identity through
-  unrelated stores.
-- Some plausible fixes did not pay off: memoizing the tab row and composer draft
-  object barely moved the profile, so they were removed.
-
-Existing scenario script: workspace agent/terminal tab switching. Start Expo on
-web, keep a daemon available, then run:
-
-```bash
-PASEO_PROFILE_SERVER_ID=<server-id> \
-PASEO_PROFILE_WORKSPACE_ID=<workspace-path> \
-PASEO_PROFILE_AGENT_ID=<agent-id> \
-  npm run profile:workspace-tabs --workspace=@getpaseo/app
-```
-
-This script opens the app with `?renderProfile=1`, creates a temporary terminal
-tab, switches between a real agent and that terminal, prints aggregated React
-Profiler timings, then removes the temporary terminal. It is an example of the
-workflow above, not the only way to use the profiler. Useful knobs:
-
-```bash
-PASEO_PROFILE_APP_URL=http://localhost:19010 # Expo web URL
-PASEO_PROFILE_SWITCH_COUNT=1                # number of agent/terminal switch pairs
-PASEO_PROFILE_SWITCH_WAIT_MS=250            # delay after each click
-PASEO_PROFILE_IDLE_WAIT_MS=3000             # idle baseline before switching
-PASEO_PROFILE_DUMP_COMMITS=1                # include per-commit profiler samples
-```
-
-For warm workspace switching, point the benchmark at an app backed by seeded
-daemon state:
-
-```bash
-PASEO_PROFILE_APP_URL=http://localhost:19010 \
-  npm run profile:workspace-switching --workspace=@getpaseo/app
-```
-
-The benchmark first warms `Cmd+1` through `Cmd+7`, then records a rapid seven-workspace
-burst. It separately warms the three-entry workspace deck LRU and records `Cmd+1` through
-`Cmd+3` without waits between keys. Both scenarios report keydown-to-activation latency and
-React commits on the same browser clock. Set `PASEO_PROFILE_WORKSPACE_DIGITS`,
-`PASEO_PROFILE_WORKSPACE_LRU_SIZE`, or `PASEO_PROFILE_WARM_QUIET_MS` to change the shape. Set
-`PASEO_PROFILE_DUMP_COMMITS=1` to include the nested component breakdown for every commit.
-Set `PASEO_PROFILE_RETAINED_REPEATS=5` to repeat the retained-LRU burst for a less noisy sample.
-Set `PASEO_PROFILE_CPU_PATH=/tmp/workspace-switch.cpuprofile` to run a separate retained-LRU
-capture after the latency scenarios and write a raw CDP CPU profile without contaminating their
-timings.
-Set `PASEO_PROFILE_TRACE_PATH=/tmp/workspace-switch.trace.json` to run another separate retained-LRU
-capture and write a Chromium Performance trace with User Timing marks and screenshots. Open the
-trace in the Chrome DevTools Performance panel. Set `PASEO_PROFILE_TRACE_INVALIDATIONS=1` only for a
-focused invalidation capture; React Native's generated stacks make that mode highly intrusive.
-Set `PASEO_PROFILE_TRACE_FOCUS=1` to include focus targets, durations, and JavaScript call stacks in
-the scenario report. This mode wraps `HTMLElement.focus`, so use it only for diagnosis.
-
-For the desktop Explorer sidebar toggle, run the app against the root checkout's daemon and use:
-
-```bash
-npm run profile:explorer-toggle --workspace=@getpaseo/app
-```
-
-The harness verifies port `6768`, opens the Paseo workspace, creates and warms the Explorer pane,
-records an idle control, then measures settled and 50 ms burst Cmd+E toggles. It reports
-input-to-DOM and input-to-paint latency, React commits, mounts, unmounts, and DOM mutations. Set
-`PASEO_PROFILE_TRACE_PATH=/tmp/explorer-toggle.trace.json` or
-`PASEO_PROFILE_CPU_PATH=/tmp/explorer-toggle.cpuprofile` for separate Chromium captures. Override
-the app URL, daemon port, workspace, or server with the corresponding `PASEO_PROFILE_*` variables.
-
-For sustained composer typing, run the paired composer-versus-textarea benchmark against a seeded
-daemon:
-
-```bash
-PASEO_PROFILE_APP_URL=http://localhost:19010 \
-  npm run profile:composer-typing --workspace=@getpaseo/app
-```
-
-The benchmark opens the first workspace, preserves its existing draft, and dispatches 300 printable
-keys at a fixed 16 ms cadence without waiting for each key to paint. It measures renderer
-`keydown` to the next paint opportunity, verifies that every character survived, alternates the
-composer and plain-textarea control across three runs, then restores the original draft. The report
-includes percentiles, frame coalescing, input processing, React work, long tasks, slow samples, and
-Playwright dispatch lateness. Set `PASEO_PROFILE_TYPING_KEYS`, `PASEO_PROFILE_TYPING_CADENCE_MS`,
-`PASEO_PROFILE_TYPING_REPEATS`, or `PASEO_PROFILE_WORKSPACE_DIGIT` to change the scenario. Optional
-`PASEO_PROFILE_CPU_PATH` and `PASEO_PROFILE_TRACE_PATH` captures run separately after the latency
-measurements so profiling overhead does not contaminate them.
-
-Set `PASEO_PROFILE_TYPING_SCENARIO=height-growth` to alternate `Shift+Enter` and printable input.
-That report includes input and composer height changes plus React work grouped into composer,
-stream, and ancestor/root scopes. Ancestor/root timings include descendant work because the Profiler
-boundaries are nested. A printable key after an empty newline should not change either height.
-
-### Preview Windows and Linux window controls on macOS
-
-Desktop development can replace native macOS traffic lights with Paseo's custom controls:
-
-```bash
-PASEO_DESKTOP_WINDOW_CONTROLS=windows npm run dev:desktop
-PASEO_DESKTOP_WINDOW_CONTROLS=linux npm run dev:desktop
-```
-
-The override is rejected in packaged builds. Restart the desktop process when changing it.
-
-### Desktop macOS compositor watchdog
-
-macOS display sleep can leave Chromium's GPU-process display link — the vsync
-source that drives frame production — stuck on a stale display. The compositor
-then stops producing frames and the window looks frozen: unresponsive to clicks
-and keys even though the renderer and every process stay alive. It self-recovers
-after a few minutes, which is too long for a foreground app.
-
-`setupDarwinCompositorWatchdog`
-(`packages/desktop/src/window/compositor-watchdog/index.ts`) guards against
-this. It polls the renderer for frame production every couple of seconds and,
-after a sustained stall while the window is visible and unlocked, restarts the
-GPU process so Chromium rebuilds the display link. The probe is skipped while
-the screen is locked or the window is hidden or minimized, since a window
-legitimately stops producing frames then.
-
-The watchdog deliberately leaves background throttling **enabled**. Calling
-`webContents.setBackgroundThrottling(false)` would keep the compositor producing
-frames non-stop, pinning ProMotion displays at 120Hz forever and draining the
-battery while the app is idle — so do not re-add it. The probe's visibility
-guards already prevent throttling from causing a false stall.
-
-### Daemon logs
-
-Check `$PASEO_HOME/daemon.log` for daemon logs. The default level is `info`; set
-`PASEO_LOG_LEVEL=trace` before launching the daemon when you need full provider,
-session, and agent-manager traces for stuck-state debugging.
-
-The supervisor rotates `daemon.log`. Persisted `log.file.rotate` settings in
-`$PASEO_HOME/config.json` win first. Without persisted config, the optional
-`PASEO_LOG_ROTATE_SIZE` and `PASEO_LOG_ROTATE_COUNT` env vars override the
-defaults. The default rotation is `10m` x `3` files everywhere.
-
-### Git process pressure
-
-If Git refreshes consume too much CPU, disk, or antivirus capacity, especially on Windows, reduce
-the daemon-global Git process limits in `$PASEO_HOME/config.json`:
-
-```json
-{
-  "daemon": {
-    "git": {
-      "maxProcessesPerSecond": 5,
-      "maxProcessConcurrency": 4
-    }
-  }
-}
-```
-
-Reload the daemon with `paseo reload`. Environment-variable overrides still require a restart because
-the launch environment remains authoritative. Lower values reduce machine pressure but make Git-backed workspace state and
-Git RPCs wait longer. See [Git process limits](data-model.md#git-process-limits) for defaults,
-semantics, and environment-variable overrides.
-
-### Agent Tool Catalog Measurement
-
-Measure the MCP `tools/list` payload that Paseo injects into agents with:
-
-```bash
-npm run measure:agent-tools --workspace=@getpaseo/server
-```
-
-The command reports compact JSON bytes, estimated tokens, field totals, largest
-tools, and the browser-tools delta. It defaults to the agent-scoped catalog; use
-`-- --scope=top-level` for the unaffiliated `/mcp/agents` shape and `-- --json`
-for machine-readable output.
-
-## Worktree starting refs
-
-A new worktree starts from the current branch's upstream, or the local branch when it has no
-upstream. This keeps unpushed local commits out of new workspaces by default. The picker collapses
-identical refs; divergent local or non-origin refs remain explicit, qualified choices.
-
-The daemon sends the exact upstream ref because the remote and branch names cannot be inferred.
-Worktrees retain that ref for comparisons and updates from base while exposing its branch name to
-the UI. Merging into base requires a mutable local target: `origin/main` maps to local `main`, while
-another remote fails closed until the worktree records an explicit local target. Older daemons omit
-the optional field and retain the previous local-first behavior; older worktree metadata without the
-exact ref also resolves through its stored branch name.
-
-Worktrees inherit committed Git state only; uncommitted source-checkout changes are not copied.
-
-## paseo.json service scripts
-
-`worktree.setup` and `worktree.teardown` accept either a multiline shell script or an array
-of commands. Both run sequentially.
-
-Lifecycle commands run in the worktree through a stable script shell: `bash`
-resolved from `PATH` on macOS/Linux, and PowerShell with `-NoProfile` on
-Windows. They inherit the daemon environment plus Paseo's lifecycle variables;
-login and interactive shell startup files are not loaded, and Bash's `BASH_ENV`
-hook is unset. ACP single-string terminal commands use the same non-login Bash
-behavior on macOS/Linux, but preserve their existing `cmd.exe /c` string semantics
-on Windows. Service scripts are separate:
-they launch in a terminal and receive the service environment described below.
-
-Because the shell differs per platform, a lifecycle command that must run
-everywhere cannot use POSIX-only syntax — `VAR=1 cmd` env prefixes, `$VAR`
-expansion, `cp`/`rm`, or a `./scripts/*.sh` entrypoint all fail under PowerShell,
-and `bash` is not guaranteed to exist on Windows. Put that logic in a Node script
-that reads what it needs from `process.env` and invoke it as
-`node ./scripts/<name>.mjs`. This repo's own setup does exactly that in
-`scripts/seed-worktree-dev-state.mjs` and `scripts/seed-ios-native-cache.mjs`.
-
-```json
-{
-  "worktree": {
-    "setup": "npm ci\ncp \"$PASEO_SOURCE_CHECKOUT_PATH/.env\" .env\nnpm run db:migrate",
-    "teardown": "npm run db:drop || true"
-  }
-}
-```
-
-Every `scripts` entry with `"type": "service"` receives these environment variables:
-
-| Variable                    | Value                                                                                                                     |
-| --------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
-| `PASEO_SERVICE_<NAME>_URL`  | Proxied URL for a declared peer service. Prefer this for peer discovery; it survives peer restarts.                       |
-| `PASEO_SERVICE_<NAME>_PORT` | Raw ephemeral port for a declared peer service. Use only as a bypass escape hatch; it can go stale if that peer restarts. |
-| `PASEO_URL`                 | Self alias for `PASEO_SERVICE_<SELF>_URL`.                                                                                |
-| `PASEO_PORT`                | Self alias for `PASEO_SERVICE_<SELF>_PORT`.                                                                               |
-| `HOST`                      | Bind host for the service process.                                                                                        |
-
-Service proxy hostnames use the double-dash shape: `web--feature-auth--project.localhost` or, on the default branch, `web--project.localhost`. Optional public aliases use the same leftmost label under the configured public base host.
-
-`<NAME>` is normalized from the script name by uppercasing it, replacing each run of non-`A-Z0-9` characters with `_`, and trimming leading or trailing `_`. For example, `app-server` and `app.server` both normalize to `APP_SERVER`; that collision fails at spawn time with an actionable error.
-
-`PORT` is not injected by default. If a framework requires `PORT`, set it in the command:
-
-```json
-{
-  "scripts": {
-    "web": {
-      "type": "service",
-      "command": "PORT=$PASEO_PORT npm run dev:web"
-    }
-  }
-}
-```
-
-Service ports use OS ephemeral allocation by default. Set `worktrees.servicePorts` in
-`$PASEO_HOME/config.json`, or replace it for one project with `worktree.servicePorts` in
-`paseo.json`. The block accepts an inclusive `range` such as `"3000-4000"` or a `portScript`
-executable. Since `portScript` is executed directly without a shell, it must point to a real executable (e.g., a binary or a script with a proper shebang like `#!/bin/sh`) rather than an inline shell command or shell pipeline. For inline shell commands or pipelines, wrap them in a small script. `portScript` runs in the workspace directory with four arguments: service name,
-workspace ID, branch name, and worktree path. A missing branch is passed as an empty string. The same
-values are available as `PASEO_SCRIPTNAME`, `PASEO_WORKSPACE_ID`, `PASEO_BRANCH_NAME`, and
-`PASEO_WORKTREE_PATH`. The script must print one valid TCP port. Paseo trusts the external allocator,
-so the port may already be bound. `portScript` takes precedence when both values are present.
-
-## Bundled daemon web UI
-
-> The user-facing guide for this feature (enabling it, reverse proxy, TLS, tunnels, security) lives at [public-docs/web-ui.md](../public-docs/web-ui.md). This section is the contributor/build reference: how the artifact is produced, bundled, and excluded from desktop packaging.
-
-The daemon can optionally serve the browser web client from the same HTTP server. This is disabled by default.
-
-Enable it in persistent configuration:
-
-```bash
-paseo daemon config set features.webUi.enabled true
-paseo daemon start
-```
-
-Or set the environment variable:
-
-```bash
-PASEO_WEB_UI_ENABLED=true paseo daemon run
-```
-
-Or persist it in `config.json`:
-
-```json
-{
-  "features": {
-    "webUi": {
-      "enabled": true
-    }
-  }
-}
-```
-
-When enabled, opening the daemon HTTP origin (for example `http://localhost:6767/`) serves the web app. The same HTTP server continues to serve `/api/*`, `/mcp/*`, `/public/*`, the WebSocket upgrade, and service-proxy routes. Static files load without daemon bearer auth; API and WebSocket calls still enforce auth.
-
-The served app auto-bootstraps a connection to the same origin, so opening `http://localhost:6767/` directly usually skips the Add Host step.
-
-Build the artifact for packaging or measurement with:
-
-```bash
-npm run build:daemon-web-ui
-```
-
-This exports the normal browser web app (not the Electron-flavored desktop renderer) and copies it into `packages/server/dist/server/web-ui`, precompressing `.html`, `.js`, `.css`, and JSON assets as `.br` and `.gz`.
-
-Measured bundle size for a standard Expo web export:
-
-- raw: 10.77 MiB
-- gzip: 2.55 MiB
-- brotli: 1.93 MiB
-
-The desktop-managed daemon disables the bundled web UI by default (`PASEO_WEB_UI_ENABLED=false`) because the desktop app already ships the renderer as `app-dist`. Shipping the same assets again inside `@getpaseo/server` would duplicate the ~10.8 MiB install. Desktop packaging also excludes `node_modules/@getpaseo/server/dist/server/web-ui/**` from the packaged app.
-
-## Built workspace packages
-
-Package imports resolve through package exports to compiled `dist/` output, not sibling `src/` files. This is true in local dev and in published packages: the app, daemon, CLI, and SDK consumers should all exercise the same runtime paths.
-
-`npm run dev:server` builds the server-side workspace packages once, then keeps `@getpaseo/protocol` and `@getpaseo/client` fresh with TypeScript watch builds while the daemon runs. If you change protocol schemas or client code outside that watch workflow, rebuild the producer before trusting runtime behavior.
-
-Use the named root build targets instead of remembering workspace dependency chains:
-
-```bash
-npm run build:client       # protocol -> client
-npm run build:server-deps  # highlight -> relay -> protocol -> client
-npm run build:server       # server-deps -> server -> cli
-npm run build:app-deps     # highlight -> protocol -> client -> expo-two-way-audio
-```
-
-Use `npm run build:server` whenever you have changed any daemon/server-facing package and need clean cross-package types or runtime behavior.
-
-The app Metro config disables Watchman and uses Metro's node crawler for exports. Keep that invariant unless you have verified production app exports on machines with and without Watchman installed; distro Watchman builds can differ in capabilities and change Metro's crawl behavior.
-
-For tighter loops, you can rebuild a single workspace:
-
-- Changed `packages/protocol/src/*` or `packages/client/src/*`: `npm run build:client`.
-- Changed `packages/server/src/*`, `packages/cli/src/*`, `packages/relay/src/*`, or `packages/highlight/src/*`: `npm run build:server`.
-- Changed app build dependencies: `npm run build:app-deps`.
-
-## Dependency patches
-
-`patches/*.patch` are applied by `scripts/postinstall-patches.mjs` on every install. A patch only
-runs when its package is actually present, so add the package to that script's `patchedPackages`
-list when you introduce a new patch — otherwise the file sits in `patches/` and never applies.
-Regenerate a patch with `npx patch-package <package>` after editing `node_modules/<package>`, and
-patch every build the consumers use: Metro resolves the `react-native` field of a package
-(`src/*.ts` for `react-native-svg`), while Node and Vitest resolve `main`/`module`
-(`lib/commonjs`, `lib/module`). Patching only `lib/` leaves the app bundle unfixed.
-
-## ACP provider catalog versions
-
-The in-app ACP provider catalog pins package-runner entries (`npx`, `npm exec`,
-and `uvx`) to exact package versions. Run the drift checker regularly — and
-before releases — so catalog installs do not sit on stale agent versions:
-
-```bash
-npm run acp:version-drift        # report stale/non-exact package pins
-npm run acp:version-drift:check  # same, exits non-zero on drift
-npm run acp:version-drift:update # rewrite catalog pins to latest exact versions
-```
-
-The checker updates only package-runner catalog entries. Providers that use a
-preinstalled binary such as `opencode acp`, `cursor-agent acp`, or `goose acp`
-are reported as skipped because their versions are owned by the user's local
-install.
-
-## CLI reference
-
-Use `npm run cli` to run the in-repo CLI from source (`npx tsx packages/cli/src/index.ts`). The script wraps the CLI with `scripts/dev-home.sh`, so it automatically uses this checkout's `.dev/paseo-home` and dev daemon endpoint unless you pass an explicit override. The globally installed `paseo` binary on macOS is a symlink into the installed Paseo desktop app, not this checkout — use it to drive the desktop's built-in daemon, but use `npm run cli` when you want to talk to the CLI you are editing.
-
-Canonical automation uses `paseo project create/ls/rename/delete`, `paseo workspace create/ls/rename/archive`, `paseo heartbeat create/update/delete`, and the full `paseo schedule` group. MCP heartbeat automation is intentionally smaller: create and delete only. Detach remains an explicit user lifecycle action rather than an agent tool. `paseo run --new-workspace local|worktree` composes workspace creation with agent creation. The old `paseo worktree` and `paseo run --worktree` forms are hidden compatibility aliases.
-
-```bash
-npm run cli -- ls -a -g              # List all agents globally
-npm run cli -- ls -a -g --json       # Same, as JSON
-npm run cli -- inspect <id>          # Show detailed agent info
-npm run cli -- logs <id>             # View agent timeline
-npm run cli -- agent open <id>       # Focus an existing agent in Paseo Desktop
-npm run cli -- daemon status         # Check daemon status
-npm run cli -- clone owner/repo --dir ~/workspace # Clone GitHub repo and register project
-```
-
-Use the global `--host` option to point the CLI at a different daemon:
-
-```bash
-npm run cli -- --host localhost:7777 ls -a
-npm run cli -- --host ssh://user@host ls -a
-```
-
-Set `PASEO_HOST` to use the same target across invocations. An explicit
-selector overrides both environment selectors. With both `PASEO_HOME` and `PASEO_HOST` set, pass an explicit selector. See [CLI target selection](../public-docs/cli.md#select-one-daemon).
-
-In an SSH URI, the URL port is the SSH server port. The remote daemon defaults to `127.0.0.1:6767`; use `?daemonPort=7777` to override it. The transport runs non-interactively through the local OpenSSH client and never installs, starts, or configures the remote daemon. User-facing setup and troubleshooting live in [public-docs/connectivity.md](../public-docs/connectivity.md#ssh).
-
-Desktop integrations can focus an existing agent without creating one or
-sending a message. Use `paseo://h/<server-id>/agent/<agent-id>`, or run
-`paseo agent open <agent-id>`. The CLI reads the local daemon's server ID by
-default; pass `--server <server-id>` when targeting another server.
-
-## Agent state
-
-Agent data lives at:
-
-```
-$PASEO_HOME/agents/{cwd-with-dashes}/{agent-id}.json
-```
-
-Find an agent by ID:
-
-```bash
-find $PASEO_HOME/agents -name "{agent-id}.json"
-```
-
-Find by content:
-
-```bash
-rg -l "some title text" $PASEO_HOME/agents/
-```
-
-## Provider session files
-
-Get the session ID from the agent JSON (`persistence.sessionId`), then:
-
-**Claude:**
-
-```
-~/.claude/projects/{cwd-with-dashes}/{session-id}.jsonl
-```
-
-**Codex:**
-
-```
-~/.codex/sessions/{YYYY}/{MM}/{DD}/rollout-{timestamp}-{session-id}.jsonl
-```
-
-## Testing with Playwright MCP
-
-Point Playwright MCP at the running Expo web target. For root checkout dev, `npm run dev:app` reserves `http://localhost:8081`. For Paseo-managed worktree app services, use the service URL or port shown by Paseo for that worktree.
-
-Do NOT use browser history (back/forward). Always navigate by clicking UI elements or using `browser_navigate` with the full URL — the app uses client-side routing and browser history breaks state.
-
-## App web deploys
-
-`packages/app` exports a single-page Expo web app and deploys the `dist/`
-directory to Cloudflare Pages with `npm run deploy:web --workspace=@getpaseo/app`.
-
-PWA install metadata lives in `packages/app/public/manifest.json` and is linked
-from `packages/app/public/index.html`. Keep the install icons in `public/` so
-Cloudflare serves them from stable root URLs after `expo export`.
-
-Do not add service-worker caching casually. Paseo is a live control surface for
-agents, and an aggressive service worker can strand installed users on stale web
-code. If offline behavior becomes a product requirement, add it deliberately
-with an update strategy and test the installed-app upgrade path.
-
-## Expo troubleshooting
-
-```bash
-npx expo-doctor
-```
-
-Diagnoses version mismatches and native module issues.
-
-## Typecheck
-
-Always run typecheck after changes:
-
-```bash
-npm run typecheck
-```

docs/docker.md

@@ -1,241 +0,0 @@
-# Running Paseo in Docker
-
-Paseo publishes a container image for running the daemon on a server, VM, NAS,
-or homelab box. The image also serves the bundled browser web UI, so one
-container gives you both the daemon API and a self-hosted UI.
-
-The image source lives in [`docker/`](../docker/).
-
-## How it works
-
-The official image:
-
-- builds `@getpaseo/server` and `@getpaseo/cli` from source-built workspace tarballs
-- runs the daemon as the non-root `paseo` user
-- listens on `0.0.0.0:6767` inside the container
-- enables the bundled daemon web UI with `PASEO_WEB_UI_ENABLED=true`
-- stores daemon state and agent credentials under `/home/paseo`
-- leaves agent CLIs out of the base image
-
-Open the container's HTTP origin, for example `http://localhost:6767`, to load
-the web UI. The served app receives a same-origin connection hint and connects
-back to that daemon. Static UI files load without daemon auth; API and
-WebSocket requests still require `PASEO_PASSWORD` when one is configured.
-
-Host-side CLI commands select the container explicitly, for example `paseo project ls --host 127.0.0.1:6767`. Without an endpoint selector the CLI looks for a local home’s supervisor. Container environment settings are deployment overrides; worker restart preserves them. Your container manager owns full supervisor replacement.
-
-## Quick Start
-
-```bash
-docker run -d --name paseo \
-  -p 6767:6767 \
-  -e PASEO_PASSWORD=change-me \
-  -v "$PWD/paseo-home:/home/paseo" \
-  -v "$PWD:/workspace" \
-  ghcr.io/getpaseo/paseo:latest
-```
-
-Then open:
-
-```text
-http://localhost:6767
-```
-
-If you set `PASEO_PASSWORD`, enter the same password when adding the direct
-daemon connection in the web UI or another Paseo client.
-
-## Docker Compose
-
-Use [`docker/docker-compose.example.yml`](../docker/docker-compose.example.yml):
-
-```bash
-cp docker/docker-compose.example.yml docker-compose.yml
-$EDITOR docker-compose.yml
-docker compose up -d
-```
-
-Minimal example:
-
-```yaml
-services:
-  paseo:
-    image: ghcr.io/getpaseo/paseo:latest
-    restart: unless-stopped
-    ports:
-      - "6767:6767"
-    environment:
-      PASEO_PASSWORD: "change-me"
-    volumes:
-      - ./paseo-home:/home/paseo
-      - ./workspace:/workspace
-```
-
-## Installing Agents
-
-The base image does not preinstall Claude Code, Codex, OpenCode, Copilot, Pi, or
-other agent CLIs. That keeps the default image small and avoids coupling Paseo
-releases to third-party agent release cycles.
-
-Create a child image for the agents you use:
-
-```Dockerfile
-FROM ghcr.io/getpaseo/paseo:latest
-
-USER root
-RUN npm install -g @openai/codex @anthropic-ai/claude-code opencode-ai
-```
-
-Build it:
-
-```bash
-docker build -f Dockerfile -t paseo-with-agents .
-```
-
-Then use `image: paseo-with-agents` in Compose.
-
-Leave the child image user as root. The base entrypoint uses root only for
-first-run directory setup, then drops the daemon and launched agents to the
-non-root `paseo` user.
-
-An example child image is in
-[`docker/Dockerfile.agents.example`](../docker/Dockerfile.agents.example).
-
-You can also mount credentials from the host or run agent login once inside the
-container:
-
-```bash
-docker exec -it --user paseo paseo codex
-docker exec -it --user paseo paseo claude
-```
-
-Agent credentials and config persist in `/home/paseo`, alongside daemon state.
-Provider environment variables such as `OPENAI_API_KEY`, `ANTHROPIC_API_KEY`,
-`OPENAI_BASE_URL`, or `ANTHROPIC_BASE_URL` can be passed through `docker run -e`
-or `compose.environment`; Paseo passes them to launched agents.
-
-## Volumes
-
-| Mount         | Purpose                                                                  |
-| ------------- | ------------------------------------------------------------------------ |
-| `/home/paseo` | Paseo state under `.paseo` plus agent config such as `.codex`, `.claude` |
-| `/workspace`  | Code that Paseo and launched agents can read and write                   |
-
-The image defaults:
-
-| Variable       | Default              |
-| -------------- | -------------------- |
-| `HOME`         | `/home/paseo`        |
-| `PASEO_HOME`   | `/home/paseo/.paseo` |
-| `PASEO_LISTEN` | `0.0.0.0:6767`       |
-
-If you bind-mount host directories on Linux, make sure the container user can
-write them. The built-in `paseo` user has uid/gid `1000:1000`. For a different
-host uid/gid, either adjust ownership on the mounted directories or run the
-container with Docker's `--user` / Compose `user:` option.
-
-## Reverse Proxies
-
-When serving Paseo behind a reverse proxy, forward normal HTTP requests and
-WebSocket upgrades to the same daemon port.
-
-Caddy example:
-
-```caddy
-paseo.example.com {
-  reverse_proxy 127.0.0.1:6767
-}
-```
-
-Nginx example:
-
-```nginx
-server {
-    listen 443 ssl;
-    server_name paseo.example.com;
-
-    location / {
-        proxy_pass http://127.0.0.1:6767;
-        proxy_http_version 1.1;
-        proxy_set_header Upgrade $http_upgrade;
-        proxy_set_header Connection "upgrade";
-        proxy_set_header Host $host;
-        proxy_set_header X-Forwarded-Proto $scheme;
-    }
-}
-```
-
-If you reach the daemon by DNS name, set `PASEO_HOSTNAMES` so host-header
-validation allows that name:
-
-```yaml
-environment:
-  PASEO_HOSTNAMES: "paseo.example.com,.lan"
-```
-
-IPs and `localhost` are allowed by default.
-
-## Security
-
-- Set `PASEO_PASSWORD` for any published port or network-reachable deployment.
-- Prefer HTTPS at the reverse proxy for direct browser access.
-- Use the [official Paseo relay](https://github.com/getpaseo/paseo-relay) for
-  untrusted networks or mobile access when you do not want to expose the daemon
-  port directly.
-- The container is the isolation boundary for agents. Agents can read and write
-  whatever you mount into `/workspace` and whatever credentials you place in
-  `/home/paseo`.
-- The bundled web UI static files are public on the daemon origin. The daemon
-  API and WebSocket remain protected by password auth when configured.
-
-See [SECURITY.md](../SECURITY.md) for the daemon trust model.
-
-## Building Locally
-
-```bash
-docker build -f docker/base/Dockerfile -t paseo:local .
-```
-
-To assert the source tree version while building:
-
-```bash
-docker build \
-  --build-arg PASEO_VERSION=0.1.102 \
-  -t paseo:0.1.102 \
-  -f docker/base/Dockerfile \
-  .
-```
-
-The Docker workflow builds the image on pull requests and on `main` as a
-non-publishing check. Stable `vX.Y.Z` tag pushes publish
-`ghcr.io/getpaseo/paseo:X.Y.Z` and `ghcr.io/getpaseo/paseo:latest`. Beta tags
-publish only the exact prerelease tag, such as
-`ghcr.io/getpaseo/paseo:0.1.102-beta.1`, and do not update `latest`.
-
-To replace a Docker image in place without rebuilding desktop, APK, or EAS
-mobile release artifacts, dispatch the Docker workflow manually instead of
-pushing a `v*` release tag:
-
-```bash
-gh workflow run docker.yml \
-  --ref main \
-  -f paseo_version=0.1.102-beta.1 \
-  -f publish=true
-```
-
-Manual Docker publishes require an explicit `paseo_version`. The workflow builds
-from the checked-out source tree and publishes only the exact prerelease image
-tag for prerelease versions.
-
-The published image is multi-arch for `linux/amd64` and `linux/arm64`.
-
-## Troubleshooting
-
-- **The web UI loads but cannot connect**: if `PASEO_PASSWORD` is set, add a
-  direct connection with the same password.
-- **403 Host not allowed**: set `PASEO_HOSTNAMES` to the DNS names you use.
-- **Provider not available**: install that agent CLI in a child image or mount a
-  runtime where the binary is on `PATH`.
-- **Permission errors in `/workspace`**: make the mounted directory writable by
-  uid/gid `1000:1000`, or run the container as the host uid/gid.
-- **Logs**: inspect `docker logs paseo` or
-  `/home/paseo/.paseo/daemon.log` inside the container.

docs/explorer-sidebar.md

@@ -1,97 +0,0 @@
-# Explorer sidebar and side pane
-
-The Explorer sidebar and the side pane share panel implementations, but they have different shell
-contracts.
-
-| Surface          | Purpose                      | Lifecycle                                  |
-| ---------------- | ---------------------------- | ------------------------------------------ |
-| Explorer sidebar | Files and Changes navigation | Cmd+E shows or hides the dedicated dock    |
-| Side pane        | Ordinary workspace content   | Created and closed like any workspace pane |
-
-## Panel host contract
-
-Every desktop panel registers its supported `PaneHost` values and presentation. Launchers derive
-fixed-target labels and icons from that registration, filter by host, and never substitute one
-panel type for another. Tab moves reject unsupported destinations, and placement resolves only to
-a compatible pane.
-
-Files and Changes are the Explorer defaults. Their panel manifests mark them as singletons,
-so a pane’s + menu omits each while that pane already contains it. Closing one makes its menu
-item available again. Other compatible tabs, including agents, terminals, files, and diffs,
-can move between Explorer and main panes.
-Keep panel implementations independent of either shell. `WorkspacePanelHost` owns mounting and
-retention, while each shell owns its tabs, focus, dragging, resizing, and shortcuts.
-
-## Explorer sidebar
-
-`packages/app/src/workspace-tabs/explorer-sidebar.ts` owns show, hide, toggle, and view selection.
-On desktop, the shell is rendered outside the workspace split canvas so it divides the full
-workspace, including the header. It has its own persisted width and resize handle. Main-pane splits
-never read or modify that width.
-
-`packages/app/src/workspace-tabs/open-supporting-view.ts` owns semantic Changes and pull-request
-opens. Compact and wide native layouts select the matching Explorer tab. Desktop Changes opens
-follow the shared diff preference. Desktop pull requests use their Main panel, On the side, or
-Explorer sidebar setting. Automatic PR discovery follows that preference once per workspace without
-interrupting the user's work. Closing the tab opts that workspace out of future automatic opens,
-even for a different PR; moving or reordering it remains the user's choice.
-Callers request the content and never choose the shell.
-The composer Changes pill is a two-stage desktop action: it first reveals Explorer on Changes, then
-routes later presses to the working diff through the shared diff preference.
-
-The persisted layout still contains the Explorer pane so tabs survive reloads. The renderer removes
-that pane from the workspace split tree and docks it separately. Persisted identifiers retain the
-literal `"explorer"` pane id and `explorerPaneIdByWorkspace` key for compatibility.
-
-Explorer uses the shared workspace tab row and ordinary tab context menus. Files and Changes
-hide their close buttons through the panel manifest; close them from the tab context menu.
-Other tabs reveal the close control on hover. The + menu opens compatible panels in the dock and
-omits Agent and terminal profiles. Agents and terminals can still be dragged into Explorer.
-Bulk-close actions apply only to the dock's tabs. Explorer tabs can be reordered and dragged
-between compatible panes, but the dock cannot be split or maximized. Selecting an Explorer tab
-does not change workspace focus.
-
-Cmd+E shows or hides Explorer without changing its selected view. Compact layouts use the combined
-full-screen Explorer overlay for Changes, Files, and pull requests, and close it after a file opens. Compact Changes has no tree rail; its overview is the Jump to file action (`packages/app/src/git/jump-to-file/`), a sheet over the same changed-files tree the desktop rail renders.
-Wide native layouts without pane splits use the same combined content in a resizable inline dock;
-opening a file leaves that dock visible. Both presentations keep their selection in the panel store
-and reuse the layout store's per-workspace Explorer width. They do not create a second Explorer
-lifecycle.
-
-## Side pane
-
-`packages/app/src/workspace-tabs/open-beside.ts` owns content opened beside the user's work. The
-layout store remembers one ordinary pane per workspace. The first side open creates a full-height
-right split around the workspace root; later side opens reuse it.
-
-Removing a pane clears its remembered id; a later side open creates a new pane. The last visible
-ordinary pane stays when its final tab closes and shows the New launcher. An empty workspace does
-not automatically create an agent draft tab; choosing Agent opens one. Explorer cannot replace the
-workspace canvas, even when visible. Restoring a saved layout enforces the same rule while preserving Explorer and saved
-tab content. There is no hidden side-pane lifecycle.
-
-Placement intent still controls existing tabs:
-
-| Mode      | New target                  | Existing target                   |
-| --------- | --------------------------- | --------------------------------- |
-| `pane`    | opens in the requested pane | moves to the requested pane       |
-| `prefer`  | opens in the requested pane | stays where the user placed it    |
-| `focused` | opens in the focused pane   | focuses it where it already lives |
-| `ambient` | opens in a compatible pane  | focuses it where it already lives |
-
-Explicit **Open to Side** uses `pane`. Implicit opens use `prefer`, so a preference affects only a
-new target and never yanks an existing tab out of a user-selected pane.
-
-## Routing preferences
-
-Desktop **Settings → Layout → Open location** has independent Main panel or On the side choices for
-Explorer Files, diffs, chat files, files opened from diffs, and subagents. They default to Main
-panel. Mobile ignores them.
-
-Pull requests have a three-way open location: Main panel, On the side, or Explorer sidebar. Explorer
-sidebar is the default. Compact layouts always open pull requests in Explorer regardless of this
-desktop preference.
-
-Panels request an implicit open through the narrow `openPreferredTarget(target, source)` pane
-contract. Entry points outside panels use `openPreferredWorkspaceTarget`. Do not branch on a
-specific shell inside a panel.

docs/expo-router.md

@@ -1,197 +0,0 @@
-# Expo Router
-
-Paseo's mobile route tree is fragile because Expo Router and React Navigation do
-not fail loudly when a nested native route is mounted under the wrong layout. The
-usual symptom is a white or blank native screen with no JavaScript crash.
-
-Read this before changing `packages/app/src/app`, startup routing, remembered
-workspace restore, or active workspace selection.
-
-## Ownership
-
-Each layout owns only the routes directly inside its directory.
-
-- The root layout registers `h/[serverId]`.
-- The root layout does not register host leaf routes such as
-  `h/[serverId]/workspace/[workspaceId]`, `h/[serverId]/open-project`, or
-  `h/[serverId]/index`.
-- `packages/app/src/app/h/[serverId]/_layout.tsx` owns the host leaves with
-  relative screen names: `index`, `workspace/[workspaceId]/index`,
-  `agent/[agentId]`, `sessions`, `open-project`, `settings`,
-  `plugin/[pluginId]/[surfaceId]`, and
-  `plugin/[pluginId]/[contributionKind]/[contributionId]`.
-
-Expo Router warns with `[Layout children]: No route named ...` when a layout
-registers grandchildren. Treat that warning as a route-tree bug. On native, that
-shape can leave a nested index route mounted without its local dynamic params and
-render a blank screen.
-
-## Startup
-
-The root `/` route chooses a host boundary. It does not jump directly into a host
-leaf.
-
-- Good: `/` -> `/h/[serverId]`
-- Bad: `/` -> `/h/[serverId]/workspace/[workspaceId]`
-
-`/h/[serverId]` is the host home route. The host index restores the last
-remembered workspace for that host after the remembered selection has hydrated
-and the workspace has not been proven missing. If there is no restorable
-workspace, it goes to global `/open-project`.
-
-This restore is based on the last navigated workspace, not current connection
-status. Do not redirect to another online host just because the remembered host
-is still connecting or offline; the workspace screen owns that offline/loading
-state.
-
-This split is deliberate. The host layout must mount first so native local
-dynamic params exist before any nested workspace leaf is selected.
-
-## Error Recovery
-
-The root error boundary lives above `ExpoRoot` in `src/root-app.tsx`. Reload
-remounts the router at `/open-project`, preserving saved workspace layouts and
-the remembered selection. Do not move the boundary inside the root layout:
-catching a render error there unmounts the navigator, so the recovery button
-cannot reliably dispatch a navigation reset. Starting recovery at `/` would
-restore the same workspace and could repeat the crash.
-
-## App-Wide Route Hops
-
-When app-wide routes such as `/new`, `/settings`, or `/sessions` navigate back
-into a host workspace, use `navigateToWorkspace()`. Do not make the caller
-branch on its current route.
-
-Pass only `serverId` and `workspaceId` for normal attention-aware navigation.
-When the action names a specific tab, pass it as `target`; that explicit choice
-is authoritative. Callers should not choose between separate route and tab
-navigation APIs.
-
-The root stack owns `h/[serverId]`; the host stack owns
-`workspace/[workspaceId]/index`. Repeated global-route hops must `POP_TO` the
-root host route and pass the nested workspace screen when a host route is
-already mounted, or Expo Router can append extra hidden workspace deck entries.
-The workspace navigation helper inspects the mounted navigation state to make
-that decision; if no host route is mounted yet, it falls back to ordinary route
-navigation. Both paths wait for the root navigation container to be ready. The
-workspace navigation owner keeps the latest pending intent across ref
-re-registration and applies it on the container's `ready` event; routes must not
-add their own readiness retries.
-
-Those hidden entries are not harmless: composer floating panels can measure
-against the wrong deck and disappear offscreen. Follow the
-[retained panel measurement rules](coding-standards.md#retained-panel-measurements)
-for components that intentionally remain mounted while hidden.
-
-Hidden host routes may keep their local params while an app-wide route is
-foregrounded. Active-workspace observers must prefer the current pathname and
-only use local param fallback during cold mount (`/` or empty pathname), or a
-hidden workspace can overwrite the remembered workspace before Settings or
-History returns.
-
-Plugin settings use the distinct `settings/hosts/[serverId]/plugins/[pluginId]/[screenId]` leaf;
-Back returns to that host's Plugins page.
-
-Settings detail routes are separate siblings on purpose. Keep
-`settings/[section]`, the host routes, the projects index, and project detail as
-distinct route names. `router.dismissTo()` ultimately matches stack entries by
-route name. A single catch-all Settings route would make project detail and the
-projects index the same route; Back would update params in place and leave a
-phantom detail entry underneath. The host routes also stay outside the
-store-ready protected group so a cold host deep link can survive daemon startup.
-Do not collapse this topology with a catch-all, `getId`, or
-`dangerouslySingular` workaround.
-
-## Agent Targets
-
-Notifications and agent URLs enter the router with different authoritative
-targets.
-
-- Notifications carry `serverId`, `workspaceId`, and `agentId`. Route them
-  directly to the workspace with the agent open intent.
-- Agent URLs carry only `serverId` and `agentId`. Route them through
-  `/h/[serverId]/agent/[agentId]`; that route waits for the named host, resolves
-  the agent's workspace from the host, and then opens the agent there.
-
-Both paths converge on `navigateToAgent()`. Do not make notification routing
-guess a workspace, and do not add a workspace to the stable agent URL format.
-
-## Params
-
-Required dynamic params belong to the matched route.
-
-Do not paper over missing required params by reading global params in the leaf.
-If `useLocalSearchParams()` misses a required param, fix layout ownership or the
-startup route shape.
-
-Use the host route context for host-owned leaves that need the host id after
-`h/[serverId]/_layout.tsx` has matched. Do not make a leaf recover from an
-unmatched tree by guessing from global state.
-
-## App Directory
-
-Keep non-route modules out of `src/app`. Expo Router treats ordinary `.ts` and
-`.tsx` files there as routes, which produces `missing the required default
-export` warnings and pollutes the route tree.
-
-Put shared route policy in `src/navigation`, `src/utils`, stores, or another
-non-route directory.
-
-## Native Stack
-
-Keep workspace identity and retention outside native-stack `getId` and
-`dangerouslySingular`. Expo Router maps `dangerouslySingular` to React
-Navigation `getId`, and `getId` has broken Android native-stack/Fabric by
-reordering an already-mounted workspace screen.
-
-Use `ThemedStack` from `packages/app/src/navigation/themed-stack.tsx` for every
-Expo Router stack. React Navigation otherwise paints each native stack screen
-with its light default background. A screen-level wrapper can hide that surface
-while settled, but Android may expose it for one frame when navigation crosses
-from a nested stack to its parent stack. This is especially visible when an
-app-wide route such as `/new` opens from a dark workspace.
-
-Do not read the active theme with `useUnistyles()` in a layout to build
-`screenOptions`. `ThemedStack` keeps that third-party prop theme-reactive through
-a small `withUnistyles` boundary without subscribing the route tree itself to
-every Unistyles runtime update.
-
-Navigators keep their identity across appearance changes. `ThemedStack` remounts
-each screen's content below the native stack when appearance tokens change; a
-keyed wrapper above a stack remounts the stack itself, and Android crashes when
-that happens while a FragmentManager transaction is running, which settings
-hydration at startup makes likely. A screen that mounts a nested navigator (the
-root stack's `h/[serverId]`) is passed in `nestedNavigatorScreens` so the nested
-stack owns its own screens. See [unistyles.md](unistyles.md).
-
-## Regression Shape
-
-Pure helper tests are useful but not enough. The failure mode here is native
-route-tree state, so a real regression should launch native with seeded persisted
-state:
-
-1. Seed `paseo:last-workspace-route-selection` with a valid
-   `{ serverId, workspaceId }`.
-2. Launch the native app cold.
-3. Assert a real screen is visible, not the blank tree.
-4. Assert no `[Layout children]` warning appears.
-
-The pure policy tests should still enforce the boundary split:
-
-- root startup with a saved workspace returns `/h/[serverId]`;
-- host index with the same saved workspace returns
-  `/h/[serverId]/workspace/[workspaceId]`;
-- host index with no restorable workspace returns `/open-project`.
-
-## Checklist
-
-Before landing route changes:
-
-- [ ] Did you change `packages/app/src/app`? Re-read this file.
-- [ ] Did you touch remembered workspace restore? Keep root on `/h/[serverId]`.
-- [ ] Did a route return to a workspace? Use `navigateToWorkspace()` and pass a
-      `target` when the action names a specific tab.
-- [ ] Did you add a route? Register it in the layout that directly owns it.
-- [ ] Did `useLocalSearchParams()` lose a required param? Fix the route tree.
-- [ ] Did native show a blank screen without a crash? Suspect route ownership
-      before stores, themes, or rendering.

docs/file-icons.md

@@ -1,122 +0,0 @@
-# File Icons
-
-The file explorer uses colored SVG icons from [`material-icon-theme`](https://github.com/material-extensions/vscode-material-icon-theme) (installed as a dev dependency in `packages/app`).
-
-## How it works
-
-Two files:
-
-- `packages/app/src/components/material-file-icons.ts` — the vendor table. `SVG_ICONS` maps icon
-  names to SVG strings copied verbatim from the theme, `EXTENSION_TO_ICON` maps extensions to icon
-  names, and `getRawFileIconSvg(fileName)` looks one up with a generic fallback. Keep it a faithful
-  copy so re-copying an icon stays a mechanical edit.
-- `packages/app/src/components/file-icon-svg.ts` — `getFileIconSvg(fileName)`, the only thing
-  anyone should import. It desaturates the vendor colours and caches the result.
-
-Render with `<MaterialFileIcon fileName size />` rather than reaching for `SvgXml` yourself.
-
-## Why the colours are toned down
-
-material-icon-theme picks its palette for VS Code's file tree, where the icon is the only colour on
-the row. Ours share rows with status dots, diff stats, and check badges, and a column of them at
-full chroma is the loudest thing in the panel.
-
-Every hex in the SVG is pulled toward neutral at the same perceived lightness (`desaturateHexColor`
-in `packages/app/src/utils/color.ts`, OKLab — scaling HSL saturation instead would darken the
-yellows and barely touch the blues). Hue survives, which is the only part of an icon's colour that
-carries meaning at 16pt.
-
-`ICON_CHROMA` in `file-icon-svg.ts` is the single knob. Move it; do not add per-icon overrides, or
-we are back to hand-picking 53 colours.
-
-## Adding a new icon
-
-1. Find the icon name in the material-icon-theme manifest:
-
-```bash
-node -e "
-const m = require('./node_modules/material-icon-theme/dist/material-icons.json');
-console.log('fileExtensions:', m.fileExtensions['YOUR_EXT']);
-console.log('languageIds:', m.languageIds['YOUR_LANG']);
-"
-```
-
-2. Verify the SVG exists:
-
-```bash
-cat node_modules/material-icon-theme/icons/ICON_NAME.svg
-```
-
-3. Add two things to `material-file-icons.ts`:
-   - The SVG string in `SVG_ICONS`:
-
-     ```ts
-     "icon_name": `<svg ...>...</svg>`,
-     ```
-
-   - The extension mapping in `EXTENSION_TO_ICON`:
-     ```ts
-     "ext": "icon_name",
-     ```
-
-4. Run `npm run typecheck` to verify.
-
-## Currently included icons
-
-53 unique icons covering these extensions:
-
-| Extension(s)                               | Icon        |
-| ------------------------------------------ | ----------- |
-| `ts`                                       | typescript  |
-| `tsx`                                      | react_ts    |
-| `js`                                       | javascript  |
-| `jsx`                                      | react       |
-| `py`                                       | python      |
-| `go`                                       | go          |
-| `rs`                                       | rust        |
-| `rb`                                       | ruby        |
-| `java`                                     | java        |
-| `kt`                                       | kotlin      |
-| `c`                                        | c           |
-| `cpp`                                      | cpp         |
-| `h`                                        | h           |
-| `hpp`                                      | hpp         |
-| `cs`                                       | csharp      |
-| `swift`                                    | swift       |
-| `dart`                                     | dart        |
-| `ex`, `exs`                                | elixir      |
-| `erl`                                      | erlang      |
-| `hs`                                       | haskell     |
-| `clj`                                      | clojure     |
-| `scala`                                    | scala       |
-| `ml`                                       | ocaml       |
-| `r`                                        | r           |
-| `lua`                                      | lua         |
-| `zig`                                      | zig         |
-| `nix`                                      | nix         |
-| `php`                                      | php         |
-| `html`                                     | html        |
-| `css`                                      | css         |
-| `scss`                                     | sass        |
-| `less`                                     | less        |
-| `json`                                     | json        |
-| `yml`, `yaml`                              | yaml        |
-| `xml`                                      | xml         |
-| `toml`                                     | toml        |
-| `md`, `markdown`                           | markdown    |
-| `sql`                                      | database    |
-| `graphql`, `gql`                           | graphql     |
-| `sh`, `bash`                               | console     |
-| `tf`                                       | terraform   |
-| `hcl`                                      | hcl         |
-| `vue`                                      | vue         |
-| `svelte`                                   | svelte      |
-| `astro`                                    | astro       |
-| `wasm`                                     | webassembly |
-| `svg`                                      | svg         |
-| `png`, `jpg`, `jpeg`, `gif`, `webp`, `ico` | image       |
-| `txt`                                      | document    |
-| `conf`, `cfg`, `ini`                       | settings    |
-| `lock`                                     | lock        |
-| `groovy`                                   | groovy      |
-| `gradle`                                   | gradle      |

docs/file-observation.md

@@ -1,21 +0,0 @@
-# File observation
-
-Use `packages/server/src/server/file-observer` for recursive filesystem observation. Create one observer service at the owning service boundary, subscribe roots through it, and close it during owner shutdown. Keep platform watchers, directory discovery, exclusion reconciliation, event batching, failure cleanup, diagnostics, and teardown inside the module. A consumer supplies a root and excluded subtrees; it must not branch on the platform or manage child watchers.
-
-Do not replace the Linux implementation with `fs.watch({ recursive: true })`. Node 22 implements Linux recursion in JavaScript by walking the tree and watching every file and directory. Paseo's directory-only Linux watcher already exhausted resources before ignored-tree pruning and a watcher cap were added in [#794](https://github.com/getpaseo/paseo/pull/794).
-
-Closing an observation must remain safe after its root is renamed or removed. Workspace archive removes owned worktrees while releasing observation references, so teardown cannot assume the watched path still exists.
-
-`unsubscribe()` is an awaited barrier. Once it resolves, no scan, reconciliation, queued event, native handle, or callback may remain. `updateIgnore()` is the equivalent barrier for excluded paths: events queued below a newly excluded root cannot be delivered after it resolves. Treat path disappearance while scanning, attaching, or receiving a watcher error as rename/archive churn. Surface permission and resource errors so WorkspaceGit can enter bounded polling.
-
-Linux topology repair is trailing-debounced and scoped to the renamed path. A file rename needs one classification stat; a new or moved directory scans only its subtree. Full-tree scans are reserved for startup and ignore-set replacement. The initial Linux scan conservatively emits existing files discovered before their directory watcher was installed; WorkspaceGit batches these into one refresh. Benchmark this startup cost with pre-populated trees.
-
-Windows and macOS use one native recursive watcher plus an ignored-pruned, directory-indexed inventory. Native events deliver immediately. Named events trigger serialized shallow scans of their parent directories; known directory events also reconcile that subtree. This recovers concrete create and delete paths omitted by coalescing without walking the whole root for each edit. Classification is admission-controlled to 32 concurrent `fs.stat` calls, since `fs.stat` runs on the libuv threadpool the whole daemon shares. Startup and exclusion changes use an awaited full inventory barrier. Activity arms a full safety audit 30 seconds after it settles, with a 30-second minimum interval and a five-minute starvation bound; pathless native events also trigger an immediate shallow root scan. Observation fails into polling rather than retaining more than 250,000 file and directory entries per root. A repository that large is also expensive to poll, so degraded polling doubles its gap from 5 seconds to a 60-second ceiling while the workspace snapshot comes back unchanged, and resets to 5 seconds on the first change. Explicit reads still force a refresh; the ceiling only bounds how long an edit made outside Paseo stays undiscovered.
-
-Read aggregate health from the owning observer service. Runtime metrics include active observations, native handles, tracked native files, pending events and immediate reconciliation work, scoped and full reconciliation activity and latency, and failure counts. `nativeTrackedFileCount` and other per-file counters are native-backend diagnostics only — the Linux backend keeps no per-file inventory and reports zero — so a cross-platform assertion belongs on delivered events, not those counters. Delayed safety audits do not count as pending work. Closing the service releases every subscription and clears its diagnostics. Do not add path lists, watcher handles, or platform-specific controls to this interface.
-
-Git owns Git-ignore evaluation. The observer accepts absolute excluded roots and applies updates without replacing the observation or exposing its watcher topology. This keeps tracked files inside otherwise ignored directories observable and keeps Git policy out of the filesystem module.
-
-Workspace Git verifies each repository metadata subscription with a one-shot canary inside the Git directory. If the event does not round-trip through the subscription callback, treat the watcher as unavailable and enter degraded polling. Refresh working-tree Git-ignore exclusions from ignore-file events, newly observed directories, and watcher recovery, never from a healthy-watcher timer. `git ls-files` reports an ignored directory only once it exists, so new directory topology is a trigger in its own right; the refresh is edge-triggered per directory and debounced so a dependency install collapses into a couple of Git runs.
-
-The real-filesystem contracts and daemon auto-archive lifecycle run in the normal server test suite. Use the scripts only for manual performance and soak work: `npm run measure:file-observer --workspace=@getpaseo/server` measures burst and sustained-create behavior, and `npm run repro:file-observer-teardown --workspace=@getpaseo/server` runs the teardown soak.

docs/floating-panels.md

@@ -1,367 +0,0 @@
-# Floating Panels
-
-Anchored popovers — tooltips, hover cards, dropdowns, autocompletes — that visually
-float above an anchor element on iOS, Android, and web. This doc captures the
-non-obvious traps. It is **not** a tutorial; it assumes you have seen the
-canonical files and are trying to add or change one.
-
-## Canonical files
-
-| File                                     | Use case                                                          |
-| ---------------------------------------- | ----------------------------------------------------------------- |
-| `components/ui/combobox.tsx`             | Anchored picker with search; mobile falls back to bottom sheet    |
-| `components/ui/tooltip.tsx`              | Non-interactive hover/long-press tooltip                          |
-| `components/ui/hover-card.tsx`           | Desktop-web hover card the pointer can move onto; Portal          |
-| `components/ui/autocomplete-popover.tsx` | Slash-command autocomplete anchored to the focused composer input |
-
-Each handles a different mix of concerns: combobox owns input focus, tooltip is
-non-interactive, hover-card is web-only desktop, autocomplete keeps the composer
-input focused while its scrollable list lives in a Portal. There is no shared
-"floating panel" primitive yet — when a fifth use case shows up we can revisit;
-until then prefer copying the closest file and trimming.
-
-## Popover width contract
-
-Combobox desktop popovers are never narrower than their trigger, and they grow
-with content up to a ceiling that is never below the trigger:
-
-```ts
-const floor = Math.max(desktopMinWidth ?? 0, referenceWidth ?? 200);
-const frameStyle = { minWidth: floor, maxWidth: Math.max(400, floor) };
-```
-
-`desktopMinWidth` is an explicit floor-raiser. It does not cap width, and the
-trigger still wins when it is wider. Changing this default requires re-verifying
-every consumer listed here.
-
-Consumers: `composer/agent-controls/mode-control.tsx`,
-`composer/agent-controls/index.tsx`, `composer/index.tsx`,
-`components/combined-model-selector.tsx`, `components/hosts/host-picker.tsx`
-(including `components/hosts/host-filter.tsx`), `components/branch-switcher.tsx`,
-`components/left-sidebar.tsx`, `components/ui/select-field.tsx` (schedule form),
-`screens/new-workspace-screen.tsx` plus `screens/new-workspace/project-picker.ts`,
-`components/import-session-sheet.tsx`, `screens/workspace/workspace-screen.tsx`,
-`screens/settings-screen.tsx`, and `screens/project-settings-screen.tsx`.
-
-## Gotcha 1 — Android touch hit-test by parent bounds
-
-On Android, a child View whose bounds fall outside its parent's bounds renders
-correctly (with `overflow: visible`, the default) but **does not receive touch
-events**. `ViewGroup.dispatchTouchEvent` filters touches by the parent's hit
-rect first, then iterates children. A touch in the overflowing region never
-reaches the parent, let alone the child. iOS and web do not share this rule —
-iOS hit-test descends into overflowing children, web uses standard CSS pointer
-events. This is the bug that put autocomplete on this path: the popover was
-positioned `bottom: 100%` of its parent and worked on iOS/web for months;
-Android touches sailed straight through to the chat scroll view behind it.
-
-Two escape hatches in the codebase:
-
-- **`Modal`** (combobox, dropdown menu and tooltip on native) — opens a new Android window, so
-  hit-testing starts fresh in that window. If its children use gesture-handler,
-  the Modal owner must wrap its content in a full-height `GestureHandlerRootView`:
-  the app's root does not span Android windows. React context alone does not
-  establish a native gesture root. Side effect: a Modal opening on
-  Android can detach the IME from an underlying TextInput. Fine for combobox
-  (it has its own input) and tooltip (no input). **Not** fine for autocomplete
-  (the composer's input must stay focused so the user keeps typing).
-- **`<Portal>` from `@gorhom/portal`** (hover-card, autocomplete-popover) —
-  hoists the React subtree to a fixed mount point whose bounds cover the
-  screen. Same window, same IME, hit-test works because the new parent is
-  full-screen. This is the right default when you must keep IME attachment.
-  Choose the host by layer: app-global overlays use the root host; content
-  overlays can use the current `FloatingPanelPortalHost` so sliding sidebars
-  cover them.
-
-  Choose Modal vs Portal by whether the underlying input can lose its keyboard.
-
-On web, dropdown menus render into the shared `overlay-root`, not React Native
-Web's `<Modal>`/`<dialog>`. A browser top-layer dialog always paints above
-ordinary portals regardless of `z-index`, which would hide app toasts and
-tooltips behind the menu. The shared overlay scale keeps menus below toasts and
-lets tooltip portals paint above both.
-
-The shared overlay scale is relative for interactive surfaces: a base floating
-panel is below a base modal, while a floating panel rendered from inside a modal
-inherits that modal's layer and paints above it. Wrap portal content in
-`OverlayLayerProvider`; do not assign one global menu z-index. Desktop web
-comboboxes must use `overlay-root` too. Rendering them through React Native
-Web's `<Modal>` puts them in the browser top layer, where no ordinary modal
-portal can cover them.
-
-Painting and keyboard ownership use the same relative layer model. Register
-desktop modal, combobox, and dropdown focus scopes with `useWebOverlayRegistration`; the
-highest painted scope alone receives overlay keys, traps focus, and restores
-focus when it closes. Hover cards register with `manageFocus={false}`: they claim overlay keys without moving or trapping focus on pointer hover. Do not add component-local global Escape listeners: two
-stacked overlays would both close on one keypress.
-
-If an overlay is rendered by a global host rather than beneath its opener in
-the React tree, carry the opener's current layer through the host store and
-restore it with `OverlayLayerProvider`. Otherwise painting and keyboard
-ownership silently reset at the app root. When the opener is a global keyboard
-action and has no component context to carry, resolve the host layer with
-`useGlobalWebOverlayLayer` on its closed-to-open transition. It captures the
-current top registered layer before the new host joins the stack; do not give a
-global dialog a fixed root-derived modal layer.
-
-## Gotcha 2 — Portal breaks lifecycle and coordinate-system inheritance
-
-A Portal escapes Android's hit-test, but it also escapes two things you were
-quietly relying on:
-
-- **Lifecycle.** The portal'd subtree mounts at the app root, not inside your
-  component's natural ancestor chain. When the user navigates away, your
-  component may stay mounted (offscreen, in a tab) — the popover stays with it.
-  Gate `visible` on a screen-focus signal. For panes inside `agent-panel`, the
-  `isPaneFocused` prop already exists and flips on pane switches; pass
-  `visible={isYourOwnVisible && isPaneFocused}`.
-- **Transforms.** `KeyboardShiftProvider` owns the canonical keyboard shift
-  SharedValue, and `useKeyboardShiftStyle()` only adapts that value into
-  translate/padding styles. The composer and chat content must both read that
-  provider-owned value. A portal'd popover is outside the composer tree — it
-  does not get that transform unless you apply it yourself.
-- **Layering.** The default root host renders after app content, so it sits
-  above compact sidebars. Content overlays that must sit below sidebars should
-  use the current `FloatingPanelPortalHost`.
-- **Coordinate systems.** `measureInWindow` gives window coordinates. A Portal
-  renders inside its host, not necessarily at window origin. Position anchored
-  content relative to the host: `anchorRect - hostRect`. This is what
-  `measureFloatingPanelPortalHost()` is for.
-- **React context.** `@gorhom/portal` is not a React portal — a real one keeps
-  context, this one does not. It stores the element and the host renders it, so
-  context resolves at the _host's_ position. Everything provided between
-  `PortalProvider` in `app/_layout.tsx` and your sheet is invisible inside it.
-  This is why app-wide providers wrap `PortalProvider` rather than the reverse.
-
-The fix for transforms is Gotcha 3. The fix for context is Gotcha 7.
-
-## Gotcha 3 — Keyboard layout and portal anchors
-
-`composer/dock` owns the stationary viewport, bottom-anchored surface, composer
-capacity, and keyboard motion for chat, workspace draft tabs, and New workspace.
-Render `<ComposerDock>{contentAbove}{composer}</ComposerDock>` below the header.
-The optional third child is an overlay that moves with the surface. New workspace
-uses `centered` for its existing desktop/tablet form. Hosts never reserve keyboard
-space or translate the composer themselves. Put the dismiss surface behind content
-as a sibling, with `pointerEvents="box-none"` on its content wrapper. A Pressable
-ancestor takes the JS responder on idle Android Fabric and intercepts the stream's
-MOVE events before its native scroll view reaches touch slop. Streaming can hide
-this failure by delaying the responder grant. Native scroll views retain their own
-tap-to-dismiss behavior; unclaimed empty-space taps reach the dismiss sibling.
-On iOS, decorative form containers also need `box-none` (and inert titles/spacers
-need `none`); otherwise their empty padding blocks hit testing of that sibling.
-The shared screen header uses the same dismiss surface. Keep the
-header escape available when a capped draft clips all content above it, since
-iPhone has no system keyboard-dismiss button. Child controls keep their touches,
-and the stream keeps its existing flick-to-dismiss gesture.
-
-The dock's private viewport and capacity model are extracted from chat. The
-app-wide `@/keyboard/shift` module owns shared motion for the dock, portals, streams,
-terminal, explorer, and dialogs. Import only its public entry point: the provider,
-shift hooks, shift style, translate view, settled stream inset, and explorer padding
-policy. Its contexts and reconciliation stay private. Keep `KeyboardShiftProvider`
-at its root mount point outside the portal host when changing dock hosts.
-
-`KeyboardTranslateView` owns visual keyboard motion inside `@/keyboard/shift`. Android uses the
-controller's Reanimated signal. iOS uses its native-driver `Animated.event`
-signal because the stock iOS Reanimated value changes at move start, while
-writing a replacement Reanimated value every frame interrupts UIKit's hide
-animation. Keep this platform choice inside the keyboard module's private platform-specific translate files.
-
-`ComposerDock` always keeps the surface at full height and wraps it in
-`KeyboardTranslateView`. The panel root clips it at the header edge, so rows
-slide under the header on open and out from under it on close. Do not swap the
-dock to keyboard padding at rest. Changing its height creates either a blank
-band or a paused transition when the inverted list updates its viewport.
-
-Do not animate a layout prop through the keyboard transition. On Android
-Fabric, each animated layout update clones the shadow tree and runs Yoga over
-the dock subtree. This measured about 10 ms per frame on the emulator and the
-mounted layouts arrived in bursts every 2–4 frames. A transform does not dirty
-layout. Preserve the translated dock's history scroll range with a far-end
-content inset on the inverted stream list. Update that inset only when keyboard
-motion settles; never drive it per frame.
-
-The translated dock's height is not the composer's available height. Bound the
-composer against the stationary space below the header inside
-`composer/dock`, including its controls and attachments. Reserve the
-keyboard destination at move start on the UI thread. Waiting for a settled JS
-update lets a long draft disappear behind the header during opening. This is a
-boundary-time layout change, not an animated layout prop. Keep the input's
-native intrinsic sizing and internal scrolling. Keep the editing input's
-`defaultValue` current on every edit: Fabric re-measures the Android input from
-the JS text whenever its frame changed, so a stale prop inflates or collapses
-the input (see `packages/app/src/components/ui/text-input/text-input.native.tsx`).
-
-Closing the keyboard moves the composer; it does not enlarge its capacity. The
-viewport keeps the last keyboard reservation until the next opening replaces
-it, so a capped draft keeps one height through every keyboard transition
-instead of expanding on close and shrinking again on open.
-
-Keep setup fields out of the composer's shrink chain. New workspace supplies its
-setup fields as the first dock child so they move up under the header as the draft
-grows. Putting the fields and composer in one bounded, shrinkable column made
-Yoga split the shortage between them: rows vanished behind the composer while
-the input lost lines at the same time. Keep that separation inside the dock,
-shared by every phone host. The centered tablet form caps the complete block
-for header clearance, but reserves the composer's own capped height before
-shrinking the setup scroll view. The form must not take editing space from the
-composer.
-
-Move the stream and composer together through `ComposerDock`. Do not translate
-them independently.
-
-`KeyboardShiftProvider` owns the normalized shift used for settled insets and
-portal geometry, plus the `isMoving` worklet value. It reconciles native
-animation-end events because the controller can retain a nonzero value after
-the keyboard closes.
-
-Measure portal anchors while the dock is at rest. If a popover opens during
-motion, re-measure when `isMoving` settles. `measureInWindow` includes the
-dock's current layout and transform. Snapshot the shift at measurement time and
-apply only the subsequent shift delta to the animated `bottom`. Adding the full
-shift moves the portal twice and can place it over the composer controls.
-
-The provider also reconciles iOS from the controller's native `onEnd` event.
-The controller's stock iOS shared values update at move start and during an
-interactive move, but not at the terminal event, so JS contention can otherwise
-leave the last height/progress pair stuck in either the open or closed state.
-Keep that terminal reconciliation on the UI thread; a later focus or blur must
-not be required to repair the offset.
-
-## Gotcha 4 — Host-relative positioning before platform offsets
-
-The generic anchored-overlay rule is:
-
-1. Measure the anchor with `measureInWindow`.
-2. Measure the Portal host with `measureFloatingPanelPortalHost(hostName)`.
-3. Position with anchor coordinates relative to the host:
-
-```ts
-left = anchorRect.x - hostRect.x;
-bottom = hostRect.height - (anchorRect.y - hostRect.y) + offset;
-```
-
-Do this before adding any platform offset. If anchor and host are both measured
-with `measureInWindow`, Android's status-bar coordinate behavior cancels out.
-Only add a status-bar offset when the render surface is not measured in the same
-coordinate system. See `tooltip.tsx` for that separate case.
-
-## Gotcha 5 — The two-measurement flash
-
-If your popover needs `top` (or `left`) computed from both:
-
-- the anchor's screen position (`anchorRect` from `measureInWindow`), **and**
-- the popover's own size (`contentSize` from `onLayout`),
-
-then a naïve implementation will flash through three positions on every open:
-
-1. **Frame 1** — render with `top: -9999` (or any placeholder) while waiting
-   for either measurement. Wrapper has no `width`, so the inner content lays
-   out at its natural (often narrow) intrinsic width.
-2. **Frame 2** — `anchorRect` lands. Wrapper now has `width: anchorRect.width`.
-   But the stale `onLayout` from frame 1 has already set `contentSize` to the
-   narrow-width dimensions. `top = anchorRect.y - wrongHeight - gap` — visible
-   at the wrong spot.
-3. **Frame 3** — real `onLayout` fires with the correct width. `contentSize`
-   updates. Position snaps to the right place.
-
-The visible jump in frame 2 is the flash. Two pieces solve it, and you need
-both:
-
-- **Do not mount the floating content until `anchorRect` is set.** Return
-  `null` until then. This prevents the bad-width onLayout from happening at
-  all.
-- **Once `anchorRect` is set but `contentSize` isn't, render the wrapper with
-  the final width but `opacity: 0`.** The first visible paint is at the
-  correct position. This is the combobox pattern —
-  `shouldHideDesktopContent` at `combobox.tsx:481, 876`. **Do not** use
-  `top: -9999` as the placeholder; the layout work still happens at -9999 and
-  any subsequent state-flash is visible when you flip back.
-
-The "render invisible to measure, then reveal" pattern is the canonical
-solution to chicken-and-egg positioning in this codebase. Reach for it before
-anything fancier.
-
-## Gotcha 6 — Bottom sheet refs are not lifecycle truth
-
-`@gorhom/bottom-sheet` modals churn their imperative ref while presenting and
-dismissing. Do not treat `ref != null` as permission to call `present()`, and do
-not treat `ref == null` as the sheet being closed. The user-visible lifecycle is
-the desired `visible` prop plus the sheet callbacks (`onChange(-1)`,
-`onDismiss`).
-
-If a user closes a sheet with the backdrop or a pan gesture, the sheet may detach
-and reattach before React state has acknowledged `visible=false`. Re-presenting
-on that attach races Gorhom's dismiss path and leaves the modal unable to reopen.
-Track an explicit phase (`closed` / `presenting` / `presented` / `dismissing`) and
-ignore ref churn while dismissing.
-
-Do not treat `onChange(-1)` as a close by itself. In a stacked
-`BottomSheetModal`, `-1` can also mean the sheet is temporarily hidden under
-another pushed sheet. Close React state from `onDismiss`; use `onChange` only to
-track phase.
-
-All sheets use the app-wide Gorhom modal provider through `IsolatedBottomSheetModal`. This
-includes native centered dialogs: separate React Native Modals cannot present a root-owned
-sibling dialog over an existing iOS presenter.
-
-The wrapper must give Gorhom an object ref. Gorhom accepts a callback ref at the React boundary
-but stores it in the modal queue and later reads `.current`; provider dismissal, replacement,
-and restoration then silently do nothing. Callers may use callback refs on the wrapper, which
-forwards commands to the current Gorhom handle.
-
-Request a backdrop with `backdropOpacity`; do not install a caller-owned backdrop. On web,
-Gorhom's default backdrop closes its own sheet, even when another modal is above it. Its animated
-pointer-event changes can expose a lower backdrop during a transition. The shared web backdrop
-keeps its press target until portal teardown and asks the provider to dismiss the top modal.
-Gorhom's presentation queue remains the authority; backdrop mount order is irrelevant. Native
-retains Gorhom's gesture backdrop and the same push/replace presentation semantics.
-
-## Gotcha 7 — A sheet cannot read context from its call site
-
-React cannot copy contexts reflectively, so the only way across the teleport in
-Gotcha 2 is to render the providers a second time, with values captured on the
-near side where they are still readable. `IsolatedBottomSheetModal` takes a
-`contextBridge` for exactly that:
-
-```tsx
-const contextBridge = useCallback<ContextBridge>(
-  (content) => <ThingContext.Provider value={thing}>{content}</ThingContext.Provider>,
-  [thing],
-);
-```
-
-The prop is **required**, and `null` is a real answer. A sheet whose content
-needs nothing local should have to say so, because the failure mode is silent
-until someone adds a `useContext` deep inside and it throws on device only —
-never on web, where the desktop path uses a real portal. `menu-surface.tsx`
-bridges the menu's two contexts; the rest pass `null`.
-
-Wrapping providers _around_ the modal does nothing. They land on the wrong side.
-
-## Recipe for a new anchored panel
-
-Before you write a new one, ask:
-
-1. **Can the underlying input lose its keyboard?** If yes, use Modal (simpler).
-   If no, use Portal.
-2. **Does the panel need to dismiss on screen change?** Almost always yes —
-   gate `visible` on an upstream focus prop (`isPaneFocused` or similar).
-3. **Is the panel rendered in a Portal host?** Measure the host too. Never use
-   raw window coordinates as local Portal coordinates.
-4. **Does the panel sit above something that moves with the keyboard?** If
-   yes, slave a Reanimated transform to the same SharedValue (Gotcha 3).
-   If no, you can probably skip the transform entirely.
-5. **Will the panel's content height vary?** If yes, you need both
-   `anchorRect` and `contentSize` for positioning → apply Gotcha 5 (return
-   null until anchor, then opacity-0 until contentSize). If no — content has
-   a known fixed max height — you might be able to use bottom-anchored
-   positioning (`bottom: windowHeight - anchor.y + gap`) and skip the
-   `contentSize` round-trip entirely. **But only if the height is genuinely
-   bounded**. Verify before you commit.
-
-Then copy the closest canonical file and trim.
-
-Building a **menu** rather than a bare panel? Don't. Use the menu engine — it already solves
-everything above, plus submenus, sheets, and hover intent. See [menus.md](menus.md).

docs/forge-providers.md

@@ -1,225 +0,0 @@
-# Adding a Git Forge to Paseo
-
-Paseo's forge layer is a registry/manifest system. A forge is a runtime concern:
-shared protocol messages carry neutral/open facts, the server adapter owns
-behavior, and the app owns bundled presentation/runtime interpretation.
-
-The maintainer litmus test is the rule of thumb:
-
-> Adding a new forge means adding files in a new directory/module that implement
-> an interface, plus one entry in the centralized registry/manifest for that
-> package.
-
-## The Three Registrations
-
-For forge `acme`, the expected end state is:
-
-1. **Protocol manifest** - optional, only when the forge should be presented by
-   shared manifest data. Add one `ForgeDefinition` to
-   `packages/protocol/src/forge-manifest.ts`.
-
-2. **Server adapter** - add `packages/server/src/services/acme-service.ts`
-   implementing `ForgeService`, any adapter-owned fact types/guards/constants
-   beside it, and one `defaultForgeRegistry` entry in
-   `packages/server/src/services/forge-registry.ts`.
-
-3. **App modules** - a forge splits into a pure logic half and a view half so
-   logic consumers (URL builders, merge-capability, native checks, and the
-   Node-based e2e harness) never pull the client rendering stack:
-   - `packages/app/src/git/forges/acme.ts` - logic: `id`, optional `urlGrammar`
-     (source links and pasted issue/change-request reference paths), optional
-     `facts` (schema, merge-capability, native-check fallbacks). No
-     React/React-Native imports. Register in `CLIENT_FORGE_LOGIC_MODULES` in
-     `packages/app/src/git/forges/index.ts`.
-   - `packages/app/src/git/forges/acme.view.tsx` - view: `icon` (SVG component
-     under `packages/app/src/components/icons/`), optional `brandColor`, optional
-     `paneContributions`. Register in `CLIENT_FORGE_VIEW_MODULES` in
-     `packages/app/src/git/forges/view.ts`.
-
-There should be no protocol typed-union arm, no central app icon/color/url/facts
-map, and no central server union of known forge facts.
-
-## Protocol
-
-`forgeSpecific` on PR status is an open envelope:
-
-```ts
-z.object({ forge: z.string() }).passthrough();
-```
-
-The `forgeSpecific.forge` field is a **facts-family tag**, not the workspace
-brand id. Gitea, Forgejo, and Codeberg can all emit `forgeSpecific.forge ===
-"gitea"` when they share the same facts shape, while top-level `status.forge`
-keeps the brand id (`"gitea"`, `"forgejo"`, `"codeberg"`).
-
-Protocol does not validate per-forge fact fields. Consumers that understand a
-facts family validate at runtime with their own schema/guard. Unknown or
-schema-mismatched facts render neutrally instead of failing the whole message
-parse. This is the version-skew win: an old client can receive facts from a
-newer forge and still show the PR/MR in a neutral state.
-
-Check results keep a stable normalized `status` for aggregation and an optional
-open `traits: string[]` for composable forge-neutral refinements such as
-`manual`, `action_required`, and `warning`. Consumers ignore unknown traits and
-fall back to `status`; `rawStatus` preserves provider-native detail. Do not add
-provider vocabulary to the normalized status union. Producers and the
-presentation layer share the trait constants in
-`packages/protocol/src/check-traits.ts` — use those instead of string literals
-so classification and emission cannot drift apart.
-
-Shipped GitHub compatibility stays separate:
-
-- The forge compatibility layer first shipped in `v0.2.0-beta.1`. Its initial
-  six-month cleanup target is `2027-01-17`, after supported client and daemon
-  floors reach stable `v0.2.0`.
-- `status.github` remains accepted for released peers.
-- The server keeps the `COMPAT(forgeSpecific)` mirror that copies GitHub facts
-  into `status.github` for older clients.
-- Do not add a compatibility shim unless a released peer (<= 0.1.102) can
-  actually produce the state.
-
-## Server
-
-The server-wide status type only promises:
-
-```ts
-type ForgeSpecificStatusFacts = { forge: string } & Record<string, unknown>;
-```
-
-Adapter-owned files define the typed shapes and guards, for example
-`github-facts.ts`, `gitlab-facts.ts`, and `gitea-facts.ts`. The adapter can keep
-strong internal types for construction and command guards, but shared server
-code must not grow a central list of forge fact arms.
-
-Register the adapter in `defaultForgeRegistry` with:
-
-- `createService`
-- `matchesHost` from manifest `cloudHosts`
-- `probeHost` when self-hosted/Enterprise detection is supported
-
-Current change-request lookup uses two identities deliberately:
-
-- An open PR/MR belongs to the checkout when its head branch and head repository
-  match. Its remote head SHA may differ because the checkout can be ahead,
-  behind, or contain commits that have not been pushed yet.
-- A merged or closed PR/MR belongs to the checkout only when its recorded head
-  SHA exactly matches the checkout's current `HEAD`. Branch names are reusable;
-  selecting the newest terminal request by branch alone can silently attach an
-  old promotion or feature request to new work.
-
-Thread the checkout head SHA through adapter cache and poll identities as well
-as the lookup itself. Otherwise a commit made on the same branch can inherit the
-previous commit's cached terminal status until the cache expires.
-
-Cloud hosts in the manifest are a bounded public-host list, not a self-host
-allowlist. Self-hosted detection is a trust gate: Paseo only talks to a forge
-host that is either a known cloud host or one the CLI is already authenticated
-to. Adapter probes must not make anonymous HTTP requests to remote-derived
-hosts, and adapters must not route credentials to an unauthenticated host.
-
-## App
-
-Each app forge splits into two modules so pure logic never imports the client
-rendering stack:
-
-`acme.ts` exports a `ClientForgeLogicModule`:
-
-- `id`
-- optional `urlGrammar` (including `referencePaths` for composer auto-attachment)
-- optional `facts` registration (schema, merge-capability, native-check fallbacks)
-
-`acme.view.tsx` exports a `ClientForgeViewModule`:
-
-- `id`
-- `icon`
-- `brandColor` (`null` for neutral; GitHub intentionally uses `null`)
-- optional `paneContributions`
-
-Two registries live under `packages/app/src/git/forges/`:
-`CLIENT_FORGE_LOGIC_MODULES` (`index.ts`) drives URL grammar, merge-capability
-derivation, and native fallback checks; `CLIENT_FORGE_VIEW_MODULES` (`view.ts`)
-drives icon/color lookup and PR-pane contributions. Logic consumers must import
-the logic registry only — importing the view registry (or a `.view.tsx` module)
-from a logic path pulls react-native and breaks the Node-based e2e harness.
-
-Per-forge brand colors live on the module, not in `styles/theme.ts`. Use the
-Unistyles-safe pattern from `docs/unistyles.md`: no `useUnistyles()`. Brand icon
-call sites use `withUnistyles` and a `uniProps` mapping such as:
-
-```ts
-(theme) => ({ color: theme.colorScheme === "light" ? colors.light : colors.dark });
-```
-
-Facts modules use one source of truth: a Zod schema. Helpers like
-`defineForgeFacts`, `defineNativeFallbackCheck`, and `definePaneContribution`
-derive guards from `schema.safeParse` and re-parse before invoking typed
-derivers/renderers. That keeps typed derivers away from the open wire envelope.
-
-## Checklist
-
-To add `acme`:
-
-1. Add `acme` to `FORGE_DEFINITIONS` if the shared manifest should know its
-   label, nouns, icon kind, sign-in CLI, or cloud hosts.
-2. Add `acme-service.ts` implementing `ForgeService`.
-3. Add `acme-facts.ts` beside the adapter if it reports native facts.
-4. Add one `defaultForgeRegistry` entry.
-5. Add `packages/app/src/git/forges/acme.ts` (logic) and
-   `packages/app/src/git/forges/acme.view.tsx` (view).
-6. Add one `CLIENT_FORGE_LOGIC_MODULES` entry (`index.ts`) and one
-   `CLIENT_FORGE_VIEW_MODULES` entry (`view.ts`).
-7. Add/update the icon component only if the client bundle should show a brand
-   mark.
-8. If the forge's CI/data model does not fit an existing required
-   `ForgeService` field, widen the shared interface (plus the protocol schema
-   and its guards) instead of faking a value — e.g. Gitea Actions runs carry no
-   check-run id, so `GetCheckDetailsOptions.checkRunId` became optional with
-   `workflowRunId` as the alternative address. Expect this step to touch
-   `forge-service.ts`, `messages.ts`, and the call-site guards of the other
-   adapters. Widening a shared field is not forge-local: it also affects the
-   already-shipped forges/GitHub call sites and the capability-gated RPC (e.g.
-   `forgeCheckDetails`), so verify every consumer rather than assuming the change
-   only reaches the new adapter.
-9. Run targeted tests: manifest/registry/resolver, the adapter test, protocol
-   checkout PR schema, app forge URL/presentation tests, app merge capability,
-   and any PR-pane native data tests touched.
-
-Run `npm run typecheck` after each implementation slice. If protocol or client
-declarations are stale, run `npm run build:client`; if server/CLI declarations
-are stale, run `npm run build:server`.
-
-## Gotchas
-
-- GitHub is a normal registry entry plus released compatibility shims. Keep all
-  real shims tagged with `COMPAT(name)`.
-- Gitea-family facts use `forgeSpecific.forge === "gitea"` even when the
-  top-level brand is Forgejo or Codeberg.
-- Gitea's legacy Actions task endpoint cannot filter by commit, may enforce a
-  page size below the requested limit, and omits rerun-attempt numbers. Walk a
-  bounded number of pages using `total_count` and filter locally. Preserve
-  ambiguous same-run tasks: display names are not stable job identities, so
-  name-based deduplication can hide a real failure.
-- A blocked Gitea Actions task is not necessarily manual: only add the
-  `action_required` trait when the matching run metadata reports
-  `need_approval`.
-- Brand icons are bundled React components, so they cannot come from protocol
-  manifest data.
-- Source URL grammars are app-side because blob/tree path syntax is
-  forge-specific. If a forge has no grammar, omit the "Open on ..." source link
-  rather than constructing a wrong URL.
-- Pasted issue/change-request URL recognition is also app-side and registry
-  driven. Put the forge's route infixes in `urlGrammar.referencePaths`; the
-  neutral extractor matches the pasted host and full repository path against
-  the current remote before it invokes cwd-routed forge search. Do not add a
-  central forge switch or guess a self-hosted Gitea-family brand from URL shape.
-- GitLab pipeline status constants belong to the GitLab adapter/client module,
-  not protocol.
-- GitLab `manual` jobs need `allow_failure` to distinguish optional gray jobs
-  (`manual`) from blocking jobs (`manual` plus `action_required`). A failed
-  allowed-failure job carries the `warning` trait, and `canceling` remains active
-  until GitLab reports a terminal status.
-- GitHub PR polling owns one account-wide GraphQL budget. Coordinate retained
-  targets per host, batch their reads, and stop until GitHub's reset time when
-  the reserve is exhausted. Never add a per-target GitHub request to the poll
-  path. Resolve fork PRs through their parent repository without abandoning the
-  shared batch.

docs/forms.md

@@ -1,112 +0,0 @@
-# Forms
-
-The paved road for building forms in the app. The schedule form is the golden
-example; when building or fixing any form, copy its shape, not the shape of
-whatever screen you happen to be near.
-
-Golden example files:
-
-- `packages/app/src/schedules/schedule-form-model.ts` (+ `.test.ts`) — the model
-- `packages/app/src/schedules/use-schedule-form-model.ts` — model lifetime adapter
-- `packages/app/src/schedules/use-schedule-form-provider-snapshot.ts` — async input adapter
-- `packages/app/src/components/schedules/schedule-form-sheet.tsx` — render + intent dispatch
-- `packages/app/src/schedules/aggregated-schedules.ts` / `hooks/use-schedules.ts` — load-state gating
-- `packages/app/e2e/schedules-*.spec.ts` — the behavioral contract
-
-## The form model
-
-Every non-trivial form gets a **plain TypeScript model** — zero React imports:
-
-- `openXxxForm(snapshot)` **constructs** a fresh instance from declared inputs
-  (mode, the record being edited, hosts, defaults). Edit mode seeds every value
-  AND display from the snapshot — never from a previous instance.
-- **Commands** mutate (`setHost`, `setProject(value, display)`, `setModel`, …).
-  Derived state (disclosure, canSubmit, displays) is recomputed inside the
-  model on every publish.
-- `close()` destroys the instance. `subscribe`/`getState` feed one
-  `useSyncExternalStore` in the component.
-
-The component renders state and dispatches intent. That is all it does.
-
-### Lifecycle rules (each one killed a real shipped bug)
-
-1. **Fresh mount per open.** The sheet returns `null` when not visible and
-   mounts the open form with a `key` derived from mode + record identity.
-   A long-lived component instance shared across create/edit is how edit
-   contaminated create.
-2. **Construct the model ONCE per mount** — `useState(() => openXxxForm(snapshot))`.
-   NEVER `useMemo(() => open(...), [snapshot])`: the snapshot's identity depends
-   on live data (projects, hosts, preferences), and any background churn — e.g.
-   a scheduled run creating a workspace — would reconstruct the model and wipe
-   the user's in-progress input.
-3. **Late data is an explicit model input, not a reconstruction.**
-   `applyProviderSnapshot(serverId, …)`, `applyProjectTargets(…)`,
-   `applyHosts(…)`. Adapters pipe identity changes into these with mechanical
-   effects. Input plumbing is fine; orchestration effects are not — the sheet
-   itself has zero `useEffect`/`useRef`, and that is the target for every form.
-4. **Resolution is explicit model state, per host** (`idle | pending |
-complete`), keyed off the opened snapshot's serverId. Waiting for data is a
-   state you can render, not an effect race.
-5. **Displays are owned state.** The selected option's label is captured at
-   selection/seed time (`setProject(value, display)`), never re-derived from a
-   live options list — list churn must not flicker or blank a selection.
-6. **Disclosure is derived in the model** from user intent
-   (host → project → model → thinking/mode), so fields cannot pop in from
-   cache timing.
-
-## Form kit
-
-- Compose `Field` / `SelectField` / `FormTextInput` / `SegmentedControl` /
-  `Switch` from `components/ui/`. Geometry (heights, padding, radii, focus/hover
-  states) is owned by `components/ui/control-geometry.ts` — controls never
-  declare their own, and screens never nudge global component styles to align
-  a row.
-- Every text field consumes `EditingTextInput`, directly or through a UI
-  wrapper. The editing surface owns in-progress text; React observes committed
-  edits through `onChangeText`, and programmatic mutations use the input's
-  `replaceText` command. Its props omit `value` and `defaultValue`, web IME
-  candidates stay unpublished until composition commits, and lint rejects raw
-  React Native `TextInput` imports outside the primitive.
-- The form declares one size for all fields: `sm` on desktop, `md` compact
-  (`useIsCompactFormFactor`).
-- Availability hierarchy: a field whose capability doesn't apply is **hidden**
-  (isolation on a non-git project — same gating as New Workspace), not rendered
-  disabled with an explanation. Disabled-with-a-reason `hint` is only for
-  transient states the user can resolve.
-- Copy is opt-in and rare. No hint/subtext unless the maintainer approved the
-  exact string; validation errors are the exception. State a fact (like the
-  timezone) once — never in a preview line AND a helper line.
-- `useUnistyles` is banned (see docs/unistyles.md); lint enforces.
-
-## Settings rows
-
-Use the named components from `@/components/settings` for settings cards and controls.
-`SettingsCard` owns row separators; `SettingsRow` accepts custom content. Heading-only screens
-can import `SettingsGroup` and `SettingsSection` directly from their modules in
-`@/components/settings/headings/`.
-The plugin UI entry exposes the same components; keep them independent of storage and routing.
-
-## Data gating
-
-Aggregate hooks return a discriminated load state:
-
-```ts
-type AggregateLoadState<T> =
-  | { status: "connecting" } // an answer may still be pending
-  | { status: "loading" }
-  | { status: "loaded"; data: T[] };
-```
-
-Empty states are only typeable inside `loaded` — a fetch that "succeeded"
-before hosts connected is `connecting`, not empty. Query keys carry real fetch
-inputs (host set, connection statuses), never synthetic version counters.
-
-## Anti-patterns (reject in review on sight)
-
-- `useEffect` choreography impersonating construct/hydrate/resolve/destroy.
-- One mounted form instance serving create and edit.
-- `useMemo`-keyed model construction on live-data identity.
-- Selected labels derived from live query lists.
-- `isLoading`/`isEmpty` boolean bags where a load-state union belongs.
-- Conditional mounting of hint/error rows that shifts layout (subtext renders
-  only when present, but the pattern for that lives in `Field`, not ad hoc).

docs/glossary.md

@@ -1,63 +0,0 @@
-# Paseo Glossary
-
-Authoritative terminology. UI label wins. Don't invent synonyms; use what's here.
-
-- **Project** — A stable, exact selected-root record. Its host-local `projectId` is an opaque `prj_<16 hex>` value. Its persisted `projectKey` is an opaque equivalence key that may group the logical project across hosts. A normalized Git remote is the current key producer, but consumers must not parse or rederive it. Git facts can update mutable kind and grouping metadata but never the ID, root, or default display name. UI: "Project" / "Add project". Forbidden: "Repo", "Repository" as UI label.
-- **Workspace** — One concrete `cwd` on one daemon, with git state; belongs to exactly one project. Its `id` is opaque workspace identity; its `cwd` is the filesystem directory. UI: "Workspace". Code: `WorkspaceDescriptorPayload` (`packages/protocol/src/messages.ts:2178`). Don't confuse with: Branch (one branch can back many workspaces via worktrees). Forbidden: "Folder", "Directory" as UI label.
-- **Archive workspace** — Removes one workspace from active use and archives everything it owns. UI, CLI, and MCP always say "Archive workspace", regardless of backing. The daemon leaves ordinary directories intact and removes a Paseo-owned worktree only when no active workspace still references it.
-- **Workspace kind** — `"directory" | "local_checkout" | "worktree"`. The git-derived, persisted property of a workspace, used across its lifetime (archive safety, sidebar, grouping). Derived from the cwd's git reality by `deriveWorkspaceKind` in `workspace-registry-model.ts`, not stored from a user choice. Don't confuse with **Isolation** (the create-time intent).
-- **Isolation** — Create-time choice for a new workspace: reuse the existing checkout (**Local**) or cut a dedicated git worktree (**New worktree**). A transient setup input, also remembered as a create-form preference; it is not a workspace property. UI: "Isolation" control on the New Workspace screen. Code: `isolation` (`"local" | "worktree"`), `useWorkspaceIsolation` (`packages/app/src/screens/new-workspace-screen.tsx`); persisted as `FormPreferences.isolation` (`packages/app/src/create-agent-preferences/preferences.ts`). Distinct from **Workspace kind**, which is the git-derived property the intent produces (Local → `local_checkout` or `directory` by git-ness; New worktree → `worktree`). On the wire it is the create request's `source.kind` (`directory | worktree`, `packages/protocol/src/messages.ts:1693`).
-- **Agent** — See **Agent session**. UI still says "Agent" / "New Agent" in places, but moving toward **Agent session** as the canonical term. Code: `AgentSnapshotPayload` (`packages/protocol/src/messages.ts:608`). Forbidden: "Task", "Job", "Run".
-- **Daemon** — Local Paseo server process; identified by `serverId`. UI: "Daemon" (system contexts only). Code: `serverId` in `ServerInfoStatusPayloadSchema` (`packages/protocol/src/messages.ts:1936`), `DaemonClient` (`packages/client/src/daemon-client.ts`).
-- **Host** — Client-side connection profile pointing at a daemon; bundles one or more `HostConnection`s. UI: "Host" / "Add host" / "Switch host". Code: `HostProfile` (`packages/app/src/types/host-connection.ts:37`). Forbidden: "Connection" (means `HostConnection`, not host).
-- **Host badge** — The item on a sidebar workspace row's meta row naming which host that workspace lives on. Three things gate it, and they compose as a lattice rather than competing: the sidebar must span more than one host (automatic), **Show → Host** in the sidebar's display preferences must be on (global, all hosts at once), and then that host's own display mode decides _how_ it draws — **Name** / **Icon only** / **Hidden**. Name, color, and display mode are per-host, per-device, and live client-side on `HostProfile.appearance`; nothing about it reaches the daemon. Never add a fourth way to hide it. UI: the "Appearance" group on a host's settings page, and the "Show" submenu in the sidebar's display preferences. Code: `selectHostBadges` (`packages/app/src/hosts/appearance.ts`) takes the first two as its `enabled` input; `WorkspaceMetaRow` (`packages/app/src/components/sidebar/workspace-meta-row/index.tsx`) draws it. Don't confuse with **Status pill**, which reports state rather than identity.
-- **Project host entry** — One row in a project for a single (project, daemon) pair, aggregating that daemon's workspaces in the project. Internal. Code: `ProjectHostEntry` (`packages/app/src/utils/projects.ts:11`). Don't introduce "Checkout" as a synonym.
-- **Placement** — One workspace's stable foreign-key relationship to its project plus its git checkout snapshot. Internal. An explicit creation `projectId` is authoritative when active.
-- **Branch** — Plain git branch. UI: "Switch branch". Code: `currentBranch` in `WorkspaceGitRuntimePayloadSchema` (`packages/protocol/src/messages.ts:2136`); `BranchSwitcher` (`packages/app/src/components/branch-switcher.tsx`).
-- **Forge** — Git hosting service behind Paseo's change-request features: GitHub, GitLab, Gitea, Forgejo, or a future registered adapter. Code: `ForgeService`, `forge-registry`, `forge-resolver`. Use `forge` for internal abstraction and registry IDs; use concrete forge names only when a behavior or RPC is forge-specific.
-- **Change request** — Forge-neutral term for a proposed branch-to-branch code change. UI normally renders the forge noun instead: GitHub/Gitea/Forgejo "PR", GitLab "MR". Code: `forge_change_request` attachments, `checkoutSource: { kind: "change_request" }`, and PR/MR status payloads.
-- **MR** — GitLab merge request. UI label for GitLab change requests only; do not use MR for GitHub/Gitea/Forgejo.
-- **Worktree** — Paseo-managed git worktree (`~/.paseo/worktrees/{name}`); also a `workspaceKind` value. User-facing creation treats it as the `worktree` workspace isolation choice. Code and `paseo.json` retain worktree terminology for git lifecycle implementation. Forbidden: "Checkout" as a product synonym.
-- **Repository / Remote** — Internal Git observations. They may produce mutable kind, branch, and project-grouping metadata but never the host-local project ID, root, display name, or workspace membership. No UI label.
-- **Sidebar items** — The configurable entries of the app sidebar, in two sections. Header: the rows at the head of the sidebar — New workspace, History, Search, Schedules, and plugin header items. Footer: the full-width rows between Add project and the footer icon row — Usage and plugin footer items. Add project and the icon row (Hosts, Help and support, Settings) are fixed and are not sidebar items. A plugin item may render several rows, such as one per bot; it is still one item that moves and hides as a block. Each section's order and visibility is one per-device preference (`AppSettings.sidebarNavItems`, `AppSettings.sidebarFooterItems`); every item may be off. UI: the Header and Footer cards on the Sidebar settings page. Code: `packages/app/src/sidebar-nav/model.ts` resolves a section, and the sidebar (`components/sidebar/sidebar-nav-rows.tsx`, the footer in `components/left-sidebar.tsx`) and the settings page (`screens/settings/sidebar/sidebar-nav-section.tsx`) read it through `useSidebarNavItems(section)`. Never hardcode one of these entries or add a second place that decides which ones show. Don't confuse with **Explorer sidebar**.
-- **Explorer sidebar** — The dedicated navigation dock containing the Files and Changes trees. UI: "Explorer sidebar". Code: `packages/app/src/workspace-tabs/explorer-sidebar.ts`; persisted pane identifiers retain the `explorer` spelling. See [explorer-sidebar.md](explorer-sidebar.md).
-- **Side pane** — An ordinary right-side workspace pane used for content opened beside the user's work. It closes and participates in workspace splits like every other main-host pane. See [explorer-sidebar.md](explorer-sidebar.md#side-pane). Forbidden: "Side panel".
-- **Directory-backed surface** — A right-sidebar surface whose content is determined by the workspace's `cwd`, so two workspaces on the same directory see identical content: git diff/status, forge change-request info, file preview/explorer contents. Keyed by `(serverId, cwd)`, never `workspaceId`. See [architecture.md](architecture.md#right-sidebar-boundary-directory-backed-vs-workspace-owned).
-- **Workspace-owned state** — Per-workspace state that never leaks to a same-`cwd` sibling: tabs, agents, terminals, panes, title, plus review drafts, diff-mode overrides, composer attachments, and file-explorer open/expand state. Keyed by `workspaceId` (`cwd` only as a fallback for old payloads). See [architecture.md](architecture.md#right-sidebar-boundary-directory-backed-vs-workspace-owned).
-- **Workspace status bucket** — Aggregate activity signal for a workspace row. Same-`cwd` workspaces intentionally share agent and terminal status buckets, while tab, agent, and terminal visibility remains scoped by `workspaceId`.
-- **Agent session** — One running instance of an agent inside a workspace (one provider, one model, one cwd, one timeline). The conceptual unit; in the UI this opens as a tab. Moving toward this as the canonical term over "Agent". Code: `AgentSnapshotPayload` (`packages/protocol/src/messages.ts:608`).
-- **Session** — Two senses: (a) per-client connection to a daemon, internal; (b) user-facing agent session, see **Agent session**. Code: `Session` (`packages/server/src/server/session.ts`) for (a). Don't confuse with: provider-side agent session log.
-- **Profile** — Internal name for the persisted shape of a host. Code: `HostProfile` (`packages/app/src/types/host-connection.ts:37`). Never user-facing. Three other things are called "profile" in this codebase, so always qualify: **Agent profile**, **Terminal profile**, and the provider aliases in [custom-providers.md](custom-providers.md). Bare "profile" is forbidden in UI copy.
-- **Agent profile** — A named launch bundle: provider, model, mode, thinking option, feature values, and free-text notes. Applying one writes those values into the **Agent controls** and is then forgotten — there is no selected profile, no default profile, and no drift tracking. The notes are written for orchestrating agents and are what the `list_profiles` MCP tool surfaces. Stored host-wide in daemon config as `agentProfiles`. UI: "Agent profiles". Code: `AgentProfile` (`packages/protocol/src/messages.ts:161`). Carries no system prompt, because a per-agent system prompt can only be set at creation. Forbidden: "Favourite", which this replaced.
-- **Terminal profile** — A named shell command a terminal can launch. Stored host-wide in daemon config as `terminalProfiles`. UI: "Terminal profiles". Code: `TerminalProfile` (`packages/protocol/src/messages.ts:135`), `resolveTerminalProfiles` (`packages/protocol/src/terminal-profiles.ts`). Also selectable as a New Workspace launch target, where the alternative is the chat agent.
-- **Provider** — Agent backend (Claude Code, Codex, Copilot, OpenCode, Pi, Oh My Pi). UI: "Provider". Code: `ProviderSnapshotEntry` (`packages/protocol/src/messages.ts:198`).
-- **Usage source** — Plugin registration that discovers accounts and fetches plan usage. Code: `UsageSourceRegistration` (`packages/plugin/src/server/usage.ts`).
-- **Report ID** — Stable daemon-composed identity for one source account: `<sourceId>:<accountKey>`. The source owns the account key; clients treat the whole ID as opaque. Code: `UsageReportEntry.id` (`packages/protocol/src/messages.ts`).
-- **Usage report** — A source's normalized usage for one account, including status and optional windows, balances, and details. Its entry carries the Report ID, account label, and fetch time. Each report renders as one card in the Usage modal, in host Settings, and in an agent's context window details (a hover card on desktop web, a tooltip on native wide screens, a sheet on compact ones), which show only the account that agent runs under, without pins. The hover card and the sheet have Refresh; the native tooltip takes no presses. Code: `UsageReport` (`packages/plugin/src/server/usage.ts`), `UsageCard` (`packages/app/src/usage/card.tsx`), `AgentUsage` (`packages/app/src/usage/agent-usage.tsx`).
-- **Usage (sidebar item)** — The sidebar footer item showing each pinned window's source icon and percent, hidden while no pinned window has data (the footer's Usage icon remains available); both entry points open the Usage modal over the current screen: a dialog on wide layouts, a bottom sheet on compact ones. Usage has no route of its own. Off until the user turns on **Summary in sidebar** (Usage Settings) or the Usage row in Settings > Sidebar; window rows pin only while it is on, and saved pins come back when it is turned on again. A pin is `{ sourceId, windowId }` and shows once per account of that source. Pins and the used/remaining choice are one per-device preference (`AppSettings.usage`) that every usage surface follows. It reads the active workspace's host, else the first connected host with usage sources. Code: `packages/app/src/usage/sidebar-item.tsx`, `usage/usage-modal.tsx`, `usage/pinned.ts`, `usage/preferences.ts`.
-- **Model** — A specific LLM offered by a provider. UI: "Model" / "Select model". Code: `AgentModelDefinition` (`packages/protocol/src/messages.ts:187`).
-- **Tab** — UI surface representing one session inside a workspace. Not a conceptual unit; use **Agent session** when talking about the model. Code: `WorkspaceTabDescriptor` (`packages/app/src/screens/workspace/workspace-tabs-types.ts`).
-- **Terminal** — Workspace-scoped PTY shell streamed over the binary mux channel. UI: "Terminal". Code: `TerminalStreamFrame` (`packages/protocol/src/terminal-stream-protocol.ts`).
-- **Workspace script** — A named command a workspace can run, declared in `paseo.json`. Two types: `service` and `script` (a command that runs and finishes). UI: "Scripts" for the panel and the menu, both of which list either type. Code: `WorkspaceScriptPayload` (`packages/protocol/src/messages.ts:3126`). Don't confuse with **Service**, which is one of the two types rather than a synonym for the pair.
-- **Service** — A workspace script of type `service`: long-running, may bind a port, and carries `health` of `healthy | unhealthy | null` once the daemon has observed it. The only type a sidebar workspace row reports, because a running plain script says nothing about whether the workspace is up; the row names the service and turns danger when its health fails, and where several run the failing one takes the row's single slot. UI: "Services" in the sidebar's display preferences (**Show → Services**). Code: `selectWorkspaceServiceSummary` (`packages/app/src/components/sidebar/workspace-meta-row/service-summary.ts`), `WorkspaceScriptHealthSchema` (`packages/protocol/src/messages.ts:3124`). Forbidden: "Service" as a label for the Scripts panel, which lists both types.
-- **Schedule** — Cron-style trigger that creates new agents. UI: CLI/MCP (`paseo schedule`, `create_schedule`). Don't confuse with: Heartbeat (cron prompt back into the same agent).
-- **Heartbeat** — Ephemeral cron prompt sent back into the same agent/conversation. Agent surfaces expose create, update cron, and delete only. Use for reminders and babysitting where status should return inline.
-- **Mode** — Provider-specific operational mode (plan, default, full-access, …). UI: icon-only. Code: `modeId` in `AgentSessionConfig` (`packages/protocol/src/messages.ts:257`).
-- **Attachment** — External or local context bound to an agent prompt: forge issue/change request, review context, uploaded file, text, or image. UI: "Attach issue or PR/MR". Code: `AgentAttachment` (`packages/protocol/src/messages.ts:782`).
-- **Composer** — The whole prompt surface for sending work to an agent. Code: `Composer` (`packages/app/src/composer/index.tsx`). Don't call this "message input" except for the text-entry subcomponent.
-- **Composer input** — The text-entry surface inside the composer. Code: `MessageInput` (`packages/app/src/composer/input/input.tsx`).
-- **Composer toolbar** — The bottom control row inside the composer input. Contains agent controls, attachment button, voice controls, and stop/send controls. Code: `leftContent`, `beforeVoiceContent`, and `rightContent` slots in `MessageInput` (`packages/app/src/composer/input/input.tsx`). Forbidden: "Status bar".
-- **Agent controls** — Provider, model, mode, thinking, and provider-feature controls for an agent or draft agent. Code: `AgentControls` / `DraftAgentControls` (`packages/app/src/composer/agent-controls/index.tsx`). Forbidden: "Agent status bar".
-- **Composer footer** — Optional area rendered below the composer input but still inside the keyboard-shifted composer layout. Code: `Composer.footer` (`packages/app/src/composer/index.tsx`).
-- **Composer track** — A contextual lane at the foot of a pane, by the composer input. Specific tracks use the `<thing> track` form: **Queue track**, **Subagents track**, **Tasks track**. The subagents and tasks tracks are pills floating over the transcript, each opening a panel with its rows; the queue track is a lane inside the composer itself. Code: queue track inside `Composer` (`packages/app/src/composer/index.tsx`), pill and panel frame in `packages/app/src/composer/tracks.tsx`, `SubagentsTrack` (`packages/app/src/subagents/track.tsx`), `AgentTaskList` (`packages/app/src/composer/task-list/index.tsx`).
-- **Steer** — A follow-up admitted into an agent's already-running turn instead of interrupting it. Interrupting the turn discards steers the provider has not read yet; there is no take-back short of that, and no provider offers one. The stop button and Escape both interrupt. A steer the provider never read keeps its transcript row, matching Codex. Sending while the agent waits on a permission denies that request first, so the message reaches the same turn instead of stalling behind it. UI: "Send and steer". Code: `steerActiveTurn` (`packages/server/src/server/agent/agent-sdk-types.ts`). Don't confuse with **Queue track**, which holds messages client-side until the turn ends and never enters the running turn. Forbidden: "Delivery", "Queued prompt".
-- **Subagent** — User-facing term for an agent session related to a parent agent session. Use **subagents** in UI copy and docs. Internal daemon/provider plumbing may say "child agent" or `child_session`, especially for provider-managed imports; do not surface "child agent" as a product term.
-- **Attachment tray** — The selected-attachments row inside the composer input, above the text input. Code: `renderAttachmentTray` (`packages/app/src/composer/index.tsx`). Forbidden: "Attachment bar".
-- **Fork** — Starting a NEW agent session seeded with a copy of another session's curated chat history. The history rides along as a `chat_history` composer attachment on a draft; the fork does **not** resume or branch the provider-side session, and the source session keeps running untouched. Two targets, one surface, one RPC (`agent.fork_context`, gated on the `agentForkContext` host feature). UI: the fork menu lives in the assistant turn footer and offers "Fork in a new tab" / "Fork in a new workspace". On a **completed** turn it sits beside the copy button and pins a boundary to that turn, so the fork stops where the turn ended. On the **in-flight** turn it sits beside the progress loader and elapsed timer, and omits the boundary entirely — `selectForkContextRows` projects the whole timeline when no boundary is given, so the fork captures everything **up to now**, including the response still streaming. That omission is what makes mid-run forking work; pinning a boundary there would silently drop the live response. Forbidden on provider-subagent (read-only) panes. Code: `useForkAgent` (`packages/app/src/hooks/use-fork-agent.ts`), `selectForkContextRows` (`packages/server/src/server/agent/activity-curator.ts`). Don't confuse with: git fork (unrelated; Paseo has no such concept), **Worktree** (filesystem isolation, not history copying).
-- **Conflict** — Two distinct senses; do NOT use the bare word in UI copy without qualifying which: (a) **stale-write conflict** on `paseo.json` ("Config changed on disk", code `stale_project_config`, `packages/app/src/screens/project-settings-screen.tsx:593`); (b) **git merge conflict** (no current UI string).
-- **Product discussion** — Where non-bug product talk goes: [GitHub Discussions](https://github.com/getpaseo/paseo/discussions) and `#product` in Discord. Covers workflows, features, and product direction. The container term; the ask inside it is always a **workflow** — what you're doing, how you do it today, where Paseo gets in the way. Issues are bugs only. Forbidden: "Feature request" as a Paseo surface, label, or invitation; the phrase is only used when answering someone who arrived with it. Don't invent "feature discussion", "idea", or "workflow thread" as synonyms. See [CONTRIBUTING.md](../CONTRIBUTING.md).
-
-## Inconsistencies (documented, not papered over)
-
-- CLI `--host <host>` description `"Daemon host target"` (`packages/cli/src/utils/command-options.ts:5`) blurs daemon/host; the app keeps them distinct.
-- `WorkspaceDescriptorPayloadSchema.workspaceKind` accepts legacy `"checkout"` on the wire (`packages/protocol/src/messages.ts:2187`) while `PersistedWorkspaceKind` does not (`packages/server/src/server/workspace-registry-model.ts:8`).

docs/hover.md

@@ -1,154 +0,0 @@
-# Hover
-
-Read this before writing any hover code. Every hover regression we ship is one of the three failure modes below, and every one of them is solved by the same canonical pattern. The pattern is hardwon — it survived every other shape we tried — so copy it, don't reinvent it.
-
-## The pattern
-
-The canonical implementation lives in `packages/app/src/components/sidebar-workspace-list.tsx`, in the workspace row (around line 1369). When in doubt, open that file and copy the shape.
-
-```tsx
-//
-//   ┌─ Plain View. Tracks hover via pointerenter/pointerleave.
-//   │
-<View
-  style={styles.workspaceRowContainer}
-  onPointerEnter={handlePointerEnter}
-  onPointerLeave={handlePointerLeave}
->
-  <Pressable                          // ┐ Separate inner Pressable.
-    onPress={handlePress}             // │ Handles press only.
-    onPressIn={...}                   // │ Never has onHoverIn/onHoverOut.
-    onPressOut={...}                  // ┘
-    style={workspaceRowStyle}
-  >
-    <View style={styles.workspaceRowMain}>
-      <View style={styles.workspaceRowLeft}>…</View>
-      <WorkspaceRowRightGroup isHovered={isHovered} />
-      {/*                    └─ Reveals content based on hover state. */}
-    </View>
-  </Pressable>
-</View>
-```
-
-Five things make this work. Every one of them matters.
-
-1. **Hover lives on a plain `View`, not a `Pressable`.** `Pressable` carries its own internal hover state machine. Nested `Pressable`s fight over it. A plain `View` just dispatches DOM events — no state machine, no fighting.
-2. **Press lives on a _separate_ inner `Pressable`.** Hover and press never share an element. The two state machines never see each other.
-3. **`onPointerEnter` / `onPointerLeave` are non-bubbling**, mouseenter-style by W3C spec. They fire only when crossing the outer `View`'s bounding box. Crossing into descendants — including descendant `Pressable`s (the kebab menu's buttons, a copy button, a tooltip target) — does **not** fire `pointerleave`. This is why nesting `Pressable`s inside is safe.
-4. **The row has a fixed `minHeight`.** When content swaps in on hover (kebab replacing a diff stat), both occupy the same fixed slot. Zero layout shift, zero geometry flicker.
-5. **The outer `View` has nothing but `position: relative`.** It exists only to be the hover target. All real layout lives on the inner `Pressable`. The hover-tracker is a sealed envelope around the row; layout changes inside it never leak out and re-enter through the side.
-
-That's the whole pattern. Internalize it.
-
-## When you skip the pattern, here is what breaks
-
-### Failure mode 1 — Nested Pressables fight over hover state
-
-If you put `onHoverIn` / `onHoverOut` on a `Pressable` that has another `Pressable` anywhere inside it (a copy button, an icon button, a nested action), the moment the cursor moves onto the inner `Pressable`, the inner one's hover state machine claims hover and the outer one's `onHoverOut` fires. Your reveal state flips off. The reveal hides. The cursor is no longer over the hidden reveal, so it ends up back over the trigger area. The outer's `onHoverIn` fires. Loop.
-
-This is the most common hover bug shipped in this codebase, by a wide margin. It is what the workspace row is structured to avoid. The fix is not "be clever about handlers" — it's "don't put hover on a Pressable that contains other Pressables."
-
-> **Rule:** the hover-tracking element is a plain `View` with `onPointerEnter` / `onPointerLeave`. Any `Pressable`s — including ones you forgot are Pressables, like `TurnCopyButton`, icon buttons, anything that handles a tap — live inside it.
-
-### Failure mode 2 — The hovered state changes the trigger's geometry
-
-Symptom: you hover a button, it changes appearance, then flickers between hovered and not-hovered without the cursor moving.
-
-Cause: the hover state changed the size or position of the trigger. The cursor was on the original element; the new layout shifts or shrinks it out from under the cursor; `onHoverOut` fires; state reverts; original layout returns; cursor is back over the trigger; `onHoverIn` fires; loop.
-
-Common variants:
-
-- Hover state changes the trigger's `width`, `height`, `padding`, or `borderWidth`.
-- Hover state mounts/unmounts a child that pushes the trigger to a new position.
-- Hover state swaps the trigger for a different element type, remounting it.
-
-Fixes, in preferred order:
-
-1. **Don't change the trigger's outer geometry on hover.** Change colors, opacity, borders that don't take layout space (`outlineWidth` on web, absolutely positioned overlays), or child content that fits inside the same fixed box. Never change `width`, `height`, `padding`, or `borderWidth` of the hover target itself.
-2. **Hide with `opacity` + `pointerEvents`, not conditional rendering**, when the hidden element lives inside the trigger. Mounting/unmounting on hover reflows the layout under the cursor.
-3. **Pin the hit area.** Set a fixed `minHeight` / `minWidth` on the trigger so internal swaps (icon-A becomes icon-B on hover) leave the bounding box unchanged. The workspace row's `minHeight: 36` is what makes the kebab/diff-stat swap stable.
-
-### Failure mode 3 — Revealed content lives outside the hover trigger
-
-If hovering element A reveals element B, B must be **inside** A's hover trigger. If B is a sibling, the moment the cursor moves from A toward B it crosses out of A's bounding box, `pointerleave` fires, B disappears.
-
-Wrong:
-
-```tsx
-<View>
-  <View onPointerEnter={...} onPointerLeave={...}>     {/* hover trigger */}
-    <Bubble />
-  </View>
-  <TrailingRow />                                       {/* OUTSIDE — sibling, not child */}
-</View>
-```
-
-Right:
-
-```tsx
-<View onPointerEnter={...} onPointerLeave={...}>      {/* hover trigger */}
-  <Bubble />
-  <TrailingRow />                                      {/* INSIDE — child */}
-</View>
-```
-
-Any gap between A and B (margins between siblings inside the same parent) is part of the parent's bounding box, so the cursor stays inside the hover region while crossing it. No bridge needed.
-
-If A and B genuinely can't share a parent — B portals into a different layer, floats above other content — see [Section: real gaps](#real-gaps-with-floating-panels) below.
-
-### Failure mode 4 — A hover-revealed trigger unmounts its own open menu
-
-A kebab that only exists while its row is hovered opens a menu, and that menu takes the pointer
-off the row: a sheet slides up over it, a popover covers it. The row un-hovers, the trailing
-overlay unmounts, and the trigger goes with it — taking the menu's open state, which lived
-inside the trigger's subtree. The surface itself is already presented in a portal, so nothing
-unmounts it and nothing is left that can close it. On a bottom sheet that means a full-screen
-backdrop swallowing every click until reload.
-
-Lift the menu's open state to whatever decides to render the trigger, and keep the trigger
-rendered while the menu is up. `useOpenKebabMenuVisibility`
-(`packages/app/src/components/sidebar/use-open-kebab-menu-visibility.ts`) is that shape for the
-sidebar rows: it owns `open`, hands the menu its controlled props, and ORs `open` into the
-row's own `showKebab`.
-
-## Native fallback
-
-Hover doesn't exist on touch devices. Anything you hide behind hover must have a non-hover path on native and compact layouts:
-
-```tsx
-const showControls = isHovered || isNative || isCompact;
-```
-
-`isNative` and `isCompact` come from `@/constants/platform` and `@/constants/layout`. Don't use `Platform.OS === "ios"` as a proxy.
-
-`onPointerEnter` / `onPointerLeave` are DOM events. They do not fire on native. You do not need to gate them — on native, hover is unreachable anyway and visibility is driven by `isNative` / `isCompact` in your show-the-controls expression above. This is why the workspace row's pointer events are not wrapped in `if (isWeb)`.
-
-## What about `Pressable.onHoverIn` / `onHoverOut`?
-
-It's fine when a `Pressable` styles **itself** based on its own hover — for example, an icon button that changes color on hover. That's self-contained. The render-prop `<Pressable style={({ hovered }) => ...}>` does the same thing more cleanly and is the preferred form.
-
-It is **not** fine for tracking hover to drive state **outside** that `Pressable` (revealing a sibling, opening a tooltip, showing a kebab) when there is any other `Pressable` inside — because that's Failure Mode 1.
-
-Heuristic: if your hover state is going to be `useState`'d and read by anything other than the same `Pressable`'s own style, do not use `onHoverIn` / `onHoverOut`. Use the canonical pattern.
-
-## Real gaps with floating panels
-
-Sometimes the revealed content can't live inside the trigger — a hover card portals into a different layer, a tooltip floats above other content, a popover renders into a `Portal`. There's a real visual gap the user has to cross with the cursor.
-
-For a card whose content the user can point at or press, use `HoverCard` (`packages/app/src/components/ui/hover-card.tsx`). It is built on `useHoverSafeZone` (`packages/app/src/hooks/use-hover-safe-zone.ts`), which computes a rectangular "bridge" across the gap between the trigger and the content, whether the card sits beside, above, or below the trigger. While the pointer is inside trigger, content, or the bridge, the card stays open. A short grace timer absorbs jitter at the edges. `Tooltip` takes no pointer events and closes as soon as the pointer leaves the trigger. If the trigger has no focusable child, give `HoverCardTrigger` `focusable` and an accessible label so keyboard users can open the same content.
-
-Don't roll your own. The math is annoying, the edge cases (pointer leaves window, drag in progress, content unmounts) are subtle, and we already paid for the hook.
-
-## Pre-PR checklist
-
-Before opening a PR that touches hover:
-
-- [ ] Hover-tracking is on a plain `View` with `onPointerEnter` / `onPointerLeave`, **not** on a `Pressable` that wraps anything pressable.
-- [ ] Any press behavior lives on a separate inner `Pressable` that does not have `onHoverIn` / `onHoverOut`.
-- [ ] The hover trigger's bounding box contains every element the user might mouse into while interacting with the feature.
-- [ ] Hovered state does **not** change the trigger's outer geometry (`width`, `height`, `padding`, `borderWidth`, mount/unmount of siblings that shift it). Internal swaps fit inside a fixed `minHeight` / `minWidth`.
-- [ ] Revealed content inside the trigger uses `opacity` + `pointerEvents`, not conditional rendering, if mounting it would reflow the trigger.
-- [ ] Visibility on native and compact layouts works without hover (`isHovered || isNative || isCompact`).
-- [ ] A menu opened from the revealed trigger keeps the trigger rendered while it is open, so losing hover can't strand it.
-- [ ] If the revealed content sits in a separate layer (portal, floating panel) and the user can point at it, it is a `HoverCard`.
-- [ ] You opened the dev server, hovered the trigger, and slowly moved the mouse along **every** revealed element — including any visible gaps — without losing hover state.

docs/hub.md

@@ -1,103 +0,0 @@
-# Paseo Hub relationship
-
-Paseo Hub is an explicit opt-in connection from one Paseo daemon to one Hub. Running a daemon does
-not register it with a Hub. The relationship begins only when a user runs
-`paseo hub connect [url]` from the daemon machine with an explicit API key or matching stored CLI login.
-
-The human CLI login and daemon relationship are separate identities. `paseo hub login [url]` stores a durable organization-scoped CLI credential keyed by normalized Hub origin under `PASEO_HOME`. Interactive login optionally connects the local daemon, then points to the Hub UI for trigger configuration; it does not scaffold or deploy configuration. `paseo hub init` remains the explicit triggers-as-code scaffold: it writes one self-contained organization trigger under `.paseo/triggers/`, validates it through the trigger API, and optionally installs it. `paseo hub deploy` validates and installs every trigger in that directory; passing `--project` keeps deploying the legacy project bundle instead. `paseo hub export [directory]` writes the active organization's current triggers in the same layout, using the active login unless another Hub or API key is selected. Origin resolution uses explicit command input, `PASEO_HUB_URL`, active login, then `https://hub.paseo.sh`. Connect uses exact-origin authority to request a one-time enrollment token, then passes only that token to the daemon. The daemon generates and persists its own relationship credential.
-
-## Connection and authority
-
-The daemon enrolls over HTTP(S), then opens and maintains a direct outbound WebSocket to the Hub.
-The Hub never discovers or acquires the daemon through Paseo's relay. The relay remains an optional
-encrypted path for normal Paseo clients and has no role in Hub enrollment, authentication, dispatch,
-or reconnects.
-
-The daemon persists a relationship ID and private connection credential before enrollment. The
-relationship is independent of its current transport, so a future transport can replace the direct
-WebSocket without pairing again. The current foundation supports one Hub relationship per daemon.
-
-Normal authenticated daemon sessions may manage the daemon's Hub relationship and permissions.
-Hub connections have no daemon permissions by default. Connecting gives Hub machine identity and
-presence but no execution authority. The `hub.execute` permission lets workflows triggered from
-GitHub, Slack, Discord, Linear, and other integrations create workspaces and run agents. Grant it
-during interactive login or later with `paseo hub permissions grant hub.execute`. Relationships
-created before this split migrate their legacy execution scope to `hub.execute`. Hub sessions cannot
-manage their own relationship or permissions.
-
-## Session grants and agent operations
-
-Hub uses the same authenticated, resumable Session protocol as other clients. Its persisted
-`hub.execute` permission authorizes ordinary agent creation, workspace titling, messaging,
-cancellation, archival, agent/workspace observation, timeline subscriptions, and workspace recovery. This authority is
-daemon-wide; it is not limited to agents created by that Hub. Daemon configuration, terminals,
-browser control, and permission management still require their own permissions. See
-[permissions.md](permissions.md).
-
-Creating an agent may create a directory workspace. The same `hub.execute` session can title that
-workspace through `workspace.title.set.request` without `workspace.manage`.
-
-Clients using this contract check `server_info.features.hubAgentRpc` and
-`server_info.features.agentRequestReceipts` once. An older host must be upgraded; do not silently
-fall back to creating a fresh agent when continuation was requested.
-
-Hub owns conversation keys, trigger policy, execution records, and the mapping to workspace/agent
-IDs. None of these routing concepts are part of the generic daemon RPCs. Creation accepts ordinary
-provider configuration, exact MCP tool policy, environment, and workspace/worktree selection.
-Private session configuration is persisted for recovery and is not exposed in agent snapshots.
-Provider controls remain provider-native; see [providers.md](providers.md).
-
-`create_agent_request.idempotencyKey` identifies one creation operation. With a key, omit
-`initialPrompt`, persist the returned agent/workspace identity, then deliver the prompt using
-`send_agent_message_request` with a stable `messageId`. Request IDs correlate individual attempts;
-creation keys and message IDs identify the operation across attempts. A creation key is daemon-wide;
-a message ID is scoped to its agent. Reusing either with different arguments is a conflict.
-`workspace.create.request.idempotencyKey` provides the same creation guarantee for directory and
-worktree workspaces; check `server_info.features.workspaceRequestReceipts` before using it.
-Workspace creation keys and agent creation keys have separate namespaces. The app keeps these keys
-for the lifetime of a draft and reuses the first message ID after failures.
-
-The daemon journals the assigned agent ID before creation. Concurrent retries share one operation,
-and a retry after a lost acknowledgement or restart returns the durable agent without creating a
-workspace or starting a turn. Deleting that agent does not make its old creation key reusable.
-Confirmed message delivery is also journaled, so retrying its message ID does not submit it again.
-An unfinished delivery after restart reports `agent_request_outcome_unknown`: a provider can have
-accepted a prompt before the daemon recorded success, so automatic resubmission could duplicate
-work. Inspect the agent before choosing a new message ID. Receipts contain identity and request
-hashes, never prompts, environment values, or credentials.
-
-Before messaging an archived workspace, call `workspace.recovery.inspect.request`, then
-`workspace.recovery.restore.request` and await success. The native message handler unarchives the
-agent and loads its persisted provider session. `activeTurnBehavior: "steer"` uses the provider's
-native steering behavior, including Paseo's existing behavior when that provider cannot steer.
-Execution completion and arrival-specific output authority remain Hub responsibilities.
-
-The older `hub.execution.*` RPCs remain accepted for existing clients. Their execution ownership
-and create deduplication behavior are unchanged; new continuation work uses the ordinary RPCs.
-
-## Disconnect and revocation
-
-Normal socket loss reconnects the active relationship with bounded exponential backoff and jitter.
-Daemon restart loads the same relationship and credential and reconnects without another enrollment
-ceremony.
-
-Hub authentication rejection or close code `4403` permanently revokes the local relationship. The
-daemon deletes its credential, stops reconnecting, and retains only the relationship ID, Hub origin,
-scopes, and a sanitized reason for status reporting.
-
-`paseo hub disconnect` disables socket reconnect and execution authority before making one bounded
-remote revocation request. The daemon then removes the local relationship whether the request
-succeeds or fails. A failed request returns a warning that server-side revocation may remain pending.
-`--force` skips the remote request. Legacy persisted `disconnecting` records are removed on startup;
-the daemon does not retry revocation in the background.
-
-`paseo hub logout` removes only the active human CLI credential and preserves credentials for other origins. Interactive logout inspects and optionally disconnects a same-origin daemon before deleting the login; a failed requested disconnect preserves the login. JSON and noninteractive logout never prompt or disconnect implicitly.
-
-## Cross-repository compatibility
-
-The consumer implementation lives in Paseo Cloud. Cloud owns its copy of the Hub wire schemas and
-has no Paseo runtime or build dependency. Cross-repository end-to-end verification separately builds
-a Paseo source checkout and exercises the real daemon, CLI, direct WebSocket, Cloud service, and
-Postgres. That compatibility fixture is not a package dependency or fallback implementation.
-Its `hub-e2e` ACP provider accepts only exact tool names on the injected `hub` MCP server. Other
-custom ACP providers remain unsupported for unattended preapproval.

docs/i18n.md

@@ -1,93 +0,0 @@
-# I18n
-
-Paseo client UI translations live in `packages/app/src/i18n`.
-
-## Supported Locales
-
-- `en`
-- `ar`
-- `es`
-- `fr`
-- `ja`
-- `ko`
-- `pt-BR`
-- `ru`
-- `zh-CN`
-
-The persisted app language setting is `"system" | "ar" | "en" | "es" | "fr" | "ja" | "ko" | "pt-BR" | "ru" | "zh-CN"`. `"system"` follows the device or browser locale when it maps to a supported locale; unsupported system locales fall back to English. Japanese maps from system locales `ja` and Japanese regional locales. Korean maps from system locales `ko` and Korean regional locales. Brazilian Portuguese maps from system locales `pt-BR` and bare `pt`; other Portuguese regional locales remain unsupported until explicitly added.
-
-## Translation Scope
-
-Translate client-owned UI copy: labels, buttons, empty states, confirmation text, and local status/error wrappers.
-
-Do not translate agent output, daemon output, terminal contents, file paths, provider names, model names, command names, user-authored text, code blocks, logs, or raw protocol/server error text.
-
-## Adding Copy
-
-English source strings live in `packages/app/src/i18n/resources/en.ts`. Each supported locale has a matching resource in `packages/app/src/i18n/resources`.
-
-For migrated screens and components, use `useTranslation()` and pass translated text into UI primitives. Low-level primitives such as `<Button>` do not import translation state unless they own the text they render.
-
-Keep resource keys grouped by product surface, not component mechanics.
-
-Run:
-
-```bash
-npx vitest run packages/app/src/i18n/resources.test.ts --bail=1
-```
-
-The parity test catches missing keys across English and every supported locale resource.
-
-## Forge-Variant Copy
-
-Strings that vary by git forge follow a two-tier rule:
-
-- **Indeclinable tokens** — brand names ("GitHub", "GitLab"), the PR/MR initialism, number prefixes (`#`/`!`) — are interpolated into a single key (`"Refresh git and {{brand}} state"`). These tokens stay latin and uninflected in every supported locale, so one string per locale suffices. The value comes from the forge manifest via `getForgePresentation`.
-- **Sentences containing the full change-request noun** ("pull request" / "merge request" inflects and takes gender/case in translation) use the i18next `context` mechanism: the base key carries the pull-request wording and an `_mr` sibling carries the merge-request wording (`pullRequest` / `pullRequest_mr`). Call sites pass `t(key, { context: getForgePresentation(forge).changeRequestContext })`; an undefined or unknown context falls back to the base key.
-
-Keys scale per vocabulary family (PR vs MR), not per forge: a new forge picks an existing family in its manifest entry and needs zero locale edits.
-
-## Migration Order
-
-Client UI translation is staged so each pass can migrate complete local copy clusters and keep reviews focused.
-
-1. App shell and shared UI chrome: common actions, headers, sheets, command center, and client-owned toast status.
-2. Composer and agent workflow: composer input, agent controls, permission prompts, plan approval, and agent panel wrapper states.
-3. Settings expansion: Appearance, Shortcuts, Integrations, Permissions, Diagnostics, About, Project settings, Host settings, and provider diagnostics.
-4. Workspace and panels: setup/file/browser/terminal wrapper copy, file explorer local states, import-session flows, and remaining local toast/error wrapper text.
-
-Within a migrated surface, do not leave mixed-language neighboring labels when those labels are owned by the client. Move the whole local copy cluster together.
-
-### Progress
-
-- Batch 2 migrated Composer and agent workflow chrome: Composer input and attachments, agent controls, stream permission prompts, agent panel wrapper states, and draft panel descriptors. Provider/model names, provider-defined option labels, agent output, and protocol/server diagnostics remain untranslated.
-- Batch 3A migrated Settings Diagnostics/About, Appearance, Shortcuts, Integrations, and Desktop Permissions chrome. Host settings and Project settings remain for Batch 3B; raw runtime status/error details remain untranslated.
-- Batch 3B migrated Host settings, Provider diagnostics, and Project settings chrome. Provider/model names, project/host labels, script commands, diagnostic output, file paths, and raw runtime/server error details remain untranslated.
-- Batch 4A migrated workspace wrapper chrome for import sessions, file explorer, setup, browser, terminal, and file panels. File paths, URLs, commands, logs, terminal output, provider labels, and raw runtime/server errors remain untranslated.
-- Batch 4B migrated workspace tab shell, workspace scripts, Git actions/diff/PR chrome, worktree archive warnings, Open-in-editor controls, and inline review controls. Branch names, PR titles/bodies, check names, workflow names, file paths, diff contents, commands, terminal output, provider labels, and raw runtime/server errors remain untranslated.
-- Batch 4C migrated Sidebar project/workspace menus, hide/remove/archive confirmations, workspace rename chrome, New workspace ref picker/create flow, and Open project home tiles. Workspace/project names, branch names, PR titles, paths, provider labels, daemon output, and raw runtime/server errors remain untranslated.
-- Batch 4D migrated provider/model selector chrome, provider catalog install modal, add-connection method modal, and paste-pairing-link modal. Provider/model/catalog names, provider descriptions, pairing URLs, protocol parser errors, daemon connection details, and raw runtime/server errors remain untranslated.
-- Batch 4E migrated onboarding welcome chrome, direct-connection modal fields/actions/local failure guidance, QR scan permission/unavailable states, and desktop pair-device card. Pairing URLs, host/port placeholders, endpoint values, transport details, protocol parser errors, and raw runtime/server errors remain untranslated.
-- Batch 4F migrated realtime voice overlay accessibility labels, rewind menu chrome and fallback toast, DiffViewer default empty state, and service URL chooser copy. Shortcut key names, raw daemon errors, diff contents, URLs, and caller-provided override labels remain untranslated.
-- Batch 4G migrated the keyboard shortcuts help dialog to render section titles, row labels, and row notes through translation keys. Shortcut key names, shortcut combos, binding IDs, action IDs, and fallback registry labels remain untranslated.
-- Batch 4H migrated Sessions screen chrome and AgentList local UI copy: date section headers, local status labels, fallback session titles, badges, load-more/empty states, and the archive action sheet. Agent titles, project paths, provider icons/labels, host labels, relative timestamps, and raw runtime data remain untranslated.
-- Batch 4I migrated message utility chrome: image lightbox labels/errors, code and turn copy accessibility labels, dictation controls, question form fallback placeholders/actions, PlanCard fallback title, assistant image fallback errors, and todo list labels. Message bodies, plan text, todo item text, attachment labels, runtime dictation errors, and agent/tool output remain untranslated.
-- Batch 4J migrated workspace tab toast/empty chrome: copy failure messages, copied labels, resume-command availability errors, reload-agent local status, host-disconnected wrapper reuse, and split-pane empty state. Agent IDs, generated resume commands, workspace paths, branch names, and raw reload errors remain untranslated.
-- Batch 4K migrated sidebar/project list chrome: host picker fallback/search/title, footer actions and tooltips, Sessions row labels, mobile close label, New workspace tooltip/accessibility label, project-list empty states, and project settings host-load wrapper text. Host names, project names, workspace names, paths, branch names, and raw host errors remain untranslated.
-- Batch 4L migrated picker/file/detail utility chrome: project picker states, branch switcher labels/placeholders, file pane loading/empty/fallback errors, tool-call details section/empty labels, and open-file accessibility. Directory paths, branch names, file contents, file sizes, tool details, and raw file-load errors remain untranslated.
-- Batch 4M migrated hook/modal utility chrome: image attachment permissions/dialog/errors, copied toast wrappers, rename modal local validation/fallback errors, branch switcher stash/switch prompts and fallback toasts, and workspace setup local fallback errors. Copied labels supplied by callers, branch names, selected paths, raw dialog/API errors, and raw server errors remain untranslated.
-- Batch 4N migrated pure view-model/policy utility chrome: import-session fallback titles/previews/empty states and the worktree setup callout. Provider labels and IDs remain runtime values interpolated into translated wrappers.
-- Batch 4O migrated remaining small utility chrome: workspace route gate states/actions, compaction markers, archived-agent callout, web browser fallback, desktop quitting overlay, and image drop overlay. Host names, host status values, browser IDs, token counts, and raw route errors remain runtime values.
-- Batch 4P migrated provider-selection pure view-model utility copy to direct `i18n.t(...)` calls and removed the local labels parameter path. Provider/model labels, provider IDs, and provider snapshot error messages remain runtime values.
-- Batch 4Q migrated desktop update utility chrome: app update status text, update callout titles/actions, generic update errors, and install-error wrappers. Version labels, installer messages, raw update errors, release-channel data, and logs remain runtime values.
-- Batch 4R migrated desktop permission utility chrome: permission status details, permission request fallback errors, empty permission statuses, and desktop notification test wrappers. Browser permission states, exception names, and raw browser API error messages remain runtime values.
-- Batch 4S migrated desktop daemon settings chrome: built-in daemon status rows, daemon lifecycle toggles, logs/status modals, clipboard alerts, daemon management confirmations/errors, daemon status load errors, and desktop CLI/skills install wrapper errors. PIDs, log paths, log contents, CLI status output, version values, and raw IPC errors remain runtime values.
-- Batch 4T migrated remaining attachment/autocomplete utility chrome: user and composer review attachment labels, workspace hover-card accessibility, branch stash restore prompts/toasts, agent autocomplete loading/empty/fallback error text, older-history fallback toast, draft panel labels, and agent-control fallback labels. PR/issue numbers, browser element tags, branch names, provider labels, model labels, agent prompts, command/file names, and raw server errors remain runtime values.
-- Batch 4U migrated shared default utility chrome: Combobox and Autocomplete default placeholders/empty/loading labels, drag-overlay and subagent-track loading labels, sub-agent activity fallback headers, and file-preview fallback errors. Caller-provided labels, tab titles, subagent descriptions, file paths, and raw file-load errors remain runtime values.
-- Batch 4V migrated Git policy action chrome to direct `i18n.t(...)` calls: commit/pull/push/sync/PR/merge/auto-merge/archive action labels, pending/success labels, and unavailable reasons. Branch/base refs, PR URLs, GitHub merge-state enum values, runtime statuses, and raw Git/GitHub errors remain runtime values.
-- Batch 4W migrated remaining local wrapper states: workspace copy unavailable toasts, startup daemon-log loading/empty/load-failed text, and file-explorer workspace/host unavailable fallbacks. Workspace paths, branch names, daemon log contents/paths, checkout query details, and raw file/daemon errors remain runtime values.
-- Batch 4X migrated descriptor and command chrome: Pair-device modal header, workspace setup sheet title, terminal panel fallback labels, command-center action titles, and file-pane host-disconnected fallback. Provider/catalog names, command-center search keywords, terminal runtime titles, file paths, and raw read errors remain runtime values.
-- Batch 4Y tightened the translation boundary so React components and custom hooks use `useTranslation()` while pure helpers keep direct `i18n.t(...)` fallbacks, and migrated remaining small UI/accessibility fallbacks across message details, menu backdrops, startup errors, sidebar PR badges, settings/project accessibility labels, composer send/create/download fallbacks, client slash-command descriptions, terminal subscribe errors, and desktop update completion text. Provider catalog metadata, shortcut registry fallbacks, agent/daemon/protocol reasons, terminal contents, raw runtime errors, and user/project/workspace names remain untranslated.
-- Batch 4Z expanded the supported locale set to the six UN official languages: Arabic, Chinese, English, French, Russian, and Spanish. Arabic, French, Russian, and Spanish now have full client-owned UI resource coverage, with key parity, fallback-ratio, and interpolation-placeholder tests guarding the generated translations. Arabic does not enable RTL layout direction in this batch.
-- Batch 5A added Brazilian Portuguese (`pt-BR`) resource coverage, language selector labels, i18next registration, and system-locale mapping for `pt-BR` and bare `pt`. Non-Brazilian Portuguese regional locales remain unsupported until a matching resource is added.
-- Batch 5B added Korean (`ko`) resource coverage, language selector labels, i18next registration, and system-locale mapping for `ko` and Korean regional locales.

docs/menus.md

@@ -1,203 +0,0 @@
-# Menus
-
-One engine, in `packages/app/src/components/ui/menu/`. `dropdown-menu.tsx` and `context-menu.tsx`
-are wrappers over it and differ only in what opens them — a press, or a long press / right click.
-Import the `DropdownMenu*` or `ContextMenu*` names as before; reach for `@/components/ui/menu`
-directly only when you are building a third trigger shape.
-
-Do not add a third menu implementation. The two that existed were byte-identical from
-`computePosition` down, and the copies drifted: only one of them ever grew a sheet.
-
-## Two presentations
-
-`MenuRoot` picks one from form factor, never from platform — a tablet in a narrow split view
-sheets the same way a phone does.
-
-| Screen                         | Surface                         | Submenus                                           |
-| ------------------------------ | ------------------------------- | -------------------------------------------------- |
-| Wide                           | Popover anchored to the trigger | Flyout overlapping the row, opened by hover intent |
-| Compact, `compactMode="sheet"` | Bottom sheet                    | The page is replaced in place, with a back header  |
-| Compact, default               | Popover                         | Same as wide                                       |
-
-`compactMode` defaults to `"popover"`, so adopting the sheet is per-menu. That is deliberate:
-flipping every menu in the app to sheets at once is not a change anyone can review. Opt a menu in
-when you have actually looked at it on a phone.
-
-`ContextMenu` is the exception: it defaults to `compactMode="sheet"` and enables native long press.
-Disable mobile triggering explicitly on draggable rows, where long press belongs to drag instead.
-
-## When the items differ per form factor
-
-A menu whose contents depend on what else is on screen gets one component per surface, not one
-component with `isMobile` branches inside it. The workspace header menu is the example
-(`packages/app/src/screens/workspace/workspace-header-menu.tsx`): compact has no tab strip, so it
-carries new-tab actions, while wide leaves those to the strip's `+` menu and lists workspace
-actions only. Items both surfaces share live in one component that each menu renders, from the same
-callbacks, so the two can't drift.
-
-## Selecting an item on iOS
-
-An item that closes the menu runs its action after a fixed grace period on iOS, not immediately:
-a native presenter launched while UIKit is still tearing down the surface can hang. Both surfaces
-unmount the moment the menu closes, so the wait is a timer rather than the surface's own dismissal
-callback — a callback fired from inside a subtree that is being removed is racing its own removal,
-and it loses. Selections used to be dropped entirely for exactly that reason.
-
-The consequence for callers: an `onSelect` on iOS runs a beat after the press. Don't add a second
-delay on top of it, and don't read state that the same press mutated.
-
-This is why a row inside a menu surface goes through `selectItem` rather than calling its handler
-from its own `Pressable`. `MenuItem` is not the only row shape on the engine — `ComposerTrackRow`
-is another, with its own icons and hover-revealed actions — but both hand the press to the engine
-and take `closeOnSelect` to say whether choosing them ends the surface. A row that owns its press
-outright leaves the surface open behind whatever it opened, and skips the iOS wait.
-
-## Pages
-
-A submenu is a page, declared as data on the surface and reached by a `MenuSubTrigger` whose `id`
-matches:
-
-```tsx
-<MenuSurface pages={pages} sheetTitle="Display">
-  <MenuSubTrigger id="grouping" value="Project">
-    Grouping
-  </MenuSubTrigger>
-</MenuSurface>
-```
-
-Pages are data rather than nested children because the popover renders them as _siblings_ of the
-root surface — a flyout nested inside the root's box would be clipped by its `overflow: hidden`.
-Declaring them separately is what lets one model drive both presentations.
-
-`menu-navigation.ts` holds that model, and it is pure: the open flyout chain and the mobile push
-stack are the same path, so the popover renders every entry in it and the sheet renders only the
-last. Nothing else differs between the two.
-
-Opening a submenu truncates the path to the depth of the trigger that opened it. Without that,
-sliding the pointer across a row of triggers would stack up every flyout it passed instead of
-swapping between them.
-
-## A page that takes input
-
-A menu page can hold a small form — `MenuTextField` is the field for it, drawn as a row's own
-fill so its text lands on the same rail as the labels above it. Two things have to be true for
-that page, and both are set on the page definition rather than discovered later:
-
-- **`hoverIntent: false`.** A branch you skim is opened and closed by the pointer; a form is not.
-  Without this the page opens on a pointer that was only passing through, and dismisses itself —
-  draft and all — the moment your hands move to the keyboard and the mouse drifts off the flyout.
-  While such a page is open, the whole surface stops closing on hover, because the parent flyout
-  leads back to the same dismissal.
-- **The compact presentation has to be a sheet.** `MenuTextField` resolves to
-  `BottomSheetTextInput` on compact native, which reads the sheet's context and has none in a
-  popover.
-
-The sheet keeps `keyboardBehavior="interactive"`. `extend` grows a sheet to its largest snap
-point, and with `enableDynamicSizing` that point is the content's own height — a short page does
-not grow, and the keyboard comes up over the field you are typing into.
-
-## Hover intent
-
-A flyout **overlaps its parent by 5pt** rather than sitting beside it. With a gap there is a strip
-of backdrop between the two that belongs to neither surface, and every pixel of it is a chance to
-dismiss the menu you are reaching for. Overlapping deletes the strip; don't reintroduce the gap
-and try to cover it with a longer timer.
-
-On top of that, a flyout opens after the pointer rests ~90ms, closes ~260ms after it leaves, and
-cancels its own pending close while the pointer is inside it. The grace still matters because the
-pointer crosses sibling rows on the way down into the flyout.
-
-Hover lives on a plain `View`, never on a `Pressable` — see [hover.md](hover.md), which owns that
-rule. Hover only fires on web, which is exactly where flyouts exist; everywhere else the page
-opens on press.
-
-## Item states
-
-`selected` and `active` are different questions and must not be merged.
-
-| Prop       | Means                      | Draws                     |
-| ---------- | -------------------------- | ------------------------- |
-| `selected` | This is the chosen value   | A check, and nothing else |
-| `active`   | This row's submenu is open | The fill, and no check    |
-
-`selected` also announces itself as `aria-checked`, so a multi-select page is audible as the list
-of on/off things it is.
-
-A selected row does **not** get a background. A check and a fill are two separate claims about the
-same state, and showing both makes a chosen row compete with the row the pointer is actually on.
-`showSelectedCheck` moves the check to a reserved leading column when a group needs to stay
-aligned whether ticked or not; otherwise it sits at the trailing edge and the leading slot is free
-for the option's icon.
-
-Give options icons; leave the root rows without them. The root is labels and their current values,
-and a column of icons there is decoration competing with the values you actually came to read.
-
-## Surface details
-
-- The hover fill is **inset from the surface's edges and rounded** — a chip inside the menu, not a
-  band across it. The inset is taken _out of_ the row, never added to it: padding gives up what
-  margin takes, so labels sit at the same 13pt they always did. Insetting by growing the row is how
-  the menu ends up taller than it started.
-- **A row is as tall as what is driving it** — 28pt for a pointer, 40pt below `md` for a thumb. The
-  split is on breakpoint, not on `presentation`: the compact popover that `compactMode` defaults to
-  is worked with a thumb just as a sheet is, and sizing off the sheet would leave it at the desktop
-  height. `md` is where `useIsCompactFormFactor` divides, so row height and the popover/sheet choice
-  turn over together.
-- The desktop height only holds because the label's `lineHeight` is pinned — 18 line + 8 padding +
-  2 border is exactly 28. Leave it to the platform and content outgrows `minHeight`, which then does
-  nothing. Compact is the other way round: `minHeight` leads and the label centres in it.
-- **A row owns its fill; `MenuPage` owns the spacing between rows.** The vertical inset above the
-  first row and below the last, and the gap between rows, are the page's — one knob each,
-  `MENU_ROW_GAP` being the one a redesign turns. A row that carried vertical margin would be
-  serving both at once, and since margins don't collapse it would land as one unit at the edges and
-  two between rows, so shrinking the gap would eat the inset with it. Horizontal inset does stay on
-  the row: there is one left edge and one right edge, so nothing is doubling up.
-- `MenuPage` is also what provides a page's depth, so the popover and the sheet cannot disagree
-  about what a page is. Every entry point goes through it — root, flyout, pushed sheet page.
-- The gap reaches a page's **direct children**. A group of rows wrapped in a `View` of its own drops
-  out of it; at the current gap of zero there is nothing to lose, but anything above zero wants that
-  wrapper to carry the page style too.
-- The separator is the one row-level thing that asks for vertical space of its own, and now that
-  rows carry none, that is still one number controlling one gap. It takes no horizontal margin and
-  the page has no horizontal padding, so the rule runs the full width of the surface.
-- Separators use `borderAccent`, the same colour the surface outlines itself with. `border` sits
-  between `surface1` and `surface2`, which put it within a hair of the hover fill and made
-  separators disappear against a hovered row.
-
-## When a decision earns a submenu
-
-Put a decision behind a submenu when its options are not the point — the current _value_ is. The
-root row then reads as the answer (`Grouping  Project ›`) and costs one line instead of one line
-per option. A menu whose every option is on screen at once does not survive its third decision.
-
-Independent toggles stay on their page as a checkmark list. A pick-one group can share that page
-below a `MenuSeparator`; make selecting the checked row clear it, so "none" doesn't need a row of
-its own.
-
-## Gotchas
-
-- **Released height.** Reanimated's web entering animation leaves an inline height snapshot on
-  the surface. `AnchoredSurface` clears it, and a `revision` prop re-clears it when content
-  identity changes — a pushed page taller than the one it replaced is clipped without that.
-- **Animate only once placed.** The same snapshot carries top/left, and Reanimated writes it back
-  750ms after mount. `AnchoredSurface` remounts the surface when its position resolves so the
-  entering animation never ends at the off-screen measuring position; on a slow machine that
-  write moved the open menu back off-screen.
-- **Sheets size to content.** `enableDynamicSizing`, not fixed snap points. A pushed page is
-  rarely the height of the page before it.
-- **The sheet's content is teleported out of the menu's subtree**, so `MenuSheetSurface` rebuilds
-  both menu contexts through the sheet's `contextBridge`. Providing them around the modal puts
-  them on the wrong side of the portal and every item inside throws. Gotcha 7 in
-  [floating-panels.md](floating-panels.md).
-- **One overlay per menu.** Submenus render inside their parent's layer and paint no second
-  backdrop, so there is exactly one `Modal` on native no matter how deep the menu goes.
-- **Sheet stacking and backdrop dismissal belong to `IsolatedBottomSheetModal`.** Menus only
-  request a backdrop opacity. See [floating-panels.md](floating-panels.md#gotcha-6--bottom-sheet-refs-are-not-lifecycle-truth).
-- **Retained panels own visibility.** The shared menu surface unmounts when its panel becomes
-  inactive. An async action can navigate before its menu closes; a hidden panel must not leave a
-  portal backdrop blocking the destination. On web the chat suspends one commit after it goes
-  inactive, and that inactive commit is where the surface unmounts.
-- Anchoring, flipping, and edge clamping live in `components/ui/anchor.ts`, shared with the hover
-  card, and are unit-tested. Fix positioning bugs there, not at a call site.
-- Everything else about floating surfaces on Android — Portal/Modal escape, lifecycle gates,
-  status-bar offset, the open flash — is in [floating-panels.md](floating-panels.md).

docs/mobile-panels.md

@@ -1,128 +0,0 @@
-# Mobile panels
-
-Compact layouts have three mutually exclusive destinations:
-
-- `agent-list` on the left
-- `agent` in the center
-- `file-explorer` on the right
-
-They are one interaction, not two independent drawers. The implementation lives in
-`packages/app/src/mobile-panels/`.
-
-## Ownership
-
-React/Zustand owns the durable intent:
-
-```ts
-interface MobilePanelSelection {
-  target: "agent-list" | "agent" | "file-explorer";
-  revision: number;
-}
-```
-
-Every semantic target change increments `revision`. Repeating the current target is idempotent.
-Compact panel selection is not persisted; a cold start begins at `agent`.
-
-The UI worklet owns transient motion:
-
-- one normalized position (`-1` left, `0` center, `1` right)
-- the current motion target
-- the active gesture's starting revision
-- the last settled target
-
-React publishes the active panel only when the canonical target and the UI-thread position agree at
-the final anchor. Retained content never observes gesture previews, progress, or an unsettled target.
-The gesture hosts stay mounted. Native worklets own overlay opacity and pointer events while
-React owns settled panel activity and accessibility. Keep hidden native overlays laid out: collapsing
-their scroll ranges makes Android spring retained offsets back to zero during touch cancellation or
-release. Native panel hosts and their dependent draggable lists
-also retain identity across appearance hydration and settings changes. Do not wrap those hosts in
-appearance keys; see [Unistyles appearance boundaries](unistyles.md#runtime-theme-patching-for-user-preferences).
-
-## Why one position
-
-Both transforms and both backdrop opacities are derived from the same normalized position. Window
-width is only a projection input. Rotation changes the projection, not the panel state.
-
-This makes these invalid states unrepresentable:
-
-- a panel and its backdrop disagreeing
-- left and right drawers both claiming to be open
-- a width-sync effect resetting an active drag
-- one animation context settling a transition owned by the other
-
-Do not add another panel translate shared value, backdrop shared value, or width synchronization
-effect.
-
-## Ordering and interruption
-
-A gesture captures the current revision when it becomes active. Per-frame updates are accepted only
-while that revision still owns the gesture.
-
-When a React command arrives during a drag, its newer revision clears gesture ownership and starts
-motion toward the new target. The older gesture's remaining updates and finish callback are ignored.
-Canceled gestures return to the latest canonical target. A successful gesture starts its finishing
-motion immediately; the matching React command adopts that motion instead of restarting it. Position
-settlement and command acceptance may arrive in either order. Activity changes after both agree on
-the same target.
-
-Manual gesture arbitration has two phases:
-
-1. Before activation, determine whether horizontal intent may begin.
-2. After activation, stop running begin checks and let the active revision own updates.
-
-Re-running the begin gate after activation self-cancels the gesture because an active gesture is, by
-definition, no longer eligible to begin.
-
-## Integration rules
-
-- Callers request semantic targets through `panel-store`; they never write shared values.
-- Gesture behavior comes from the four explicit hooks in `mobile-panels/gestures.ts`.
-- A focused interactive surface may block panel-opening gestures through
-  `useBlockMobilePanelOpenGestures`. Register only while the conflicting interaction is active and
-  unregister when the surface is hidden or unfocused. The blocker never disables gestures that close
-  an already-open panel.
-- Keep `SidebarModelProvider` outside `MobileGestureWrapper`. The provider shares sidebar derivation
-  across consumers, while Gesture Handler requires the wrapper's direct child to be a native `View`
-  so its injected `collapsable={false}` reaches Android/Fabric.
-- Mobile sidebars render through `MobilePanelOverlay`; do not duplicate overlay lifecycle or motion
-  styles in sidebar components.
-- The desktop left sidebar is retained too. App chrome owns separate mounted and visible decisions:
-  closing it or yielding its width marks it inactive and applies `display: none` without conditionally
-  removing the sidebar tree.
-- Animated panel nodes use React Native static styles plus inline theme values. Do not attach
-  Unistyles-generated styles to those nodes; Unistyles and Reanimated patching the same Fabric node
-  has caused native crashes.
-- `FORCE_REACT_RENDER_FOR_SETTLED_ANIMATIONS` stays off in `packages/app/package.json`. It is a
-  compile-time flag; changing it needs a native rebuild. With it on, Reanimated 4.3 hands settled
-  animated props back to React through a collector that forgets entries older than two seconds. A JS
-  stall across a panel settle loses the final position, and the next React commit reverts the overlay
-  to its last synced props: a backdrop over the workspace while the store says closed. Upstream fixed
-  the collector in 4.4.3, which needs React Native 0.83.
-- Gesture start and progress must not update React state. The retained overlay is already mounted and
-  offscreen; only the shared position and its derived native styles move during a drag.
-- Hidden tabs and workspaces use `RetainedPanel`. It owns a non-collapsible native root, visibility,
-  pointer events, and the active signal consumed by `useRetainedPanelActive`.
-- Panels whose gesture wrapper already owns visibility use `RetainedPanelActivity` to provide the
-  same active signal without adding another layout root. Persistent animations, timers, polling, and
-  shared clocks must subscribe to that signal and stop when their final visible consumer leaves.
-- Synchronized step animations use one wall-clock-aligned source. Register a local shared value only
-  while its retained panel is active so hidden animated styles remain mounted without receiving clock
-  updates. Do not give every instance its own loop or leave hidden styles subscribed to the source.
-- Retention order and render order are separate concerns. LRU metadata may change on every switch;
-  keyed retained roots must keep a stable sibling order. Moving large retained roots triggered Fabric
-  Differ failures (`addViewAt` / `removeViewAt` view reuse) on Android.
-- `useIsMobilePanelActive` follows the settled target, not the requested target. Position at the
-  canonical target's anchor is the settlement signal; animation duration and completion callbacks
-  do not own activity. Cancellation publishes nothing.
-- Do not suspend retained native subtrees with `Suspense`/`react-freeze`. Suspension changes native
-  ownership and can detach descendants. Keep the tree mounted, stabilize its subscriptions/selectors,
-  and use the retained-panel active signal to stop timers, polling, and other genuine background work.
-  Hidden chat content is suspended on web only, through `retained-chat-content.web.tsx`, where DOM
-  nodes carry no Fabric ownership; the native file keeps the chat live.
-
-## Tests
-
-`packages/app/src/mobile-panels/model.test.ts` exercises command, drag, cancellation, interruption,
-rapid-command, position-settlement, and width-projection sequences through the transition model. Add
-a sequence there whenever ownership or ordering changes.

docs/mobile-testing.md

@@ -1,520 +0,0 @@
-# Mobile Testing
-
-## Agent Device
-
-Agent Device `.ad` scripts are the primary mobile E2E format. An agent discovers a working flow interactively, saves the successful commands, then the replay runner executes the same typed plan locally or in CI.
-
-Record a flow while driving the app normally:
-
-```bash
-agent-device open sh.paseo.debug \
-  --platform ios \
-  --session terminal-author \
-  --save-script ./packages/app/e2e/mobile/agent-device/terminal.ios.ad
-agent-device snapshot -i --session terminal-author
-agent-device press 'id="workspace-header-menu-trigger"' --session terminal-author
-# Continue the flow and verify its result with wait/get/is/find.
-agent-device close --session terminal-author
-```
-
-`close` writes the script. Keep selectors based on stable app IDs. Keep assertions as `wait`, `get`, `is`, or `find` commands; screenshots are evidence, not assertions.
-
-Run the Paseo mobile suite:
-
-```bash
-npm run test:e2e:mobile
-```
-
-The runner uses an isolated Agent Device state directory, verifies or starts Metro for this checkout, prewarms the iOS runner, discovers each script's platform from its `context` header, and cleans its sessions, runner lease, daemon, and any Metro process it started. Attempt results, timings, logs, and failure artifacts go under `.dev/agent-device-artifacts`.
-
-Set `PASEO_MOBILE_E2E_METRO_PORT` when this worktree already has Metro on a non-default port:
-
-```bash
-PASEO_MOBILE_E2E_METRO_PORT=62093 npm run test:e2e:mobile
-```
-
-[native-terminal-basic.ios.ad](../packages/app/e2e/mobile/agent-device/native-terminal-basic.ios.ad) and [native-terminal-basic.android.ad](../packages/app/e2e/mobile/agent-device/native-terminal-basic.android.ad) are the smallest examples. Each opens a fresh terminal, types a command at zero delay, submits it, and asserts its distinct output. The app must be connected to a daemon with an active workspace.
-
-For Android keyboard continuity, run the current checkout in the app, open an idle terminal
-with an empty prompt, hide its keyboard, and run:
-
-```bash
-ANDROID_SERIAL=emulator-5554 node packages/app/e2e/mobile/terminal-keyboard/android.mjs
-```
-
-Use a real docked software keyboard. The harness taps Ctrl, Esc, and Enter and checks Android's
-focused input identity and IME hide/show events. It saves screenshots and logs under
-`.dev/agent-device-artifacts/terminal-keyboard-android`. Set `PASEO_TERMINAL_KEYBOARD_APP_ID=sh.paseo`
-to test an installed production build. It never submits a chat message.
-
-`npm run test:e2e:composer-keyboard:android` preserves the chat control and
-keyboard regression flow, then runs the same growth, retained-height, bounds, and
-hold-to-delete and background-tap dismissal scenario on chat, a workspace draft
-tab, and New workspace. It checks empty-content taps and header taps at the cap
-without changing the input height. Each
-host also opens command/file autocomplete, the model selector, the attachment
-menu, and the forge picker from both keyboard states. It then submits a long
-fixture from each host and checks native stream displacement twice: after the
-response settles, and after returning to the bottom and letting the scrollbar
-fade. The image comparison excludes the scrollbar; keyboard dismissal alone
-does not prove that native scrolling receives touches.
-Artifacts are grouped by host under
-`.dev/agent-device-artifacts/composer-keyboard-android`. Configure its daemon,
-Metro, and device through the `PASEO_COMPOSER_KEYBOARD_*` variables in
-`packages/app/e2e/mobile/composer-keyboard/android.sh`. Use a software keyboard;
-the headless input helper cannot verify the
-[visible composer constraints](floating-panels.md#gotcha-3--keyboard-layout-and-portal-anchors).
-
-The Android sidebar scroll-retention flow requires a connected host with enough
-workspaces to overflow the compact sidebar. Pass `TOP_WORKSPACE` and
-`SCROLLED_WORKSPACE` as the `serverId:workspaceId` suffixes of their sidebar row
-IDs. Choose one row near the top and one initially below the viewport. Replace
-the quoted example values below with those IDs. Start in a workspace with the
-sidebar closed and keep the list stable during the run. The same flow checks
-reopening by swipe and button:
-
-```bash
-agent-device replay packages/app/e2e/mobile/agent-device/native-sidebar-scroll-retention.android.yaml \
-  --maestro --platform android --serial emulator-5556 --metro-port 8099 \
-  --env TOP_WORKSPACE='server-id:top-workspace-id' \
-  --env SCROLLED_WORKSPACE='server-id:scrolled-workspace-id'
-```
-
-Pass this checkout's Metro port so the debug app uses the intended bundle.
-For iOS, compare the scrolled row's screen bounds and screenshots across reopening.
-Agent Device's iOS visibility lookup includes offscreen scroll descendants, so
-its `assertNotVisible` cannot establish the starting scroll position for this flow.
-
-On a Play-image emulator, disable Gmail and Calendar first. Their welcome
-screens launch on their own, take input focus, and the run fails with
-`IME did not become visible` while the app still looks focused:
-
-```bash
-adb shell pm disable-user --user 0 com.google.android.gm
-adb shell pm disable-user --user 0 com.google.android.calendar
-```
-
-When replay diverges, read its ranked selector suggestions. Edit the script deliberately and rerun it from the beginning. `--update` is retained for compatibility but no longer rewrites scripts.
-
-## Maestro compatibility
-
-Existing Maestro flows live in `packages/app/maestro/`. Agent Device can execute its supported subset with `agent-device test <path> --maestro`, which provides a migration path while `.ad` coverage replaces these flows.
-
-### Existing flows
-
-Maestro flows live in `packages/app/maestro/`. Reusable sub-flows live in `packages/app/maestro/flows/`.
-
-Run a flow:
-
-```bash
-maestro test packages/app/maestro/my-flow.yaml
-```
-
-### Screenshots
-
-`takeScreenshot` writes to the **current working directory** — there's no way to configure the output path in the YAML. To keep screenshots out of the checkout, `cd` into a temp directory and use an absolute path for the flow:
-
-```bash
-FLOW="$(pwd)/packages/app/maestro/my-flow.yaml"
-mkdir -p /tmp/maestro-out
-cd /tmp/maestro-out && maestro test "$FLOW"
-```
-
-`packages/app/maestro/.gitignore` excludes `*.png` as a safety net.
-
-### Element targeting
-
-Use `testID` or `nativeID` on components, then target with `id:` in flows. Prefer this over text matching — text breaks on copy changes.
-
-```tsx
-// Component
-<Pressable testID="sidebar-sessions" onPress={onPress}>
-```
-
-```yaml
-# Flow
-- tapOn:
-    id: "sidebar-sessions"
-- assertVisible:
-    id: "sidebar-sessions"
-```
-
-### Conditional steps
-
-Use `runFlow:when:visible` for steps that should only execute when a specific element is on screen:
-
-```yaml
-- runFlow:
-    when:
-      visible:
-        id: "sidebar-sessions"
-    commands:
-      - swipe:
-          direction: LEFT
-          duration: 300
-```
-
-This is how `flows/dev-client.yaml` handles Expo dev client screens that only appear in dev builds.
-
-### Don't use launchApp against a running dev app
-
-`launchApp` kills and restarts the app, disrupting Expo dev client state and host connections. For flows that test against an already-running dev app, **omit launchApp entirely** — just interact with whatever is on screen.
-
-Use `launchApp` only in flows that need a clean start (e.g., onboarding tests).
-
-### Swipe gestures
-
-Use `start`/`end` with percentage coordinates for precise control:
-
-```yaml
-# Edge swipe from left to open sidebar
-- swipe:
-    start: "5%,50%"
-    end: "80%,50%"
-    duration: 300
-```
-
-`direction: RIGHT` is simpler but less precise — use it for generic swipes, use coordinates when the start position matters (edge gestures, avoiding specific UI regions).
-
-### Assertions
-
-`assertVisible` checks **actual screen visibility**, not just view tree presence. An element that exists in the tree but is off-screen (e.g., `translateX: -400`) will correctly fail `assertVisible`. This makes it reliable for catching animation bugs where state says "open" but the view is visually hidden.
-
-For async elements, use `extendedWaitUntil`:
-
-```yaml
-- extendedWaitUntil:
-    visible: ".*Online.*"
-    timeout: 90000
-```
-
-### Dev client handling
-
-Two reusable flows handle Expo dev client screens after launch:
-
-- `flows/launch.yaml` — handles dev launcher, dismisses dev menu, asserts "Welcome to Paseo"
-- `flows/dev-client.yaml` — same but without asserting a particular app route
-
-### Reach the composer
-
-`flows/land-in-chat.yaml` is the canonical "get into a chat" primitive. It `clearState`s, runs `launch.yaml`, taps the welcome screen's direct-connection option, types `127.0.0.1:6767`, submits, and waits for `message-input-root`. Compose any composer-level fixture on top of it:
-
-```yaml
-appId: sh.paseo
----
-- runFlow: flows/land-in-chat.yaml
-# ...your scenario here, starting from a ready composer
-```
-
-See `image-picker-repro.yaml` for an example.
-
-**Prefer direct connection over relay pairing for local E2E.** Relay needs a 400+ character pairing URL typed into an input; direct needs `127.0.0.1:6767`. The daemon listens on 6767 and the simulator can reach it directly.
-
-### New Workspace Creation
-
-The Android workspace-creation regression has a dedicated harness:
-
-```bash
-bash packages/app/maestro/test-workspace-create-android-crash.sh
-```
-
-For a short recording that starts after launch/connection/sidebar setup:
-
-```bash
-bash packages/app/maestro/record-workspace-create-android-focus.sh
-```
-
-The flow details are documented in `packages/app/maestro/README.md`. The important rule is that a valid new-workspace assertion must prove the redirect completed: select a real model, tap `Create`, wait for `workspace-header-title`, wait for `message-input-root`, assert `New workspace` is gone, and assert the Android redbox strings are absent. Waiting for the composer alone is too weak because it can still be the `/new` route after a validation error.
-
-New workspace scenarios should compose the reusable subflows in `packages/app/maestro/flows/`:
-
-- `android-dev-client.yaml`
-- `connect-direct-if-welcome.yaml`
-- `open-prepared-project-sidebar.yaml`
-- `new-workspace-open-from-sidebar.yaml`
-- `new-workspace-select-codex-gpt54.yaml`
-- `new-workspace-submit-and-assert-created.yaml`
-
-The workspace-create shell scripts render those subflows into a temp directory before running Maestro, which keeps nested `runFlow` paths and `${PASEO_MAESTRO_*}` placeholders working together.
-
-### Inputs that Maestro types into
-
-Maestro `inputText` fires one character at a time. React Native's **controlled** `TextInput` re-renders per keystroke; if a controlled input's state update lags or re-mounts mid-type, characters are dropped silently — the final value on screen is a truncated/scrambled version of what was "typed."
-
-For inputs that E2E flows type into (host endpoint, pairing URL, etc.), use an **uncontrolled ref-backed input**: `defaultValue` + `onChangeText` writes into a `useRef`, reads via the ref on submit. No per-keystroke re-render, no dropped characters.
-
-See `pair-link-modal.tsx` for the pattern (`useRef`-backed `onChangeText`, no `value=` prop). Always pair the source change with a Maestro `assertVisible` on the input's `id + text` after `inputText`, so regressions are caught immediately.
-
-### Dropdowns that launch native presenters (iOS)
-
-On iOS, when a dropdown menu (`DropdownMenu` / RN `Modal`) item needs to launch a native presenter like `PHPickerViewController` (image picker) or a `UIDocumentPicker`, the callback **must not fire while the `Modal` is still dismissing**. UIKit dismissal completion spans multiple frames beyond React unmount; launching a native presenter mid-dismissal leaves an invisible backdrop mounted that traps every subsequent touch.
-
-`DropdownMenu` handles this by deferring the selected item's `onSelect` until `Modal.onDismiss` fires (UIKit-level dismissal complete), then adds a small extra buffer before invoking it. See `components/ui/dropdown-menu.tsx`'s `selectItem` / `flushPendingSelect`.
-
-When building a new component that composes a dropdown with a native presenter, reuse this dropdown — do not invent a new timing shim.
-
-## Self-verification loops
-
-Maestro can only interact with the app UI — it can't toggle iOS appearance, change locale, or simulate network conditions. For bugs that depend on system-level state, wrap Maestro in a bash script that handles the system changes between Maestro runs.
-
-This pattern also lets agents self-verify fixes without manual user testing.
-
-### Pattern
-
-1. Run baseline Maestro flow (confirm feature works)
-2. Make system-level change via `xcrun simctl` (toggle appearance, etc.)
-3. Re-run Maestro flow (confirm feature still works)
-4. Repeat N iterations to catch intermittent failures
-
-Scripts run `maestro test` from inside a temp directory so screenshots don't dirty the checkout.
-
-See `packages/app/maestro/test-sidebar-theme.sh` for the canonical example:
-
-```bash
-bash packages/app/maestro/test-sidebar-theme.sh 6 1
-# Args: iterations=6, wait_seconds=1 between toggle and test
-```
-
-Key elements of the script pattern:
-
-```bash
-set -euo pipefail
-ITERATIONS="${1:-3}"
-
-for i in $(seq 1 "$ITERATIONS"); do
-  # Toggle system state
-  xcrun simctl ui booted appearance light
-
-  # Wait for change to propagate
-  sleep 1
-
-  # Run Maestro flow and capture result
-  if maestro test "$FLOW" 2>&1 | tee "$ITER_DIR/test.log"; then
-    echo "PASS"
-  else
-    echo "FAIL"
-    xcrun simctl io booted screenshot "$ITER_DIR/failure-state.png"
-  fi
-done
-```
-
-### Android audio focus interruptions
-
-Voice mode uses the custom `expo-two-way-audio` Android module, so incoming calls and other system audio owners must be tested with emulator/system commands, not a JS-only test. To verify that voice resume handles denied audio focus without crashing:
-
-```bash
-adb shell am start -n sh.paseo/.MainActivity
-# Start voice mode in an existing composer, then background Paseo with Home.
-adb emu gsm call 5551234
-# Foreground Paseo while the call is still ringing.
-```
-
-Expected result: Paseo does not throw `RuntimeException: Audio focus request failed`; native audio reports an interruption and voice mode stops or pauses coherently.
-
-### Releasing the audio session when idle
-
-Paseo must not hold the OS audio session once it is neither capturing nor playing, or the user's
-background music stays paused. On iOS this is not just a "while recording" problem: the
-`.playAndRecord`/`.voiceChat` category is non-mixing and survives backgrounding, and iOS re-asserts
-it every time the app returns to the foreground — so one dictation turn kills music for the life of
-the process, on every open, until the app is force-quit. Android holds
-`AUDIOFOCUS_GAIN_TRANSIENT_EXCLUSIVE` with the same effect. It must also reset
-`MODE_IN_COMMUNICATION` and clear the selected communication device; abandoning focus alone can
-leave Bluetooth earbuds on their narrow-band call route without an active microphone indicator.
-
-`createAudioEngine` (`packages/app/src/voice/audio-engine.native.ts`) calls
-`releaseAudioSession()` whenever capture stops and the playback queue drains, and the iOS module
-also releases on `OnAppEntersBackground`. The native side re-guards on `isRecording` /
-`speechPlayer.isPlaying`, because the native engine is a singleton shared by multiple JS engine
-wrappers (voice provider + dictation) and only it knows the true state.
-
-This cannot be validated by a JS test — verify on a device: play music through Bluetooth earbuds,
-open Paseo, use dictation once, stop, and confirm the music resumes at full quality; then
-background/foreground the app and confirm it keeps playing at full quality.
-
-## Unistyles + Reanimated
-
-### The crash
-
-Applying Unistyles theme-reactive styles (`StyleSheet.create((theme) => ...)`) directly to `Animated.View` causes **"Unable to find node on an unmounted component"** on theme change.
-
-Unistyles wraps styled components in `<UnistylesComponent>` and patches native view properties via C++. Reanimated also manages the same native node for animated transforms. When the theme changes, both systems try to update the node simultaneously and the view crashes.
-
-### The fix
-
-Use plain React Native `StyleSheet.create` for static positioning on `Animated.View`. Pass theme-dependent values as inline styles from `useUnistyles()`:
-
-```tsx
-// BAD: Unistyles dynamic style on Animated.View
-const styles = StyleSheet.create((theme) => ({
-  sidebar: {
-    position: "absolute",
-    top: 0,
-    left: 0,
-    bottom: 0,
-    backgroundColor: theme.colors.surfaceSidebar, // theme-reactive
-    overflow: "hidden",
-  },
-}));
-
-<Animated.View style={[styles.sidebar, animatedStyle]} />;
-```
-
-```tsx
-// GOOD: static stylesheet + inline theme values
-import { StyleSheet as RNStyleSheet } from "react-native";
-
-const staticStyles = RNStyleSheet.create({
-  sidebar: {
-    position: "absolute",
-    top: 0,
-    left: 0,
-    bottom: 0,
-    overflow: "hidden",
-  },
-});
-
-const { theme } = useUnistyles();
-
-<Animated.View
-  style={[staticStyles.sidebar, animatedStyle, { backgroundColor: theme.colors.surfaceSidebar }]}
-/>;
-```
-
-Regular `View` components can safely use Unistyles dynamic styles — the conflict is specific to `Animated.View`.
-
-## Native Chat Stream Layout
-
-The native agent stream uses an inverted `FlatList`, so chat layout has three coordinate systems:
-
-- chronological stream order
-- strategy-ordered array order
-- native inverted cell visual order
-
-Do not compute stream neighbors, history/live-head seams, turn footer ownership, assistant block spacing, or tool sequence endings inside React render loops. Those policies live in `packages/app/src/agent-stream/layout.ts` and are unit-tested without React Native rendering.
-
-Platform-specific stream edges belong on `StreamStrategy`:
-
-- forward web uses the last history item as the history/live-head boundary and renders content before a footer
-- native inverted uses the first history item as the history/live-head boundary and compensates for inverted cell child order
-
-If a chat footer looks duplicated or appears above the assistant message on mobile, start with `packages/app/src/agent-stream/layout.test.ts`. Do not add a React Native renderer test for this class of bug; make the pure layout invariant fail first.
-
-## Local iOS device builds
-
-Native changes (anything under `packages/expo-two-way-audio/ios/`, or any new Expo module) **cannot be
-tested over Metro or EAS Update**. Those ship JS only. A stale dev-client binary silently lacks the new
-native functions, so the feature no-ops and the test proves nothing. Rebuild the binary.
-
-Symptom of a stale dev client: `Cannot find native module 'ExpoDocumentPicker'` at startup, followed by a
-cascade of `Route "./X.tsx" is missing the required default export` warnings. The route warnings are not a
-router bug — the module-level throw aborts `_layout.tsx` evaluation, so its default export never gets
-assigned. One missing native module, N confusing warnings.
-
-**Prerequisite: Xcode needs a signed-in Apple ID for the signing team _with a valid keychain token_.** An
-account that merely appears in Xcode → Settings → Accounts is not enough — if its `Xcode-Token` is missing,
-the build below fails at code signing and blames a _certificate_ instead. See
-[Signing needs a working Apple ID token in Xcode](#signing-needs-a-working-apple-id-token-in-xcode) before
-you start, not after it fails.
-
-```bash
-cd packages/app
-npm --prefix ../.. run build:client
-APP_VARIANT=development npx expo prebuild --platform ios
-APP_VARIANT=development npx expo run:ios --device
-```
-
-`APP_VARIANT=development` is required. The `ios` npm script does not set it, and `app.config.js` defaults
-to `production` — so a bare `npm run ios` builds `sh.paseo` and collides with the App Store install instead
-of the `sh.paseo.debug` dev client. Ignore prebuild's `--non-interactive is not supported` warning; use
-`CI=1` if you need non-interactive.
-
-### Signing needs a working Apple ID token in Xcode
-
-Device builds fail with a trio of errors that all point away from the real cause:
-
-```
-error: No Accounts: Add a new account in Accounts settings.
-error: Provisioning profile "iOS Team Provisioning Profile: *" doesn't include
-       signing certificate "Apple Development: <name>".
-error: Provisioning profile "iOS Team Provisioning Profile: *" doesn't include
-       the aps-environment entitlement.
-```
-
-**`No Accounts` does not reliably mean no account is configured.** Check the line _above_ it in the build
-log before believing it:
-
-```
-DVTDeveloperAccountManager: Failed to load credentials for <apple-id>:
-  Invalid credentials in keychain for <apple-id>, missing Xcode-Token
-```
-
-That is the actual failure: the Apple ID is registered in Xcode, but its `Xcode-Token` keychain item is gone
-(typically after an Apple ID password change or a keychain reset). Xcode reports it as `No Accounts`, then
-falls back to whatever stale profile is cached — and if the machine holds a dev cert newer than that
-profile, you get the _certificate_ mismatch as a second-order symptom. Chasing the certificate error is a
-dead end.
-
-Verify what is actually configured rather than trusting the message:
-
-```bash
-# Accounts Xcode knows about
-defaults read com.apple.dt.Xcode DVTDeveloperAccountManagerAppleIDLists
-
-# The credential that is actually missing (error => no token)
-security find-generic-password -s "Xcode-Token"
-```
-
-Fix: Xcode → Settings → Accounts, re-sign-in to the listed Apple ID (removing and re-adding forces a fresh
-token). That restores `-allowProvisioningUpdates`, profile regeneration, and push.
-
-Signing an Xcode-_managed_ profile via `CODE_SIGN_STYLE=Manual` is not a workaround; Xcode rejects it with
-`is Xcode managed, but signing settings require a manually managed profile`.
-
-If you need a build on the device before the token is fixed, build unsigned and sign by hand with a cert the
-cached profile already embeds (list them with `security cms -D -i <profile>.mobileprovision`, then compare
-against `security find-identity -v -p codesigning`):
-
-```bash
-xcodebuild ... CODE_SIGNING_ALLOWED=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY="" build
-cp <profile>.mobileprovision "$APP/embedded.mobileprovision"
-# sign nested frameworks/dylibs first, then the bundle, then:
-xcrun devicectl device install app --device <udid> "$APP"
-```
-
-This is a stopgap, not a fix: `expo prebuild` regenerates `packages/app/ios/` and discards it. It also
-requires stripping entitlements the cached profile lacks (e.g. `aps-environment`), so push is dead in such a
-build.
-
-To verify only that native Swift compiles, skip signing entirely — the pods have their own schemes:
-
-```bash
-cd packages/app/ios
-xcodebuild -workspace PaseoDebug.xcworkspace -scheme ExpoTwoWayAudio \
-  -sdk iphoneos -destination 'generic/platform=iOS' CODE_SIGNING_ALLOWED=NO build
-```
-
-Confirm the log compiled _your_ file and not a cached copy: the `SwiftCompile` line should reference
-`packages/expo-two-way-audio/ios/...`, not a path inside DerivedData.
-
-### Headless launch cannot verify runtime behavior
-
-`xcrun devicectl device process launch` reports `The app terminated with the exit code 0` about a second
-after launch when the phone's screen is off — the app is suspended and killed before the JS bundle loads.
-This is **not** a build defect. Confirm with a control: launch `com.apple.Preferences` the same way and
-watch it exit identically. Headless install and launch prove the binary is valid and that startup reaches
-RN init; anything about on-screen behavior needs a human holding the phone.
-
-## iOS Simulator
-
-```bash
-# Screenshot
-xcrun simctl io booted screenshot /tmp/screenshot.png
-
-# Dark/light mode
-xcrun simctl ui booted appearance          # check current
-xcrun simctl ui booted appearance dark     # set dark
-xcrun simctl ui booted appearance light    # set light
-```
-
-Expo dev server logs are in the tmux pane running `npm run dev`. Daemon logs are at `$PASEO_HOME/daemon.log` (see [development.md](development.md)).

docs/opencode-global-event-baseline.md

@@ -1,49 +0,0 @@
-# OpenCode Global Event Verification
-
-Date: 2026-05-11
-
-## Objective
-
-Replace the OpenCode provider's per-directory `/event` stream with OpenCode's `/global/event` stream and remove the EOF polling recovery path that was added for the `/event` regression.
-
-## Environment
-
-- `opencode --version`: `1.14.46`
-- `which opencode`: `opencode`
-- `node --version`: `v22.20.0`
-- `npm --version`: `10.9.3`
-
-Each OpenCode test file was run independently with:
-
-```bash
-/opt/homebrew/bin/timeout 420s npx vitest run <file> --maxWorkers=1
-```
-
-## Baseline
-
-Before the provider change, the OpenCode matrix had 16 passing files and 4 failing files:
-
-- `packages/cli/tests/e2e/opencode-invalid-model.test.ts`: Vitest reports "No test suite found in file".
-- `packages/server/src/server/agent/providers/opencode-agent.test.ts`: `plan mode blocks edits while build mode can write files` did not observe a completed tool call.
-- `packages/server/src/server/daemon-e2e/opencode-initial-prompt-wait.real.e2e.test.ts`: brittle unavailable-model assertion received an auth failure from the upstream API.
-- `packages/server/src/server/daemon-e2e/opencode-send-interrupt.real.e2e.test.ts`: timed out waiting for an interrupted sleep tool call, even though the recent bash tool call status was `failed`.
-
-## Post-Change Result
-
-After switching to `/global/event`, removing polling recovery, and replacing the brittle initial-prompt model case with `opencode/big-pickle`, the OpenCode matrix had 18 passing files and 2 baseline-equivalent failing files:
-
-- `packages/cli/tests/e2e/opencode-invalid-model.test.ts`: unchanged; Vitest still reports "No test suite found in file".
-- `packages/server/src/server/daemon-e2e/opencode-send-interrupt.real.e2e.test.ts`: unchanged; still times out after the interrupted sleep tool call is already marked `failed`.
-
-The previously failing provider unit file now passes, and `packages/server/src/server/daemon-e2e/opencode-initial-prompt-wait.real.e2e.test.ts` passes with `opencode/big-pickle`.
-
-One live reasoning-dedup matrix run returned no reasoning content; an immediate targeted rerun passed. This appears model-output dependent rather than related to the event-stream change.
-
-## Focused Verification
-
-- `npm run typecheck`
-- `npm run lint`
-- `git diff --check`
-- `npx vitest run packages/server/src/server/agent/providers/opencode-agent.test.ts --maxWorkers=1`
-- `npx vitest run packages/server/src/server/agent/providers/opencode-agent.error-handling.real.e2e.test.ts --maxWorkers=1`
-- `npx vitest run packages/server/src/server/daemon-e2e/opencode-initial-prompt-wait.real.e2e.test.ts --maxWorkers=1`

docs/permissions.md

@@ -1,59 +0,0 @@
-# Daemon permissions
-
-The daemon authorizes principals with semantic permissions. RPC names and protocol namespaces are not authority.
-
-## Model
-
-```text
-principal -> grants
-    |
-    +-- authenticated by a device or service credential
-    `-- opens a session with equal or narrower authority
-```
-
-A principal is the durable identity the daemon authorizes. A credential proves that a device or service represents it. Keep them separate so you can rotate credentials, attach more than one device, and revoke a Hub user without inventing daemon user accounts.
-
-A pairing invitation is neither. It is an expiring, single-use exchange that creates a principal and credential with the permissions selected by its issuer.
-
-## Permissions
-
-| Permission          | Authority                                                                  |
-| ------------------- | -------------------------------------------------------------------------- |
-| `daemon.read`       | Daemon status, diagnostics, configuration, and provider information        |
-| `daemon.manage`     | Restart, update, configuration changes, providers, skills, and plugins     |
-| `tunnel.manage`     | Relay, Hub, service tunnel, and public endpoint relationships              |
-| `access.manage`     | Pairing invitations, principals, credentials, grants, and revocation       |
-| `workspace.read`    | Projects, workspaces, agents, timelines, files, diffs, and terminal output |
-| `workspace.write`   | Prompts, agent control, files, terminals, git operations, and scripts      |
-| `workspace.manage`  | Create, rename, archive, and remove projects and workspaces                |
-| `automation.manage` | Schedules, heartbeats, and loops                                           |
-| `hub.execute`       | Agent lifecycle, workspace titling, observation, and recovery              |
-
-Agents and terminals use workspace authority. Both can execute code and mutate the workspace, so separate write permissions would claim an isolation boundary the daemon cannot enforce.
-
-Owner, operator, and viewer are UI presets expanded into explicit permissions. Do not persist them as roles. Adding a permission must not silently widen an existing principal.
-
-Permissions are additive allows. Missing authority denies the operation. Do not add deny precedence.
-
-## Resources
-
-Permissions are daemon-wide today. Future grants may select workspaces or agents, but operation classification remains inside the authorization module:
-
-```ts
-type Grant = {
-  permission: Permission;
-  resource: { kind: "daemon" } | { kind: "workspace"; ids: string[] };
-};
-```
-
-A delegating principal can grant only authority it already possesses. A session may attenuate its principal's grants but cannot widen them.
-
-Workspace-scoped grants require every resource-bearing operation and outbound observation to enforce the same workspace boundary. File preview currently accepts any daemon-readable regular file, so it must gain resource enforcement before workspace-specific access ships.
-
-## Hub
-
-The Hub authenticates as a service principal. Its locally selected grants decide whether it may execute agents, manage the daemon, manage tunnels, or manage access.
-
-Hub user and role identifiers remain opaque external subjects. The Hub may create and revoke linked daemon principals when granted `access.manage`; the daemon does not interpret accounts, organizations, or roles.
-
-Hub enrollment and permission updates exchange these semantic permissions directly. Legacy persisted Hub relationships that contain `hub.execution.*` migrate once to `hub.execute` when the daemon loads them; new relationships never persist or emit transport scopes as authority.

docs/plan-approval-normalization.md

@@ -0,0 +1,68 @@
+# Plan Approval Normalization
+
+## Goal
+
+Normalize plan approval across providers so the UI renders one consistent plan approval card and action row, while each provider keeps its own execution quirks behind the session permission interface.
+
+## Compatibility Constraints
+
+- Older clients must remain compatible with newer daemons.
+- All new wire fields must be optional.
+- Existing plan permissions without action metadata must still render and work.
+- Existing question permissions must keep their current behavior.
+
+## Design
+
+### Shared abstraction
+
+Add optional permission action definitions to the shared permission request/response types.
+
+- Permission requests may include `actions`.
+- Permission responses may include `selectedActionId`.
+- `kind: "plan"` remains the normalized concept for plan approval.
+- The UI renders actions from the permission request instead of hardcoding provider-specific buttons.
+
+### Claude
+
+Keep Claude's plan permission flow, but enrich it with explicit action definitions.
+
+- Always expose `Reject`.
+- Always expose `Implement`.
+- If the agent entered plan mode from a more permissive mode like `bypassPermissions`, also expose `Implement with <previous mode>`.
+- Resolve the selected action entirely inside `respondToPermission()`.
+
+### Codex
+
+Synthesize a normalized `kind: "plan"` permission after a Codex plan-mode turn completes with a plan result.
+
+- Emit a plan permission with `Reject` and `Implement` actions.
+- On `Implement`, disable `plan_mode`, disable `fast_mode`, and automatically start a follow-up implementation turn.
+- On `Reject`, resolve without starting a follow-up turn.
+- Keep the implementation prompt and state transitions inside the Codex provider.
+
+### Manager and state sync
+
+After permission resolution, refresh provider-derived state so the UI sees internal mode/feature changes without knowing provider quirks.
+
+- Refresh current mode
+- Refresh pending permissions
+- Refresh runtime info
+- Refresh features
+- Persist refreshed state
+
+### UI
+
+Render plan permissions through the existing plan card, but generate buttons from normalized permission actions.
+
+- If `actions` are absent, fall back to legacy buttons.
+- Plan cards should use `Implement` as the default primary label.
+- Do not add provider-specific rendering branches.
+
+## Verification
+
+1. Shared schema/type tests for optional `actions` and `selectedActionId`
+2. App tests for generic plan-action rendering
+3. Claude tests for third action when resuming from a more permissive mode
+4. Codex tests for synthetic plan approval and automatic implementation follow-up
+5. Manager tests for post-permission state refresh
+6. `npm run typecheck`

docs/plugins.md

@@ -1,701 +0,0 @@
-# Plugins
-
-Local plugins contribute daemon RPCs, native app surfaces, workspace panels, Command Center items,
-client slash commands, timeline items, header buttons, composer pills, app themes, composer attachment sources, and settings screens.
-Paseo executes `index.server.ts` in a subprocess and `index.client.tsx` in every connected app.
-
-> **Trust every plugin you add.** `paseo plugin add` and `paseo plugin install` mean “I trust this codebase.” Plugins are unsandboxed: server code and preparation commands run with the daemon user's access on the daemon host, and client contributions run inside Paseo. The repository's dependencies and future updates are part of that trust decision. With `--host`, preparation runs on that remote daemon host.
-
-## Install a directory source
-
-Create a typecheckable plugin project, install its development dependencies, then install it into
-the daemon. `init` only writes the project files; it does not run the package manager.
-
-```bash
-paseo plugin init /absolute/path/to/my-plugin
-cd /absolute/path/to/my-plugin
-npm install
-npm run typecheck
-paseo plugin install /absolute/path/to/my-plugin
-paseo plugin install /absolute/path/to/my-plugin --id another-runtime-id
-paseo plugin ls
-```
-
-The daemon stores directory sources under the root `plugins` object:
-
-```json
-{
-  "pluginsEnabled": true,
-  "plugins": {
-    "my-plugin": {
-      "source": "directory",
-      "path": "/absolute/path/to/my-plugin",
-      "enabled": true
-    }
-  }
-}
-```
-
-Installed plugins are disabled unless `pluginsEnabled` is `true`. Built-in plugins remain active.
-Changing that root field is
-runtime-safe: run `paseo reload` after editing `config.json`. Enabling starts every configured,
-enabled plugin; disabling tears them all down without restarting the daemon. Plugin source entries
-remain lifecycle-owned and do not reload from manual config edits.
-
-The directory contains a manifest declaring identity and Paseo requirements, one optional entry per runtime, runtime-owned
-directories, and local typechecking support. At least one entry is required.
-
-```text
-my-plugin/
-  paseo-plugin.json
-  package.json
-  tsconfig.json
-  index.client.tsx
-  index.server.ts
-  client/greeting.tsx
-  server/greeting.ts
-  shared/greeting.ts
-```
-
-The generated `package.json` installs `@getpaseo/plugin` and the other host modules as development
-dependencies for local typechecking and tests. Paseo compiles TypeScript and TSX and supplies the
-runtime modules, so consumers do not install these packages when adding the plugin.
-
-```json
-{
-  "id": "my-plugin",
-  "requirements": { "paseo": ">=0.8.0" }
-}
-```
-
-Declare the supported Paseo range and keep it current when adopting newer APIs. See the
-[requirements contract](../public-docs/plugins/reference.md#requirements), including legacy
-manifests and prerelease matching.
-
-The config key is the runtime plugin ID. The manifest ID is the default selected during install;
-`--id` overrides it. Existing configuration is not renamed when the manifest changes, and the
-runtime does not compare the two IDs. The same directory can be installed under several config
-keys.
-
-Never enable plugins on a user's behalf without explicit permission. Before asking, check the
-target daemon's current `pluginsEnabled` value. State that plugins are trusted, unsandboxed code:
-backend code can access the daemon machine, while client contributions run inside the Paseo app.
-
-Source changes are explicit. Run `paseo plugin reload <id>` to stop and fully tear down the old
-plugin before compiling and starting from disk. A failed reload stays failed; Paseo does not restore
-the old code. Use `enable`, `disable`, and `remove` to manage one plugin. Removing a directory source
-never deletes it. The global `pluginsEnabled` switch remains available.
-
-## Built-in plugins
-
-Built-in plugins ship from `plugins/<id>/`, with `paseo-plugin.json`, `index.server.ts`,
-`server/`, and optional client entry and icon. Add the plugin ID to `builtinPlugins` in
-`packages/server/src/server/plugins/builtin/index.ts`; the workspace, build copy, and CI
-checks cover that registry. Unlisted directories do not load.
-
-Desktop packaging ships the entire built-in plugin directory as an external resource,
-including declarations. The external esbuild compiler cannot read Electron's `app.asar`
-filesystem, and packaging dependencies excludes `.d.ts` files needed for import validation.
-Built-ins can import only host modules (`@getpaseo/plugin/*`, `zod`) and Node built-ins:
-outside the archive, nothing resolves an npm dependency, and the dist build test cannot catch
-one because it resolves through the repository's `node_modules`.
-The packaged-app smoke check requires every listed built-in to start without relying on
-account credentials.
-
-Built-ins run in process and remain active independently of `pluginsEnabled`. They are
-absent from the installed plugin list and source configuration; their client bundles
-appear in the plugin catalog. Editing one in development requires a daemon restart.
-Directory, Git, and npm installs cannot use a built-in ID.
-
-Provider plugins use separate installation and provider IDs. `muse-provider` registers the
-selectable `muse` provider (Muse Code) and a usage source. Its `status({ launch })` reports
-availability and a diagnostic after the daemon resolves the executable. Configure command,
-environment, or enablement overrides under `agents.providers.muse`. Omit `extends` to keep
-the bundled integration; an entry with `extends` shadows it with a custom provider. See
-[provider contributions](#contribute-a-provider) for the contract and
-[Muse Code](../public-docs/muse-code.md) for setup, per-agent options, and version limitations.
-
-## Install from a registry
-
-`paseo plugin add owner/slug` installs the registry's reviewed artifact by default.
-Browse published plugins at [paseo.sh/plugins](https://paseo.sh/plugins).
-Use `git:owner/repository` or a full Git URL for a Git source. Registry installs
-keep the registry URL and ID, so update checks use its approved pin. Explicit version/ref
-selection is unavailable for registry installs; install an explicit source to select your own.
-
-Registry overviews are untrusted author content, even before installation. Render them with
-`@getpaseo/protocol/plugin-overview`: no raw HTML, HTTPS-only links and images, no relative
-URLs, and isolated external links. The website adapter and corpus tests live in
-`packages/website/src/plugins/overview.tsx` and `overview.test.tsx`; the reusable corpus is
-`packages/protocol/tests/fixtures/plugin-overview.json`. A future app overview must share
-this policy. Installed-plugin descriptions in the app remain plain text.
-
-Use `host/owner/slug` for a registry at `https://host`, or set
-`PASEO_PLUGIN_REGISTRY` to change the default base (including a path prefix).
-Private registry credentials live in daemon config under
-`pluginRegistries: { "host": { "authorization": "Bearer token" } }`.
-Restart your daemon after changing these startup settings. Credentials go only to the registry,
-never artifact hosts or redirects. Git/npm use their own host authentication.
-
-The [open registry protocol](https://github.com/getpaseo/plugins/blob/main/PROTOCOL.md)
-owns static hosting, record shapes, pins, and advisory install counts.
-
-## Install a Git source
-
-GitHub repositories use `git:owner/repository` or `github:owner/repository`. Other hosts use a Git
-URL.
-
-```bash
-paseo plugin install git:owner/repository
-paseo plugin install https://gitlab.com/group/repository.git
-paseo plugin install git:owner/monorepo:plugins/review
-paseo plugin install github:owner/repository --ref main
-```
-
-Append `:relative/path` for a plugin below the repository root. `--ref` chooses the initial
-branch, tag, or commit once. Updates of explicit Git sources resolve the remote's default HEAD
-and ask for approval. `ls` reports the installed commit without contacting the remote.
-
-## Managed source ownership
-
-The [public source reference](../public-docs/plugins/reference.md#plugin-sources) owns identifier
-syntax and npm prerequisites; the [publishing guide](../public-docs/plugins/publishing.md) owns distribution. The CLI resolves directory sources before
-calling `installPluginSource`; see the public source reference for CLI and app path semantics.
-Only the daemon reads plugin files and acquires sources.
-
-`ManagedPluginSources` owns acquisition and offline source description. Config stores the active
-directory; sources.json stores managed kind and the Git acquisition remote. The remote is needed
-because authenticated clones may have a rewritten placeholder origin. Fixed owned directory layout
-provides the selected subdirectory, npm package name and cleanup root. Git HEAD and the installed
-npm package.json checked against package-lock.json provide the current revision. Keep the complete
-npm dependency tree and lockfile after staging activation. No install selector governs updates.
-
-The loader sees only the configured directory and never invokes npm. npm lifecycle scripts are
-disabled during acquisition; manifest preparation owns required commands before validation.
-
-List responses retain the closed `source: directory | git` enum. The optional `installation`
-projection carries identity and current revision. Old npm metadata remains accepted but is no longer
-emitted. Installation uses `features.pluginSourceInstallation`; reviewed preview/apply uses
-`features.pluginSourceUpdates`, gated by the SDK and CLI entry. The old immediate-update request
-returns update-client guidance. Basic management remains independently available.
-
-Preview returns exact targets and expected installed identity/root/revision. Apply validates those
-values, acquires the displayed artifact or commit, then rechecks state before activation. No review
-session is stored in the daemon. PluginService owns activation/recovery and independent bulk results.
-
-### Declare Git preparation
-
-Most plugins should omit `build`. Use it only when the staged checkout must install a dependency
-that Paseo does not provide, generate source or assets, or perform another required preparation
-step:
-
-```json
-{
-  "id": "review",
-  "requirements": { "paseo": ">=0.8.0" },
-  "build": [
-    ["npm", "ci"],
-    ["npm", "run", "build"]
-  ]
-}
-```
-
-`build` is an optional list of argv arrays. Each array must contain at least one non-empty string;
-shell command strings are rejected. Paseo starts the executable directly, without a shell, from the
-plugin directory in the staged checkout. It never detects lockfiles or chooses a package manager.
-
-On install and every update, Paseo resolves the exact Git revision and manifest, runs the declared
-commands, then validates, compiles, and activates the candidate. It logs each argv command and its
-output in the daemon log. If a command fails, the error includes its output, Paseo discards the
-candidate, and the existing installed and running version stays untouched. On a remote daemon, all
-of this happens on the remote daemon host.
-
-Server contributions can write to stdout and stderr with normal Node logging. Paseo adds `[paseo]`
-entries for loading, ready, stopping, and stopped transitions. Compilation and load failures are
-recorded as stderr entries before a subprocess exists. Inspect the recent in-memory
-tail from the host plugin settings or with `paseo plugin logs <id>`. Git preparation commands are
-recorded in `$PASEO_HOME/daemon.log` before a plugin exists, rather than the plugin log tail. Reload, disable, and process
-failure retain the tail; removing the plugin clears it. Daemon restarts do not retain the tail, but
-structured copies remain in `$PASEO_HOME/daemon.log`. Plugin output can contain secrets, so do not
-log credentials or tokens.
-
-## Contribute behavior and UI
-
-Default export one contribution function from each runtime entry. Keep the entries to registration
-wiring. Runtime code lives behind directory boundaries:
-
-| Path                             | Owns                                                                 |
-| -------------------------------- | -------------------------------------------------------------------- |
-| `index.client.tsx` and `client/` | React, React Native, hooks, styles, surfaces, panels, and callbacks. |
-| `index.server.ts` and `server/`  | Node APIs, filesystem and process access, credentials, and handlers. |
-| `shared/`                        | Zod RPC contracts and plain values used by both runtimes.            |
-
-Do not put any other code modules in the plugin root.
-
-Shared files import contract helpers and types from `@getpaseo/plugin`. Server handler files import
-`PluginHandlerContext` from `@getpaseo/plugin/server`. Client files import Paseo UI from
-`@getpaseo/plugin/client/react-native`. Its `Icon` resolves a Lucide name using the client's installed icon
-set; an unknown name renders nothing so it cannot break the plugin surface.
-Its controlled modal keeps presentation metadata on `<Modal title="…" icon={…}>` and body UI in
-`<Modal.Content>`. Body layout, sheet-aware scrolling, and clipboard actions follow the
-[host UI contract](../public-docs/plugins/reference.md#host-ui).
-Plugin UI runs on desktop and mobile across multiple themes: color every `Text` from
-`theme.colors.foreground` or `theme.colors.foregroundMuted`, and size layout from `layout.compact`.
-See `public-docs/plugins/reference.md`.
-
-### SDK import boundaries
-
-Classify every SDK export before adding it. All client entry points and implementations live under
-`client/`; all server entry points and implementations live under `server/`. The package root is shared code: plain data types,
-Zod schemas, and functions that run in both runtimes. A type-only import is still an architectural
-dependency; shared types must not refer to React components, hooks, Node APIs, or server contexts.
-
-| Entry                                                | Owns                                                                       | May depend on          |
-| ---------------------------------------------------- | -------------------------------------------------------------------------- | ---------------------- |
-| `@getpaseo/plugin`                                   | Shared data, schemas, RPC/settings definitions, runtime-neutral helpers    | Shared code only       |
-| `@getpaseo/plugin/server`                            | Server contexts, lifecycle contracts, and CLI process launch               | Shared and server code |
-| `@getpaseo/plugin/server/provider`, `/server/acp`    | Server provider contracts and adapters                                     | Shared and server code |
-| `@getpaseo/plugin/client`                            | Client contribution contexts, hooks, navigation, and UI contribution types | Shared and client code |
-| `@getpaseo/plugin/client/react-native`, `/client/ui` | Host-provided UI components                                                | Shared and client code |
-| `@getpaseo/plugin/client/host`                       | App-owned rendering integration; not a plugin-author entry                 | Shared and client code |
-
-Server code imports shared helpers from the root and server capabilities from `/server`. Client
-code imports shared helpers from the root and client capabilities from `/client`. Neither runtime
-imports the other. Re-exports follow the same rule; tree shaking does not establish a boundary.
-React, React Native, JSX runtimes, and client hooks must never be reachable from the root or any
-server entry. Node and platform-specific code must never be reachable from the shared root.
-
-The SDK boundary checks and real plugin-subprocess tests enforce these rules. Every SDK change
-must preserve them and update the public reference, migration guide, scaffold, and examples when
-an author-facing import changes. The plugin compiler enforces the same runtime entry rules for
-plugin-authored code. Keep the package export map and host-provided module maps consistent.
-
-The compiler rejects imports across runtime directories or SDK entries, React dependencies in
-server code, and Node imports in client code (including bare names such as `fs`). Shared modules
-cannot import runtime-owned modules. Forbidden imports fail compilation; never replace them with
-empty module stubs. A relative
-import to any other code file in the plugin root is also rejected; move it into `client/`, `server/`,
-or `shared/`. These are compile errors naming the importing file and boundary rule. Top-level React
-Native calls such as `StyleSheet.create` belong in `client/`.
-
-The scaffold omits `"DOM"` from `tsconfig.json` and does not use `/// <reference lib="dom" />`, so
-browser globals are not available across the plugin. Put sanctioned web-only APIs in
-`client/web.ts`, declare only the globals that module uses, gate each export with
-`Platform.OS === "web"`, and provide a native implementation or no-op. See the
-[public plugin reference](../public-docs/plugins/reference.md#works-on-mobile) for the complete
-pattern.
-
-```ts
-// index.server.ts
-import type { PluginServerContext } from "@getpaseo/plugin/server";
-import { createGreeting } from "./server/greeting";
-import { greetRpc } from "./shared/greeting";
-
-export default function contribute(server: PluginServerContext) {
-  server.handle(greetRpc, createGreeting);
-  return () => {};
-}
-```
-
-```tsx
-// index.client.tsx
-import type { PluginClientContext, PluginSidebarItemProps } from "@getpaseo/plugin/client";
-import { SidebarRow } from "@getpaseo/plugin/client/ui";
-import { Greeting } from "./client/greeting";
-
-function GreetingItem({ currentScreen, openScreen }: PluginSidebarItemProps) {
-  return (
-    <SidebarRow
-      icon="MessageCircle"
-      active={currentScreen?.screenId === "main"}
-      onPress={() => openScreen({ screenId: "main" })}
-    />
-  );
-}
-
-export default function contribute(client: PluginClientContext) {
-  client.addScreen({ id: "main", title: "Greeting", Component: Greeting });
-  client.addSidebarHeaderItem({ id: "main", title: "Greeting", Component: GreetingItem });
-  return () => {};
-}
-```
-
-The contribution function must return cleanup. Server cleanup may be async; Paseo waits for it when
-the plugin is reloaded, disabled, removed, disconnected, or shut down. Cleanup is for resources
-created by plugin code. Paseo removes registered contributions, unmounts surfaces, clears query
-state, rejects pending RPCs, closes the plugin's daemon session, and stops the subprocess. Cleanup
-errors are logged and do not interrupt host teardown.
-
-Paseo owns the route, screen header, Lucide icon validation, close action, theme DTO, layout facts,
-and render error boundary. The contributed component owns the complete body below the header.
-The plugin owns the header's text through the screen's `title` (`resolvePluginScreenTitle` in
-`plugins/surface-contribution.ts`). A legacy `addSidebarItem` route (`/sidebar/<id>`) shows the
-item's title and icon instead, as before screens had titles; the `addSurface` alias titles its
-screen with the id. A `/sidebar/<id>` route with no legacy item of that id opens the screen with
-that id, so links saved before a plugin migrated keep working.
-
-Screen params ride in the screen route's query string (`plugins/routes.ts`), not in app state, so
-reload, history, links, and the host switcher keep them without a store. Expo Router merges the
-route's segments (`serverId`, `pluginId`, ...) into the same search params as the query, so param
-keys are stored under a `param.` prefix; plugins never see it and may use any key.
-`openScreen` validates its input once (`parsePluginOpenScreenInput`); code past it trusts the
-params.
-
-RPC contracts validate inputs and outputs in both the app and plugin subprocess. `useRpc` returns a
-typed async function. Use the host-provided `@tanstack/react-query` for request state and caching;
-Paseo gives each plugin installation its own query client.
-
-`usePaseo()` and the handler's `{ paseo }` context expose the same `PaseoApi`: projects,
-workspaces, agents, terminals, providers, and daemon config. They do not expose connection lifecycle.
-
-`usePaseo()` is the plugin's one client: `InstalledPlugin.paseo`, created with the installation in
-`packages/app/src/plugins/registry.ts` over the host's existing connection and passed to setup as
-`client.paseo`. Authors release their subscriptions in their own cleanup, and teardown (disable,
-reload, removal, host removal) disposes the client, which ends the rest; nothing is created or
-disposed per mounted surface. See the
-[public example](../public-docs/plugins/reference.md#use-the-paseo-sdk). Switching the screen's host
-changes both `usePaseo()` and `useRpc()` to that host's installation. An offline selected host fails there and never falls through to another
-installation. A server handler owns an IPC-backed daemon session for the life of its subprocess.
-Use plugin RPC for plugin-specific backend behavior that is not a normal Paseo operation.
-
-Host-targeted clients and discovery are owned by `packages/app/src/plugins/hosts`, with per-installation
-bindings supplied by the bundle loader. Bind the imperative getter to that installation; do not
-resolve ownership through a mutable current-plugin global. Keep observation ownership in this module
-and transport ownership in the app host runtime. See the [public host API contract](../public-docs/plugins/reference.md#discover-hosts-and-target-another-host).
-
-Each subprocess gets an exclusively owned `plugin:<id>` session. That identity is reserved from
-normal clients, never resumes another session, and is cleaned immediately on exit without reconnect
-grace. During daemon startup, plugin sessions may connect while application WebSockets remain
-paused; the daemon accepts clients only after configured plugins have settled and the initial
-catalog is complete.
-
-When the same plugin contribution exists on multiple hosts, Paseo shows it once in the sidebar and
-adds a host picker to the screen header. The selected host supplies the bundle, RPC transport, and
-query cache. Explicit SDK targets follow the [host API contract](../public-docs/plugins/reference.md#discover-hosts-and-target-another-host).
-
-Workspace panels, Command Center items, and client slash commands are client contributions. The
-daemon transports their compiled bundle without interpreting placement or callbacks. Panel props
-contain workspace and agent IDs. Required-selector hooks read normalized client state synchronously
-and use shallow equality, so a panel does not subscribe to fields it does not render. Command
-callbacks materialize their snapshots only when invoked. Contribution discovery and panel opening
-never fetch active context through plugin RPC. Snapshot DTOs are deeply readonly and frozen at
-runtime so plugin code cannot mutate normalized app state or a memoized selection. Panels use one persisted
-`plugin` workspace-tab target, so reload, disable, removal, and restoration resolve through the
-current installed-plugin catalog. A missing contribution renders unavailable inside the tab.
-Panels declare `locations: ["workspace", "explorer"]` to opt into Explorer hosting; omission means
-workspace only. Location controls hosting, not context. An agent panel target keeps its `agentId`
-when moved between hosts. Explorer configuration can create workspace-context panels and remove
-existing agent-context instances, but it cannot create an agent panel without an agent-aware command.
-
-Command Center callbacks use the selected host's existing `PaseoApi` for normal Paseo operations.
-They use typed plugin RPC only for plugin-specific backend work. Surface and panel navigation
-belongs to the app; plugins do not receive Expo Router or workspace-layout store access.
-See the public [navigation fields](../public-docs/plugins/reference.md#screens-and-sidebar-items)
-and [external links and workspace browsers](../public-docs/plugins/reference.md#external-links-and-workspace-browsers)
-for the author-facing contract.
-
-## Lifecycle hooks
-
-Server entries register lifecycle observers with `server.on()` and request transforms with
-`server.before()`. The [public reference](../public-docs/plugins/reference.md#lifecycle-hooks)
-owns callback shapes, ordering, and failure behavior. `plugin-examples/lifecycle-logger` registers all
-eleven hooks; `plugin-examples/lifecycle-actions` demonstrates common automation callbacks.
-
-Emit from the operation owner, not a client subscription. Provider history replay must not trigger
-live hooks. Observers must not be awaited inside agent mutations: a callback can send a prompt or
-answer a permission through its own daemon session. Awaiting it there deadlocks that command.
-
-## Contribute a provider
-
-Register a provider from `index.server.ts`. The provider connection is callback-based and owns all
-of its sessions; plugin RPC is not part of the provider data path.
-
-```ts
-import type { PluginServerContext } from "@getpaseo/plugin/server";
-import type { ProviderRegistration } from "@getpaseo/plugin/server/provider";
-import { createProvider } from "./server/provider";
-
-export default function contribute(server: PluginServerContext) {
-  server.registerProvider(createProvider() satisfies ProviderRegistration);
-  return () => {};
-}
-```
-
-Declare `command: ["agent", "serve"]` when your provider launches an executable. The daemon applies
-`agents.providers.<id>.command` and `env`, resolves the executable against the effective PATH, and
-removes parent-session and daemon-control environment variables. `connect({ launch })` receives
-`{ command, args, env }`: an executable path, effective arguments, and the complete sanitized
-environment. Spawn with those values; do not merge the plugin process's environment back in.
-The launch travels as data through the same provider protocol for built-in and subprocess plugins.
-Without a declared command, existing providers keep their connection behavior and receive no launch.
-
-Implement optional `status({ launch })` to check credentials, versions, or other prerequisites using
-that effective launch. Return `{ available: true }` or
-`{ available: false, diagnostic: "Run agent login" }`. The daemon checks executable availability
-before calling status; it exposes your diagnostic through the normal provider diagnostic command.
-A command-backed provider without status is available when its executable resolves. Providers with
-neither command nor status retain connection-based availability.
-
-A same-ID config entry without `extends` overrides the plugin's `enabled`, `command`, `env`, label,
-description, and model configuration through the normal provider registry. `enabled: false` disables
-selection and discovery. An entry with `extends` defines the user's own provider, shadows the plugin,
-and logs a warning. Overrides validate before plugins load; an override for an absent plugin stays
-inactive and logs a warning naming the unmatched ID after built-in and configured plugin startup
-settles (including disabled plugins), then on each installed registry generation.
-Use IDs matching `/^[a-z][a-z0-9-]*$/` for configurable providers. Dots and underscores
-remain valid for plugin registration but cannot be used as config provider IDs.
-
-Provider config changes rebuild the affected registry entry and invalidate its catalogue; the next
-connection receives the new launch without restarting the daemon. Running sessions keep their
-current launch until refreshed, as native providers do.
-
-Implement optional `ProviderRegistration.getCatalogCacheKey(options)` to share equivalent catalogue
-probes. The callback runs in the plugin process before discovery and receives the actual global or
-workspace target plus the resolved `launch` when a command is declared. Return a key covering
-effective configuration and execution environment, or
-`undefined` for target-specific caching. Ignore `force` when choosing identity. Existing providers
-need no change. See [catalogue ownership](providers.md#provider-snapshot-refresh-contract).
-
-`send()` resolves after acceptance. Publish operation completion, prompt disposition, turn state,
-configuration, permissions, persistence, and complete timeline snapshots through `onEvent()`.
-Route messages, structured commands, steering, and command side effects through `session.prompt`.
-Provider settings are toggle/select data that Paseo renders in the composer. Keep private options in
-the opaque `ProviderSessionConfig.providerOptions` object on `session.open`.
-It contains the provider defaults and per-agent overrides merged by the daemon.
-Validate and apply it inside the provider; core does not know your option shape.
-See [provider options](custom-providers.md#provider-options) for configuration and
-merge semantics.
-
-Agent refresh closes the current provider session and opens it again with current configuration and
-persistence. Re-read credentials and provider-owned configuration on `session.open`; consume the
-daemon launch from `connect` and the per-session env and MCP servers from `session.open`. There is
-no provider reload input.
-
-For an ACP command, register `runAcpProvider({ id, label, command })` from
-`@getpaseo/plugin/server/acp`. Its transformer hooks cover narrow vendor differences; do not translate the
-whole provider event stream. The shim uses the resolved launch for every probe and session, overlaying
-only the supplied per-session env for sessions. The direct and ACP examples live in
-`plugin-examples/provider-direct`
-and `plugin-examples/provider-acp-transformer`.
-
-Provider-emitted plugin timeline items use the same renderer registration as transformed and
-daemon-appended plugin items. The direct example includes both sides. The renderer-only
-`plugin-examples/inline-thinking` example shows that timeline presentation remains independent of a
-provider implementation. The public [provider plugin guide](../public-docs/plugins/providers.md)
-owns author workflow, lifecycle, testing, and distribution guidance.
-
-`ProviderRegistration.icon` is a file path relative to the plugin directory, such as `icon.svg`.
-It must resolve inside that directory to a regular SVG file no larger than 64 KiB. The SVG must be
-self-contained: scripts, styles, `foreignObject`, event-handler attributes, JavaScript URLs, and
-external `href` or `xlink:href` references are rejected. Fragment references such as `#mark` are
-allowed. Paseo reads and sanitizes the file when the plugin starts; the string is never an inline
-SVG or URL.
-
-## Usage sources
-
-Register a usage source from `index.server.ts` with `server.registerUsageSource()`. Import `UsageSourceRegistration` and normalization helpers from `@getpaseo/plugin/server/usage`. The plugin owns account discovery, harness labels, and credential-store reads; the daemon owns account grouping and the fetch cache. Agent popovers use only the agent's own login. The host-wide Usage modal falls back across an account's logins; any success shows usage only, and all failures show every login's labeled error and remedy. Follow the [usage source discovery contract](../public-docs/plugins/reference.md#usage-sources). The resolved launch environment crosses into the trusted, unsandboxed plugin subprocess for session discovery. Usage queries never run lifecycle hooks. Inputs are validated in the plugin process and remain daemon-side. `icon` uses the same sanitized SVG file rules as provider icons.
-
-The daemon calls discovery for `usage.list_reports`; the client gates this RPC on `server_info.features.usageSources`. The old `provider.usage.list` RPC maps discovered reports for older clients.
-
-## Contribute sidebar items
-
-Sidebar header and footer items are plugin components, not descriptors. The
-[public reference](../public-docs/plugins/reference.md#sidebar-items) owns the author API. The host
-lives in `packages/app/src/plugins/sidebar-items/`; `packages/app/src/sidebar-nav/model.ts` resolves
-one section's order from built-ins, plugin groups, and the section's preference
-(`sidebarNavItems` or `sidebarFooterItems`).
-
-- The item's `Component` renders directly in the section, with no wrapper, so a fragment or array
-  of rows lays out like separate items while Settings keeps one entry for the block. Footer items
-  are rows between Add project and the footer's icon row. The icon row (Hosts,
-  Help and support, Settings) is fixed app code, not a contribution slot, so the kit has no icon
-  button.
-- `openPopover` opens through the same `PluginPopoverSurface` as header buttons
-  (`plugins/popover.tsx`). Any press inside a `SidebarRow`, including its `trailing` content, moves
-  the menu anchor to that row: a capture-phase `onStartShouldSetResponderCapture` runs before the
-  pressed child claims the touch on native and web, and returns false. Keyboard activation skips
-  the responder system, so the row's own press anchors too. Until a press, the first mounted row
-  holds the anchor. An item that renders no kit component
-  anchors to its section container.
-- `SidebarSeparator` reuses the app's separator and cancels the footer's horizontal padding, so
-  the line runs edge to edge in both sections.
-- `SidebarRow.trailing` sits in a second `Pressable` beside the row's button, since web cannot nest
-  buttons. Its `onPress` is the row's, so a press on non-interactive trailing content presses the
-  row; a button inside it wins its own press because only the innermost pressable responds.
-- A new-API item renders from the current route's host, else the host remembered under
-  `pluginScreensHostKey(pluginId)`, which the screen's host switcher and the item's `openScreen`
-  set. One key per plugin: switching host on any of its screens moves all its items.
-- `addSurface`, `openSurface`, and `addSidebarItem` are undocumented aliases, tagged
-  `COMPAT(pluginSidebarAliases)`. `addSidebarItem` is recorded only in `legacySidebarItems` and
-  groups as a `legacy` sidebar group, which the app draws as its own row: its registered icon, in
-  the sidebar and in Settings > Sidebar, opening `/plugin/<id>/sidebar/<item>` on the host it
-  remembers under its own key. It shares header ids and the `plugin:<pluginId>:<id>` settings key
-  with new-API items.
-
-## Contribute buttons
-
-Header buttons and composer pills share the client-only descriptor and registration lifecycle in
-`packages/app/src/plugins/buttons/`. The [public button reference](../public-docs/plugins/reference.md#header-buttons)
-owns the author API and placement rules. Keep presentation policy in this module so another
-placement can reuse behavior without copying registration or action state.
-
-Native sheets teleport their children. Button surfaces rebuild the installation's SDK, state,
-query, and toast providers inside the surface content, including overflow pages from different
-plugins. Providers only around the trigger do not reach those bodies.
-
-Request observation with `client.paseo.agents.list({ subscribe: {} })` and consume the returned
-`subscription` handle. Plain `list()` and agent/workspace directory `.subscribe(handler)` listeners create no daemon
-demand. Provider and project `subscribe()` calls establish their own demand. On capable daemons, each
-list-and-subscribe call has its own server ID, even for the same query. Older daemons retain
-[shared delivery behavior](protocol-compatibility.md#owned-observations). Handle snapshots
-also run after reconnect; replace your view before applying its subsequent updates. The installation
-owns every observation created through its API and releases them on unload, including setup failure.
-Mounted surfaces and command invocations have shorter API lifetimes.
-
-Keep the client entry synchronous: return its cleanup function immediately and start asynchronous
-work inside it. See the maintained [composer pill example](../plugin-examples/local-plugin/client/main.tsx).
-
-## Contribute timeline items
-
-Timeline transformers and renderers are client contributions. The daemon's canonical rows and
-built-in projection stay unchanged. The app transforms each source item while building the render
-model, for both fetched history and live events, before native Markdown splitting and Overview
-tool grouping. Assistant callbacks receive the accumulated source text, never display fragments.
-Live assistant messages use `phase: "streaming"`; committing to history makes them `"complete"`.
-Paseo memoizes by source-item reference and phase and derives replacement IDs from source identity, so
-streaming updates preserve mounted component identity.
-
-`query.itemType` selects one public `AgentTimelineItem.type`. The callback owns any detailed
-recognition and returns plain plugin item objects. `undefined` keeps the source item, `items`
-replaces it, and an empty array removes it. Output `data` must be JSON-compatible. Paseo adds the
-runtime plugin ID, preserves the source timeline cursor and identity, validates renderer data with
-its Zod schema, and mounts the component inside the normal plugin runtime and error boundary. An
-optional output `id` distinguishes several stable replacements from the same source item; its output
-index is the default.
-
-Transformers run synchronously and must be deterministic. When several transformers match, the
-first one that returns a result owns that source item. Plugin and registration ordering is stable.
-See `plugin-examples/timeline-items` for the complete contract.
-
-A plugin subprocess can also append a canonical plugin row from a server handler:
-
-```ts
-await paseo.agents.ref(agentId).timeline.append({
-  type: "plugin",
-  id: "review",
-  kind: "review-result",
-  version: 1,
-  data: { status: "ready" },
-});
-```
-
-The daemon stamps the runtime `pluginId`; plugin code never supplies it. Reusing the same `id`
-replaces the previous row from that plugin on live clients and fresh timeline fetches. Rows live in
-the daemon's in-memory timeline and survive scroll, refetch, and reconnect, but not a daemon
-restart. A row without an installed renderer shows an unavailable placeholder. Serialized `data`
-must be at most 64 KiB; the daemon rejects a larger append instead of storing a payload that cannot
-be rendered intact. The daemon advertises this RPC through
-`server_info.features.pluginTimelineItems`.
-
-## Contribute client slash commands
-
-`addSlashCommand` registers an agent- or workspace-context command in the composer. The
-callback runs in the app, receives the trimmed text after the command name as `args`, and receives
-the same `paseo`, `rpc`, `openScreen`, workspace, agent, and `openPanel` capabilities as the matching
-Command Center callback.
-
-```ts
-client.addSlashCommand({
-  name: "review",
-  description: "Run the review bot",
-  argumentHint: "[scope]",
-  context: "agent",
-  async onSubmit({ args, agent, rpc }) {
-    await rpc(startReview, { agentId: agent.id, scope: args });
-  },
-});
-```
-
-Paseo owns the autocomplete row, input clearing, and error toast. It never sends the command text to
-the agent. Built-in client commands win name and alias collisions, plugin commands win
-provider-command collisions, and the first plugin in stable catalog order wins collisions between
-plugins. Plugin slash commands do not run when the composer has attachments.
-
-## Contribute composer attachments
-
-Register a declarative attachment source backed by a plugin RPC. Paseo owns the attachment menu,
-search picker, drafts, selected pill, and submission. The plugin returns complete text snapshots;
-credentials and vendor API calls stay in the daemon handler.
-
-```ts
-// index.server.ts
-import type { PluginServerContext } from "@getpaseo/plugin/server";
-import { search } from "./server/issues";
-import { searchIssues } from "./shared/issues";
-
-export default function contribute(server: PluginServerContext) {
-  server.handle(searchIssues, search);
-  return () => {};
-}
-```
-
-```tsx
-// index.client.tsx
-import type { PluginClientContext } from "@getpaseo/plugin/client";
-import { issues } from "./shared/issues";
-
-export default function contribute(client: PluginClientContext) {
-  client.addAttachmentSource(issues);
-  return () => {};
-}
-```
-
-Attachment sources stay scoped to the composer's host. Unlike sidebar contributions, equal sources
-on several hosts are not coalesced. The selected snapshot submits as a text attachment with neutral
-external-resource presentation, so it remains readable if the plugin is removed or an older peer
-drops the optional presentation fields.
-
-## Contribute settings
-
-Register ordinary components with `client.addSettingsScreen` and open them with `openSettings`.
-The host settings shell owns navigation and layout; plugin content must not add another page
-scroll view or header. See the [author contract](../public-docs/plugins/reference.md#settings-screens)
-and `plugin-examples/settings` for the named UI components and persistence API.
-
-Settings storage is scoped to the runtime installation ID, never the source path or manifest ID.
-Its writer lives with the plugin subprocess, while its directory lives outside managed sources,
-so updates and reloads retain values. Settings-change notifications must not enter the catalog
-reload path: that path disposes the plugin and would destroy open drafts after every save.
-
-`server.registerSettings(definition)` returns a server-side handle. Use `read()` for the current
-`ready` or `invalid` state and `subscribe()` for successful saves, resets, and migrations. The
-subscription cleanup belongs in the plugin's contribution cleanup when it outlives the entry.
-
-## Contribute a theme
-
-`addTheme` takes a small light or dark palette and a display name. Paseo expands it through the
-same semantic builders as the built-in themes, so plugins do not depend on the complete app token
-contract. Unistyles needs every theme name at `StyleSheet.configure` time, so
-`packages/app/src/styles/theme.ts` reserves one light and one dark plugin slot. The appearance
-provider rewrites the matching slot when the selection changes. See [unistyles.md](unistyles.md)
-for the runtime-patching rules the appearance settings share.
-
-`addTheme` is a client registration and belongs in `index.client.tsx`. A client that predates it
-cannot evaluate that entry. Daemons advertise
-`features.pluginThemes` in `server_info`; the plugin theme catalog is the one place the app reads it, and
-a host without it contributes no themes.
-
-The selection persists as `theme: "plugin"` plus a `pluginThemeId` of `<pluginId>/theme/<themeId>`,
-so equal themes on several hosts coalesce the way sidebar contributions do. Two hosts can answer
-that id with different palettes, so picking a theme records its host through
-`rememberPluginContributionHost` and resolution prefers it; a peer connecting or dropping then does
-not repaint the app. Without a preference the sorted registry snapshot decides, so the result is
-stable rather than arrival-ordered. The app resolves that id
-against the installed catalog on every change; an id nothing contributes falls back to the default
-preference instead of painting the reserved slot's placeholder colors.
-
-Existing plugin authors should follow the standalone [v0.8 runtime-entry migration guide](../public-docs/plugins/migration.md).
-
-See `plugin-examples/local-plugin` for a native surface, `plugin-examples/linear` for a complete
-attachment-source example, `plugin-examples/timeline-items` for timeline projection, and
-`plugin-examples/catppuccin` for a theme.

docs/product.md

@@ -1,102 +0,0 @@
-# Product
-
-Paseo is an environment for running, monitoring, and interacting with coding agents across desktop, mobile, web, and the command line.
-
-**Paseo has a lean, opinionated core built to be extended.** It should be easy to start using and leave room for people to build far beyond the default experience.
-
-## Agents are the focus
-
-The central workflow is giving an agent a task, understanding what it is doing, providing direction, and reviewing the result. Files, terminals, diffs, and other supporting tools help you do that.
-
-Paseo should make this workflow coherent across providers and devices. You should be able to use the agent that fits a task and keep working from another device without rebuilding your environment around it.
-
-This is the basis for product decisions. A familiar feature from another development tool earns its place by improving that experience. Familiarity alone does not make it a requirement for Paseo.
-
-## A low floor and a high ceiling
-
-### Easy to start
-
-The default experience should be lean, polished, and understandable to someone who has never run a server or configured a VPN.
-
-With a supported coding agent installed and authenticated, you can open the desktop app and start working. The app manages its local daemon. To connect your phone through the optional Paseo relay, enable pairing and scan a QR code. You do not need to configure a VPN or understand the networking behind it.
-
-You should not need to know that plugins exist to get a useful, complete experience. Extra capability should become discoverable when it helps with something you want to do.
-
-Keeping this starting point approachable is an ongoing responsibility. A technically correct feature can still make the product harder to understand through extra choices, controls, or setup.
-
-### Room to build your own setup
-
-The same product should also work for someone running agents on a home server, using their own network, or building an automated workflow.
-
-The daemon can run independently of the desktop app. Clients connect to it locally or remotely, and multiple clients can use the same daemon. This separation lets you choose where the work runs and how you interact with it.
-
-For example, someone can use the relay to connect their phone with minimal setup. Someone else can run a daemon on their own infrastructure and connect through SSH or a VPN. Both use the same underlying system.
-
-Paseo should provide useful defaults while keeping these choices available. You should not have to adopt every part of the system to benefit from the parts you want.
-
-See the [connectivity guide](https://paseo.sh/docs/connectivity) for supported connection methods and [architecture](architecture.md) for the system design.
-
-## Freedom, ownership, and privacy
-
-Paseo's flexibility depends on keeping control with the user:
-
-- **Self-hosted:** Run agents on your own machines, with your own environment, files, and credentials.
-- **Provider choice:** Use supported agent harnesses and extend provider support through plugins. Your workflow should be able to evolve as your choice of provider changes.
-- **Cross-device:** Use desktop, mobile, web, and CLI clients according to the situation.
-- **Privacy:** No Paseo telemetry, tracking, or forced account. The relay is optional and end-to-end encrypted.
-- **Open source:** Paseo is Apache-2.0 licensed. You can inspect it, modify it, and build on it.
-
-Convenience and ownership should work together. Offering a straightforward way to connect should preserve the option to operate your own setup.
-
-## A lean core that keeps improving
-
-The core provides the shared experience: starting work, interacting with agents, understanding their state, and moving between workspaces and devices.
-
-Core development continues through improvements to reliability, performance, interaction design, and workflows with broad value. A lean core takes ongoing work.
-
-Every addition also has a lasting cost. It needs a place in the interface, an understandable relationship with existing behavior, testing across affected platforms, and maintenance as the rest of the product changes. A feature can work exactly as intended and still be the wrong addition.
-
-The preference is for a small number of well-shaped capabilities that work together. Before adding a specialized workflow, consider whether an existing capability can serve it or whether a reusable extension point would let people build it themselves.
-
-The boundary can evolve. Some built-in capabilities may eventually make more sense as plugins. Any such move needs to preserve a coherent default experience and account for people who already depend on it.
-
-## Extensibility and composition
-
-Plugins are a central part of how Paseo gains capability.
-
-Someone who needs a different agent provider, a specialized workspace panel, or a custom command should be able to build and share it independently. They can make the choices that fit their users and maintain the integration on their own schedule.
-
-Paseo's role is to provide interfaces that make those contributions possible across the daemon and connected clients. The [plugin documentation](https://paseo.sh/docs/plugins) describes what each released API supports.
-
-The [SDK](https://paseo.sh/docs/sdk) lets applications and services use the daemon directly. A separate dashboard, automation service, or client can build on the same agent infrastructure. Those projects do not all need to become features of the main app.
-
-Composition means useful pieces can be combined in ways the maintainer did not have to predict. Keeping the daemon independent, offering multiple connection methods, and exposing agent operations through APIs gives people room to choose those combinations.
-
-The extension interfaces need the same care as the core experience. They should be understandable, reusable, and maintainable. New extension points should follow concrete workflows that need them.
-
-## How Paseo develops
-
-Product, design, architecture, and workflow decisions remain with the maintainer.
-
-Those decisions draw on the history of the product: why a workflow has its current shape, what previous approaches taught us, how it interacts with the rest of the system, and where it is intended to go. Documentation shares that context, but familiarity also develops through sustained use and maintenance.
-
-Development starts with the smallest useful change that can make a substantial difference. After shipping it, leave room to learn:
-
-- Can people discover and understand it?
-- Does it work well in their actual workflows?
-- What friction or missing capability appears with repeated use?
-- Does the next addition improve the shared experience or belong in a plugin?
-
-That feedback guides the next step. Expanding a workflow too far before people use it creates commitments that are difficult to reverse. Users build habits and integrations around what ships, so removing features or changing interfaces has a real cost.
-
-Writing an implementation is one part of this process. Product judgment, design, QA, review, and learning from use determine how quickly a change can responsibly become part of Paseo.
-
-## An ecosystem people can build on
-
-People contribute through reproducible bug reports, testing, workflow discussions, documentation, plugins, integrations, and helping each other.
-
-A plugin can solve a problem for its users without adding that workflow to everyone's default experience. An alternative client can explore a different interface while using the same daemon. These projects let people take ownership of the experience they want.
-
-The aim is an ecosystem that can develop independently of the maintainer's ability to review core changes. Its value comes from useful things people build, maintain, and share.
-
-Paseo is an independent project. Sustainable development, a coherent product, and the freedom to keep building are priorities. See [Contributing](../CONTRIBUTING.md) for how to participate.

docs/protocol-compatibility.md

@@ -1,95 +0,0 @@
-# Protocol Compatibility
-
-The app and the daemon are separate products that ship separately. A user updates the app from an app store or a desktop auto-update; they update the daemon when they feel like it. Every combination happens in the wild: new app against an old daemon, old app against a new daemon, and both sides months apart.
-
-In development both sides are always the same version, which is why this is the constraint contributors miss most often.
-
-Two contracts follow from it.
-
-## The protocol contract: always compatible
-
-A schema change must not break parsing in either direction. An old app still parses messages from a new daemon. A new daemon still parses messages from an old app.
-
-`hello` carries an optional credential. The daemon accepts a client protocol version from its minimum through newer client versions, selects the lower of client and daemon maximum, and reports it as optional `server_info.protocolVersion`. A `hello.rejected` frame precedes an auth close only when the client sent `hello.auth` or advertised `hello_rejection`; older clients receive the existing WebSocket close code and reason. This avoids sending them a new top-level message their validator does not recognize.
-
-- New fields are `.optional()` with a sensible default.
-- Never flip optional to required, remove a field, or narrow a type. `string` to `enum` and nullable to non-null are both narrowing.
-- A field you stop sending stays accepted. You stop writing it, you don't stop reading it.
-- Wire schemas are pure structural declarations. No `.transform()`, `.catch()`, or `.preprocess()` on WebSocket message schemas — normalization happens in an explicit pass after validation. The reason is in [protocol-validation.md](protocol-validation.md): inbound validators are generated, and the generator only compiles pure schemas.
-- Plain `z.union()` is forbidden when every branch shares a literal tag. Use `z.discriminatedUnion()`.
-- `.default()` belongs on primitive leaves only, never on item schemas inside large arrays or big inbound containers.
-
-Two questions to ask before you commit a schema change:
-
-1. Does a six-month-old app still parse this message?
-2. Does a six-month-old daemon still send something this app accepts?
-
-If you can't answer both with yes, the change isn't done.
-
-Schemas live in `packages/protocol/src/messages.ts`. New RPC names follow [rpc-namespacing.md](rpc-namespacing.md).
-
-## The feature contract: per feature, gated once
-
-Features don't have to work across versions. A new feature usually needs a new daemon capability, and old daemons don't have it.
-
-The app checks for the capability and either runs the feature or tells the user to update the host.
-
-- **No fallback paths.** Don't build a degraded version of the feature for old daemons. Don't fan out across legacy RPCs to simulate a capability that isn't there. The user updates or doesn't get the feature.
-- **No defensive branches spread through the feature.** Detection happens in one place, and everything downstream reads a clean shape.
-- Capability flags live in `features` on the `server_info` message (`packages/protocol/src/messages.ts`, the `server_info` schema).
-
-Existing functionality keeps working across versions because of the protocol contract. Gating a new feature never substitutes for that.
-
-## Client capability ownership
-
-The client package advertises the protocol behavior it implements. Add each new capability to
-its exhaustive defaults and implement the associated subscription or decoding behavior there.
-The app, CLI, and plugins inherit those defaults; they supply only host resources such as browser
-automation, or explicit overrides. A schema accepting a message does not establish support for
-its delivery semantics.
-
-On capable daemons, connecting creates no timeline or event demand. Client subscriptions own their network membership,
-release it on unsubscribe, and restore it after reconnect. Raw message observers inspect traffic
-without requesting streams. Application caches and which agents are visible remain caller-owned.
-
-## Owned observations
-
-`owned_subscriptions` and `server_info.features.ownedSubscriptions` negotiate the source-owned
-contract described in [architecture](architecture.md#websocket-protocol). The client selects delivery
-behavior once at its connection boundary. App workflows use the same observation interface on both.
-
-With an older daemon, the client uses the existing connection and legacy RPCs. Directory subscriptions
-remain shared and last-query-wins. Local handle IDs identify listeners; they do not promise independent
-server filters. Timeline and event membership retain their existing shared behavior. Releasing a handle
-detaches its listener and uses the old unsubscribe operation where one exists. Broadcast-only hosts keep
-broadcasting; readiness there means local attachment, not a daemon acknowledgement. No extra sockets
-or multiplexing emulation are introduced.
-
-Preserve established workflows when changing delivery internals. Independent filters and quiet
-connections require a capable daemon; opening the app, reading history and using terminals do not.
-Pre-registry workspace grouping and legacy event normalization belong inside the client boundary.
-
-Old clients keep their existing wire shapes and slot behavior at the daemon's source boundary.
-The adapter keys legacy slots by physical socket, so an old connection cannot replace a modern
-sibling's observation even when both use the same logical client ID. Optional wire IDs stay accepted
-for parsing compatibility; modern requests cannot select their subscription ID.
-
-## Every shim is tagged and dated
-
-A shim that exists for old-app or old-daemon support carries a comment naming it, the version it arrived in, and when it can go:
-
-```ts
-// COMPAT(workspaceFileEditing): added in v0.2.0, remove after 2027-01-18 once daemon floor >= v0.2.0.
-```
-
-`rg "COMPAT\("` is the full cleanup backlog, so:
-
-- One tag per shim, at the site that has to be deleted.
-- Give it a name, a version, and a removal condition or date. Six months out is the usual default.
-- Never bury compatibility in an untagged `??` fallback or an optional-chain tunnel. Untagged back-compat never gets removed, because nobody can find it.
-
-When a tag's condition is met, delete the shim and the tag in the same change.
-
-## QA
-
-Tests don't fully cover compatibility. If you touched `packages/protocol`, say in the pull request why an older app still parses your message and why an older daemon still satisfies your app. See [qa.md](qa.md).

docs/protocol-validation.md

@@ -1,42 +0,0 @@
-# Protocol Validation
-
-The client validates inbound WebSocket messages with a zod-aot generated validator instead of runtime Zod on the hot path. Zod remains the authoring source of truth for schemas and TypeScript types.
-
-The reason is mobile performance. A captured 353 KB provider snapshot cost about 10.9 ms and 5.9 MB allocated per message for `JSON.parse` plus Zod on Hermes. After moving provider-model normalization out of the schema so zod-aot could compile the hot subtree, the generated validator path measured about 2.5 ms and 1.2 MB allocated.
-
-## Runtime Path
-
-`packages/protocol/src/validation/ws-outbound.ts` is the shipped boundary. It calls the generated `WSOutboundMessageSchema.safeParse` and returns the validated data. It does not normalize, repair, or re-validate the generated result.
-
-Generated validators preserve unknown keys where Zod object parsing strips them. The client dispatch path uses known `type` and payload fields, so this passthrough behavior is accepted for inbound messages. The wire format is unchanged.
-
-Provider model normalization is a parser-side compatibility shim in the client consumers that need it. Newer daemons normalize at the provider registry source.
-
-## Codegen Ownership
-
-The protocol package owns generation.
-
-- `packages/protocol/codegen/ws-outbound.compile.ts` is the build-time zod-aot discovery entry.
-- `packages/protocol/scripts/generate-validation-aot.mjs` runs the exact-pinned compiler and applies the small local compiler patches before generation.
-- `packages/protocol/scripts/watch-validation-aot.mjs` reruns generation while editing protocol sources.
-- `packages/protocol/src/generated/validation/ws-outbound.aot.ts` is generated runtime code and is gitignored.
-- `packages/protocol/src/validation/ws-outbound-schema-metadata.ts` is runtime schema metadata for zod-aot fallback/default references.
-
-Generation runs from protocol-owned lifecycle hooks: `prebuild`, `pretypecheck`, `pretest`, and `watch`. Installs do not run generation: published packages consume protocol from prebuilt `dist`, and local build/typecheck/test flows generate the source file at the point it is actually needed.
-
-## Regression Tests
-
-zod-aot is exact-pinned and young enough that compiler patches are treated as part of this package. `packages/protocol/tests/validation/ws-outbound.test.ts` keeps small regression tests for the patched cases:
-
-- discriminated-union branch output must propagate `.default()` fields
-- current sequential item routing must accept `tool_call`-like status branches
-- generated runtime imports must keep `.js` extensions for packaged Node ESM
-- the generated WebSocket envelope accepts a minimal valid message and rejects a corrupted one
-
-## Schema Purity
-
-Message schemas are structural declarations. Do not put `.transform()`, `.catch()`, or `.preprocess()` on WebSocket message schemas. If parsed data needs normalization, put it in an explicit consumer or post-validation pass.
-
-Use `z.discriminatedUnion()` when every branch has a shared literal tag. Plain `z.union()` is acceptable only when there is no shared literal discriminator or when a generated-code regression test proves that specific shape is miscompiled.
-
-Defaults are allowed only on primitive leaves. Do not place `.default()` on large arrays, item schemas, or big containers in inbound message schemas.

docs/providers.md

@@ -1,576 +0,0 @@
-# Adding a New Provider to Paseo
-
-Add new providers through the plugin SDK. The core adapter patterns below describe the existing
-server integrations.
-
-## Plugin providers
-
-Keep a bundled provider in `plugins/<id>/` and register it through
-`@getpaseo/plugin/server/provider`. Antigravity and Muse Code follow this pattern. Built-in loading and SDK
-import rules belong to [plugins.md](plugins.md#built-in-plugins); the
-[public provider guide](../public-docs/plugins/providers.md) covers the provider contract.
-
-The plugin owns the CLI transport, session state, catalog, and capabilities. Launch CLI transports
-and probes through the [SDK process helpers](../public-docs/plugins/providers.md#launch-the-provider-cli),
-which share Windows launcher handling with core providers. The daemon owns
-executable resolution and applies `agents.providers.<provider-id>.command` and `env` before
-connecting. Register the provider's icon with the plugin rather than adding it to the app's
-provider icon map. You do not need a core manifest entry or provider factory.
-
-| Provider    | Transport                                  | Setup and limitations                                            |
-| ----------- | ------------------------------------------ | ---------------------------------------------------------------- |
-| Antigravity | Installed `agy` CLI                        | [Antigravity](../public-docs/supported-providers.md#antigravity) |
-| Muse Code   | MSP over one `muse serve` host per session | [Muse Code](../public-docs/muse-code.md)                         |
-
-## Provider-native session options
-
-The provider owns validation and application of the opaque record in
-`AgentSessionConfig.providerOptions`. The registry supplies the effective options
-at session startup. See [provider configuration](custom-providers.md#provider-options)
-for defaults and merge rules, and the [SDK guide](../public-docs/sdk/provider-options.md)
-for native keys and examples.
-
-Exact MCP preapproval is a separate daemon-owned contract. A new provider must fail
-closed for Hub unattended execution until it can approve one exact injected MCP
-server and tool identity without approving native tools.
-
-## Core adapter patterns
-
-### ACP (Agent Client Protocol) -- recommended
-
-Extend `ACPAgentClient` from `packages/server/src/server/agent/providers/acp-agent.ts`. The base class handles process spawning, stdio transport, session lifecycle, streaming, permissions, and model discovery. You provide configuration (command, modes, capabilities) and optionally override `isAvailable()` for auth checks.
-
-The only built-in ACP provider today is `copilot` (`copilot-acp-agent.ts`). `GenericACPAgentClient` (`generic-acp-agent.ts`) is also ACP-based but is used for user-defined custom providers configured via `extends: "acp"` overrides — see [docs/custom-providers.md](custom-providers.md).
-
-Copilot custom agents are exposed through ACP session config, not the slash-command list. When custom agents are available, Copilot returns a select config option with `id: "agent"` and `category: "_agent"`; Paseo maps that to the `agent` provider feature. Copilot uses the agent display name as the option value, and the blank value means the default Copilot agent.
-
-ACP permission options are rendered as ordered actions and Paseo returns the selected option's exact `optionId`. Agents can therefore encode a single-choice question as multiple options of the same allow kind. Auto-accept does not resolve those chooser requests; they always wait for the user.
-
-ACP shims can own model discovery through `catalogModelResolver`; the shared client owns the probe
-process and refresh deadline. Keep vendor RPCs in the shim. Cursor uses
-`cursor/list_available_models` because switching models during discovery writes its saved CLI
-preferences and selection history. Cursor versions without that extension must be updated. Kimi
-still probes model selections in its own shim. The initial session supplies modes and the current
-model; it does not override the model list returned by a resolver.
-
-### Direct
-
-Implement the `AgentClient` and `AgentSession` interfaces from `agent-sdk-types.ts` yourself. This gives full control but requires you to handle process management, streaming, permissions, and session persistence from scratch.
-
-Core direct providers: `claude` (in `providers/claude/agent.ts`), `codex` (`codex-app-server-agent.ts`), `opencode` (`opencode/runtime-client.ts`), `pi` (`providers/pi/agent.ts`), and `omp` (`providers/omp/agent.ts`). The dev-only `mock` provider (`mock-load-test-agent.ts`) is also direct.
-
-Claude first-party model metadata lives in `packages/server/src/server/agent/providers/claude/model-manifest.ts`. When adding or updating a Claude model, update that manifest only; the model picker thinking options and Claude-specific feature gates are derived from the manifest. Do not add model-specific Claude capability lists in feature code.
-
-Keep the curated Claude catalog: `supportedModels()` has historically omitted older versions and carries less metadata. Discovery is only an opt-in visibility gate, not a replacement catalog or an entitlement guarantee. Claude Code v2.1.197 added `resolvedModel` to disambiguate alias rows; a bare family alias does not establish access to a particular version. Explicit user-configured models must remain selectable when discovery fails or omits them.
-
-Paseo tools are not implemented as MCP tools internally. They live in a shared tool catalog under `packages/server/src/server/agent/tools/`; MCP is only the fallback adapter. The daemon resolves `agents.providers.<provider>.paseoTools` by the exact provider ID. The catalog policy belongs to the caller: it filters the tools exposed to the current agent. When that agent calls `create_agent`, the child receives the policy for the child provider ID; the caller's policy is not inherited.
-
-A provider that can register runtime tools directly should set `supportsNativePaseoTools: true` and consume the already-filtered `launchContext.paseoTools` in `createSession`/`resumeSession`. When native tools are present, `AgentManager` strips the internal Paseo MCP server from the provider launch config so the provider does not receive the same tools twice. Providers that only know MCP should keep `supportsMcpServers: true` and let the daemon inject `/mcp/agents`; the MCP server builds the same policy-filtered catalog for that caller. Filtering is enforced at catalog registration in both paths. Browser tools remain subject to the daemon browser-tools setting and browser-host availability.
-
-Pi is a process-backed provider. Paseo requires the user to have the `pi` binary installed and talks to it through `pi --mode rpc`; the server package does not embed Pi's SDK/runtime packages.
-
-Pi extension adapters live under `packages/server/src/server/agent/providers/pi/extensions/<extension>/`. Each adapter turns Pi RPC facts into Paseo tool, timeline, subagent, or question mappings through the [extension contract](../packages/server/src/server/agent/providers/pi/extensions/contract.ts). To add one, create its directory, add one entry to `extensions/registry.ts`, and test it with fixtures captured from the real extension in Pi that record package, version, source commit, Pi version, and capture date. `agent.ts`, `history-mapper.ts`, and `tool-call-mapper.ts` never name an extension.
-
-Paseo's per-agent and daemon-wide system prompts are appended by its generated Pi integration extension. Paseo deliberately does not pass `--append-system-prompt`, because that flag replaces Pi's automatic `APPEND_SYSTEM.md` discovery instead of composing with it.
-
-Pi model records expose input capabilities through `model.input`. Only send raw RPC `images` when the current model explicitly includes `"image"` in that list. Text-only Pi/OMP models reject image content and persist the rejected image in JSONL history, so image prompts for those models must be materialized to a local file and passed as a text path hint instead.
-
-Probe Pi MCP support with Pi RPC `get_commands` for the agent cwd. Pi 0.99 and later ship MCP as a built-in extension, which registers an extension command named `mcp` with `sourceInfo.path` `builtin:mcp`. Register injected servers through `pi.registerMcpServer` in Paseo's generated extension; the built-in extension rejects SSE servers and names with characters other than letters, digits, `_`, and `-`, and a server of the same name in Pi's `mcp.json` takes precedence.
-
-The open-source `pi-mcp-adapter` extension replaces the built-in one and registers its own `mcp` command (often with `sourceInfo.source` containing `pi-mcp-adapter`). When it is loaded, write a per-agent MCP config and pass it with `--mcp-config` instead of modifying user or project MCP files. Because that flag replaces the Pi global config layer, preserve the existing `<Pi agent dir>/mcp.json` in the generated file before overlaying injected servers. For local HTTP servers such as Paseo's own `/mcp/agents` endpoint, explicitly disable adapter OAuth (`auth: false`, `oauth: false`) in the generated config.
-
-Pi control-plane RPCs wait 60 seconds by default. Override `params.rpcTimeoutMs` when extension or MCP startup on a slow host needs more time. Timeout errors name the pending RPC phase and report both elapsed time and the configured deadline. This setting does not govern long-running Pi compaction or Pi extension UI results. See [OMP profiles and Pi-compatible forks](custom-providers.md#omp-profiles-and-pi-compatible-forks) for OMP startup and RPC deadlines.
-
-Pi import discovery reads Pi's persisted JSONL session files because Pi RPC does not expose a recent-session listing command. Resume and full history hydration still go through `pi --mode rpc` using the session file as `nativeHandle`.
-
-OMP is a first-class built-in provider, disabled by default. Its launch contract, typed runtime, agent/session behavior, history, permissions, imports, and test fake live under `providers/omp/`; only the provider-neutral JSONL child-process transport is shared with Pi. It launches `omp --mode rpc-ui`, uses OMP's `get_available_commands` RPC for slash-command discovery, bridges OMP `rpc-ui` approval dialogs into Paseo permissions, and imports terminal-started sessions from `~/.omp/agent/sessions` when enabled.
-
-OMP supports native Paseo host tools. The adapter registers the full caller-scoped Paseo tool catalog directly with OMP, matching providers such as Claude that expose the full catalog through MCP. Serialize every OMP host definition with `loadMode: "essential"` so `create_agent`, `send_agent_prompt`, `wait_for_agent`, and related tools remain direct calls; omitting the field makes OMP mount non-built-in names under `xd://` instead. OMP's provider-managed task subagents are surfaced as Paseo subagents through `child_session` imports; the parent keeps the subagents track while the child runtime stays owned by OMP. Custom OMP profiles should extend `omp`; other Pi-compatible forks can still extend `pi`, override `command`, and set `params.sessionDir` to their JSONL session directory.
-
-Pi RPC extension UI dialog requests (`select`, `input`, `editor`, `confirm`) are bridged into Paseo question permissions and answered with `extension_ui_response`. Pi extensions such as `ask_user` may chain dialogs: for example, a `select` can be followed by an optional-comment `input`. When an `ask_user` tool call declares `allowComment: true`, Paseo presents the selection and optional comment as one question permission, answers Pi's initial `select` immediately, then auto-answers the follow-up optional `input` with the comment the user already supplied (or an empty string). Preserve placeholders and optional/skip semantics for standalone optional inputs so the app can still distinguish "skip this optional input" from "cancel the whole dialog." Fire-and-forget extension UI requests such as notifications are intentionally ignored by the provider adapter unless Paseo grows first-class UI for them.
-
-OpenCode adapters target v1.14.46 and v2.0.10. V2 rejects binaries older than the tested 2.0.10 SDK at runtime selection. Runtime selection uses the configured command and environment. A recognized version is cached until provider configuration reload; a failed, timed-out, or unrecognized probe retains the v1 path and retries detection on the next operation. Load v2 code and materialize its plugin only after positive v2 selection; v1 sessions remain undecorated. Keep upstream SDK types inside the version-specific adapter. OpenCode owns storage migration; a missing native session must fail resume rather than create a replacement. V2 has no native archive/unarchive operation: archiving affects Paseo only. V1 retains native archiving.
-
-Use OpenCode v2 execution events to trigger turn completion, with active-state and durable-log reconciliation after admission, reconnect, and while a turn remains active. Do not use `session.wait`: a healthy turn exceeding Node's HTTP headers deadline produces a transport error while OpenCode keeps working. The live event feed has no replay, and shutdown interruption preserves the previous idle outcome, so the session snapshot alone cannot recover missed execution events. Quiet streams are healthy: v2 heartbeats are SSE comments, not application events.
-
-V2.0.4 also removed the activation endpoint that gated a cold location, and a cold location registers its config-derived commands, skills, and providers asynchronously. Wait until `plugin.list` returns a populated inventory before reading the catalog or commands; an empty inventory means the location is still warming. Fail when the readiness deadline expires, including when an inventory request stalls.
-
-Paseo installs its OpenCode tool bridge through `OPENCODE_CONFIG_CONTENT`. V1 accepts a plugin file; v2 silently skips configured files and requires a package directory with a server entry point. Both versions use the daemon's private loopback bridge for caller-scoped tools. Bridge context lives only in daemon memory and is removed when the Paseo session closes. The content-addressed plugin artifacts contain no session data or secrets. V2 also needs this plugin when native Paseo tools are disabled: its prompt API has no structured-output format, so the plugin supplies a schema-validated final-answer tool.
-
-An agent with custom environment variables or user-configured MCP servers gets a dedicated OpenCode server. V2 supports session environment, but its MCP configuration remains location-scoped, so separate servers still prevent one agent from changing another agent's MCP setup. Configure custom MCP with `mcp.add`; do not follow it with `mcp.connect`, which only toggles config-backed servers.
-
-OpenCode owns user message IDs. Do not pass Paseo-generated IDs to OpenCode prompt APIs; let OpenCode create `msg*` IDs and record the user timeline item from the `message.updated` event.
-
-`AgentManager` owns the one canonical timeline row for a foreground prompt carrying a Paseo `clientMessageId`. It records that row when `startTurn` accepts, with the wire `messageId` set to the same value. Provider adapters still emit their native user-message echo with the same `clientMessageId` when available; the manager records its provider identity on the internal row without changing or redispatching the wire item. If an adapter emits the echo before `startTurn` resolves, the manager records the provider identity with the row at acceptance. Provider adapters continue to own externally initiated user rows that have no Paseo client identity. Do not perform global transcript text dedupe.
-
-Active-turn steering is an optional `AgentSession.steerActiveTurn` operation. The manager owns admission against its exact foreground turn, canonical user-message creation, echo reconciliation, and falls back to the normal interrupt-and-replace path only when the adapter reports `unavailable`. An adapter error leaves the steer's fate ambiguous and must surface without an interrupt or retry. Codex calls `turn/steer` with the native expected turn and Paseo client user-message ID. Claude pushes an admitted steer into the exact active SDK query input; isolated control commands remain unavailable. OpenCode calls `session/prompt_async` with an OpenCode-generated message ID; the server queues the prompt while busy and the next LLM call in the same Paseo turn includes it. Pi sends its native `steer` RPC, which queues the message for delivery after the in-flight assistant turn's tool calls. Slash-command inputs report `unavailable` because pi rejects extension commands on the steer path, and echo identity is correlated by message text because pi's steer RPC takes no message ID. A missing session reports `unavailable` and uses the normal interrupt fallback.
-
-A steering adapter also owes its interrupt: stopping a turn must discard the steers the provider has not read yet, or one of them resumes the turn the user just stopped. Codex clears pending input when it aborts a turn; Claude does not, so its adapter cancels the SDK messages it queued before calling `query.interrupt()`. It calls `query.interrupt()` only while a main-session turn is in flight (between `system/init` and that turn's `result`): with the main session idle, an interrupt reaches only background subagents and no result follows it, so the adapter withdraws its unstarted messages and stops there. The adapter also declares `perTaskStopAffordance`, because without it the CLI kills every background subagent on interrupt. Pi requires `clear_queue` before `abort`; older binaries without that RPC retain their native queue behavior until the pi compatibility floor reaches 0.84.4.
-
-`SteerActiveTurnOptions.clearPendingPermissions` makes permission release part of the provider contract. A provider that accepts such a steer queues it first, denies permissions blocking its delivery, and stops once the steer is read. Steers without the flag leave permissions open. A denied plan remains in the timeline because the pending card was the only other copy of its text.
-
-Rewind accepts the canonical wire `messageId` and resolves it to the provider identity before calling the adapter. A submitted prompt cannot be rewound until its provider echo supplies that identity.
-
-Submitted user-message wire items carry the same Paseo ID in `messageId` and `clientMessageId`. Provider adapters attach `clientMessageId` only to the echo for that foreground submission; provider history and externally initiated user rows do not have a Paseo client ID.
-
-Provider adapters must terminalize every transient timeline row before emitting the turn's terminal event. Codex may omit the completed `contextCompaction` item when a turn ends during compaction, so its adapter closes any pending root compaction before forwarding `turn_completed`, `turn_failed`, or `turn_canceled`. A terminal turn must never leave the client showing an operation as still loading.
-
-Draft metadata lookups should avoid creating provider sessions when the upstream provider has top-level APIs for that metadata. Prefer `AgentClient.fetchCatalog`, `listCommands`, or `listFeatures` over creating a scratch `AgentSession`; scratch sessions can show up as empty native sessions in provider import/history UIs. `fetchCatalog` is the single discovery API for models and modes — provider implementations may use one process, separate upstream calls, or static data internally, but callers outside the provider do not get separate runtime model/mode probes. Draft command listing and scratch-session feature listing require an explicit draft model. Do not resolve a default model through catalog discovery. A client-level `listFeatures` implementation may return features from an incomplete, model-less draft and owns which features are valid in that state.
-
-Provider session import has its own contract. The picker calls `listImportableSessions` and receives rows only: provider handle, cwd, title, prompt previews, and last activity. Import calls `importSession({ providerHandleId, cwd })` for the selected row and must not call listing again. The provider returns the resumed session, storage config, persistence handle, and hydrated timeline for that one native session; `AgentManager.importProviderSession` seeds the daemon timeline and publishes the Paseo agent only after it is ready.
-
-## Provider Helper Processes
-
-Provider-owned helper processes that can outlive an individual agent session must be recorded in the daemon's managed-process registry. Store provider/kind metadata, the PID, launch command/args, and process identity captured from the platform process table. Remove the record on normal exit or shutdown.
-
-If a helper process has a readiness phase, the provider's lifecycle model must own the process immediately after `spawn`, before readiness succeeds. Startup timeout, startup exit, and daemon shutdown must all clean up through that owned generation. Do not keep a spawned helper only inside a readiness promise; that creates a live process outside the manager/reaper contract.
-
-Daemon bootstrap reconciles that ledger in the background, without blocking startup: dead PIDs are deleted, PID identity mismatches are deleted without killing anything, only positively matched Paseo-owned leftovers are terminated, and a record whose process cannot be inspected is left in place for the next reconcile rather than deleted. Do not add broad process-name sweepers for provider cleanup; cleanup starts from records Paseo previously wrote.
-
----
-
-## Provider Snapshot Refresh Contract
-
-Provider snapshots are views of the catalogues needed for a target. Before looking up cached
-results or discovery in flight, the manager calls optional `AgentClient.getCatalogCacheKey(options)`.
-The provider owns equivalence: equal keys must mean the same availability, models and modes,
-including the effective configuration and execution environment. `force` does not change identity.
-Omitting the method or returning `undefined` keeps target-specific caching. Codex and Claude's
-current host clients share across directories; configured provider identities remain isolated.
-
-The key chooses storage, never execution. Availability and catalogue discovery receive the actual
-`{ scope: "global", force }` or `{ scope: "workspace", cwd, force }` request, including when another
-target can share its result. Runtime-aware adapters must use that target for both probing and key
-resolution. An explicit home-directory workspace is distinct from a semantic global request.
-Plugin callbacks follow the same contract; see [plugin providers](plugins.md#contribute-a-provider).
-
-`ProviderSnapshotManager` owns one refresh deadline per provider. The deadline starts before the
-availability check and covers that check plus the complete catalog probe. Providers that make
-multiple catalog requests must not apply this deadline separately to each request. The manager
-aborts the shared refresh signal at the deadline. Providers name active catalog operations and
-finish subprocess, server, or session cleanup before rejecting. Timeout errors list the operations
-that were still active when the deadline expired.
-
-Catalogue results stay cached by identity until explicit refresh or a change to that provider's configuration.
-Keys are resolved on each read so project configuration can select a different cached catalogue.
-Selector opening may read a loading or stale query, but does not force provider probing.
-
-Saved provider/model choices are user intent. Catalogue failure must not erase them or substitute
-another model. Creation reads the caller's host and directory directly; an earlier global snapshot
-must not settle a project form's initial selection.
-
-The server's provider keys never cross the wire. Clients advertising `provider_snapshot_references`
-receive directory-to-hash announcements; an unknown hash uses the existing snapshot request.
-The manager detaches each fresh result once and publishes its content identity with the entry;
-readers share these values read-only. Each target keeps its published snapshot until membership,
-content or discovery freshness changes. All affected targets commit before subscribers run;
-subscriber failures are logged without changing discovery or configuration outcomes.
-The session compares both sides of a committed transition under the client's current visibility
-policy and sends only visible changes. It combines result identities with the client's encoding
-and icon policy, without traversing models. Reference hashes exclude freshness;
-legacy embedded hashes include it. Only responses that send a body compact the catalogue.
-Per-provider `fetchedAt` travels separately for reference clients and still means when discovery succeeded. `generatedAt`
-remains the time the response or announcement was generated. Refresh keeps settled entries visible
-until the next result, so unchanged discovery sends freshness without another model body.
-
-The app's snapshot cache owns compact expansion and stores one body per server/hash, with separate
-directory/hash/freshness records under the same byte budget. Missing bodies share a React Query
-request; directory queries cancel superseded pulls before accepting pushes. Default SDK clients
-keep expanded entries and full updates. Only callers that own materialization opt into wire snapshots.
-Keep the full encoding for older clients; compact-snapshot support alone does not imply reference support.
-
-Settings refresh invalidates requested providers across known targets and refreshes them in their
-actual execution context, so every connected client receives the refreshed view. Discovery shares
-work by provider key and admits at most four concurrent catalogue probes per configured provider, so a stalled provider does not block discovery for others. Configuration replacement invalidates
-only changed providers; unchanged entries, clients, and discovery in flight survive. Preparation
-leaves installed reads untouched until commit. Plugin replacement uses registration runtime
-identity, so unchanged registrations and builtins keep their results. Await the refresh or warmup
-promise for completion: equal results, including equal discovery timestamps, emit no transition.
-
----
-
-## Usage sources
-
-See the [public usage source reference](../public-docs/plugins/reference.md#usage-sources) for the
-contract, account and window identity, provider-derived period names, login fallback, and
-read-only credential rules. Usage adapters own the interpretation of provider fields; the app
-renders their names and resolves pins without provider-specific duration guesses.
-
----
-
-## ACP Provider Checklist
-
-### 1. Create the provider class
-
-Create `packages/server/src/server/agent/providers/{name}-agent.ts`.
-
-Define capabilities, modes, and a thin subclass of `ACPAgentClient`:
-
-```ts
-import type { Logger } from "pino";
-import type { AgentCapabilityFlags, AgentMode } from "../agent-sdk-types.js";
-import type { ProviderRuntimeSettings } from "../provider-launch-config.js";
-import { ACPAgentClient } from "./acp-agent.js";
-
-const MY_PROVIDER_CAPABILITIES: AgentCapabilityFlags = {
-  supportsStreaming: true,
-  supportsSessionPersistence: true,
-  supportsDynamicModes: true,
-  supportsMcpServers: true,
-  supportsReasoningStream: true,
-  supportsToolInvocations: true,
-};
-
-const MY_PROVIDER_MODES: AgentMode[] = [
-  {
-    id: "default",
-    label: "Default",
-    description: "Standard agent mode",
-  },
-  // Add more modes as needed
-];
-
-type MyProviderClientOptions = {
-  logger: Logger;
-  runtimeSettings?: ProviderRuntimeSettings;
-};
-
-export class MyProviderACPAgentClient extends ACPAgentClient {
-  constructor(options: MyProviderClientOptions) {
-    super({
-      provider: "my-provider", // Must match the ID used everywhere else
-      logger: options.logger,
-      runtimeSettings: options.runtimeSettings,
-      defaultCommand: ["my-agent-binary", "--acp"], // CLI command to spawn
-      defaultModes: MY_PROVIDER_MODES,
-      capabilities: MY_PROVIDER_CAPABILITIES,
-    });
-  }
-
-  // Override isAvailable() if the provider needs specific auth/env vars
-  override async isAvailable(): Promise<boolean> {
-    if (!(await super.isAvailable())) {
-      return false; // Binary not found
-    }
-    return Boolean(process.env["MY_PROVIDER_API_KEY"]);
-  }
-}
-```
-
-The `super.isAvailable()` call checks that the binary from `defaultCommand` is on `$PATH`. Override only to add credential checks on top.
-
-For reference, here is how Copilot does it -- no auth override needed because the CLI handles auth itself:
-
-```ts
-export class CopilotACPAgentClient extends ACPAgentClient {
-  constructor(options: CopilotACPAgentClientOptions) {
-    super({
-      provider: "copilot",
-      logger: options.logger,
-      runtimeSettings: options.runtimeSettings,
-      defaultCommand: ["copilot", "--acp"],
-      defaultModes: COPILOT_MODES,
-      capabilities: COPILOT_CAPABILITIES,
-    });
-  }
-
-  override async isAvailable(): Promise<boolean> {
-    return super.isAvailable();
-  }
-}
-```
-
-### 2. Add to the provider manifest
-
-In `packages/protocol/src/provider-manifest.ts`, add mode definitions with UI metadata (icons, color tiers) and a provider definition entry.
-
-First, define the modes with visual metadata:
-
-```ts
-const MY_PROVIDER_MODES: AgentProviderModeDefinition[] = [
-  {
-    id: "default",
-    label: "Default",
-    description: "Standard agent mode",
-    icon: "ShieldCheck",
-    colorTier: "safe",
-  },
-  {
-    id: "autonomous",
-    label: "Autonomous",
-    description: "Runs without prompting",
-    icon: "ShieldOff",
-    colorTier: "dangerous",
-  },
-];
-```
-
-Available `colorTier` values: `"safe"`, `"moderate"`, `"dangerous"`, `"planning"`.
-Available `icon` values: `"ShieldCheck"`, `"ShieldAlert"`, `"ShieldOff"`.
-
-Then add to the `AGENT_PROVIDER_DEFINITIONS` array:
-
-```ts
-export const AGENT_PROVIDER_DEFINITIONS: AgentProviderDefinition[] = [
-  // ... existing providers ...
-  {
-    id: "my-provider",
-    label: "My Provider",
-    description: "Short description of the provider",
-    defaultModeId: "default",
-    modes: MY_PROVIDER_MODES,
-    // Optional: enable voice
-    voice: {
-      enabled: true,
-      defaultModeId: "default",
-      defaultModel: "some-model",
-    },
-  },
-];
-```
-
-### 3. Add the factory to the provider registry
-
-In `packages/server/src/server/agent/provider-registry.ts`, import your class and add a factory entry to `PROVIDER_CLIENT_FACTORIES`:
-
-```ts
-import { MyProviderACPAgentClient } from "./providers/my-provider-agent.js";
-
-const PROVIDER_CLIENT_FACTORIES: Record<string, ProviderClientFactory> = {
-  // ... existing factories ...
-  "my-provider": (logger, runtimeSettings) =>
-    new MyProviderACPAgentClient({
-      logger,
-      runtimeSettings,
-    }),
-};
-```
-
-The factory is invoked with `(logger, runtimeSettings, options)`; `options.workspaceGitService` is also available if you need it (see the `codex` factory for an example). The registry already passes the per-provider runtime settings slice through, so you don't index into the map yourself.
-
-### 4. Add a provider icon (app)
-
-Create `packages/app/src/components/icons/my-provider-icon.tsx` following the pattern from existing icons (e.g., `claude-icon.tsx`):
-
-```tsx
-import Svg, { Path } from "react-native-svg";
-
-interface MyProviderIconProps {
-  size?: number;
-  color?: string;
-}
-
-export function MyProviderIcon({ size = 16, color = "currentColor" }: MyProviderIconProps) {
-  return (
-    <Svg width={size} height={size} viewBox="0 0 24 24" fill={color}>
-      <Path d="..." />
-    </Svg>
-  );
-}
-```
-
-Then register it in `packages/app/src/components/provider-icons.ts` by adding an entry to the existing `PROVIDER_ICONS` map (which already covers the built-in providers):
-
-```ts
-import { MyProviderIcon } from "@/components/icons/my-provider-icon";
-
-const PROVIDER_ICONS: Record<string, typeof Bot> = {
-  // ... existing entries ...
-  "my-provider": MyProviderIcon as unknown as typeof Bot,
-};
-```
-
-If no icon is registered, `getProviderIcon()` falls back to a generic `Bot` icon from lucide.
-
-### 5. Add E2E test config
-
-In `packages/server/src/server/daemon-e2e/agent-configs.ts`, add your provider:
-
-```ts
-export const agentConfigs = {
-  // ... existing configs ...
-  "my-provider": {
-    provider: "my-provider",
-    model: "default-model-id",
-    modes: {
-      full: "autonomous", // Mode with no permission prompts
-      ask: "default", // Mode that requires permission approval
-    },
-  },
-} as const satisfies Record<string, AgentTestConfig>;
-```
-
-Add an availability check in `isProviderAvailable()`. Note `isCommandAvailable` is async, so all branches `await` it:
-
-```ts
-case "my-provider":
-  return (
-    (await isCommandAvailable("my-agent-binary")) &&
-    Boolean(process.env.MY_PROVIDER_API_KEY)
-  );
-```
-
-Add to the `allProviders` array (current built-ins are `claude`, `codex`, `copilot`, `opencode`, `pi`, `omp`):
-
-```ts
-export const allProviders: AgentProvider[] = [
-  "claude",
-  "codex",
-  "copilot",
-  "opencode",
-  "pi",
-  "my-provider",
-];
-```
-
-### 6. Run typecheck
-
-```bash
-npm run typecheck
-```
-
-This is required after every change per project rules.
-
----
-
-## Direct Provider Checklist
-
-If your agent does not speak ACP, implement the interfaces from `agent-sdk-types.ts` directly.
-
-### Interfaces to implement
-
-The interfaces below are abridged signatures — read `agent-sdk-types.ts` for the full source of truth (option bag types, generics, etc.).
-
-**`AgentClient`** -- factory for sessions and model/mode listing:
-
-```ts
-interface AgentClient {
-  readonly provider: AgentProvider;
-  readonly capabilities: AgentCapabilityFlags;
-  createSession(
-    config: AgentSessionConfig,
-    launchContext?: AgentLaunchContext,
-    options?: AgentCreateSessionOptions,
-  ): Promise<AgentSession>;
-  resumeSession(
-    handle: AgentPersistenceHandle,
-    overrides?: Partial<AgentSessionConfig>,
-    launchContext?: AgentLaunchContext,
-  ): Promise<AgentSession>;
-  fetchCatalog(options: FetchCatalogOptions): Promise<ProviderCatalog>;
-  isAvailable(): Promise<boolean>;
-  // Optional:
-  listImportableSessions(
-    options?: ListImportableSessionsOptions,
-  ): Promise<ImportableProviderSession[]>;
-  importSession(
-    input: ImportProviderSessionInput,
-    context: ImportProviderSessionContext,
-  ): Promise<ImportedProviderSession>;
-  getDiagnostic?(): Promise<{ diagnostic: string }>;
-}
-```
-
-**`AgentSession`** -- a running agent conversation:
-
-```ts
-interface AgentSession {
-  readonly provider: AgentProvider;
-  readonly id: string | null;
-  readonly capabilities: AgentCapabilityFlags;
-  readonly features?: AgentFeature[];
-  run(prompt: AgentPromptInput, options?: AgentRunOptions): Promise<AgentRunResult>;
-  startTurn(prompt: AgentPromptInput, options?: AgentRunOptions): Promise<{ turnId: string }>;
-  steerActiveTurn?(prompt: AgentPromptInput, options: SteerActiveTurnOptions): Promise<SteerResult>;
-  subscribe(callback: (event: AgentStreamEvent) => void): () => void;
-  streamHistory(): AsyncGenerator<AgentStreamEvent>;
-  getRuntimeInfo(): Promise<AgentRuntimeInfo>;
-  getAvailableModes(): Promise<AgentMode[]>;
-  getCurrentMode(): Promise<string | null>;
-  setMode(modeId: string): Promise<void | AgentProviderNotice>;
-  getPendingPermissions(): AgentPermissionRequest[];
-  respondToPermission(
-    requestId: string,
-    response: AgentPermissionResponse,
-  ): Promise<AgentPermissionResult | void>;
-  describePersistence(): AgentPersistenceHandle | null;
-  interrupt(): Promise<void>;
-  close(): Promise<void>;
-  // Optional:
-  listCommands?(): Promise<AgentSlashCommand[]>;
-  setModel?(modelId: string | null): Promise<void>;
-  setThinkingOption?(thinkingOptionId: string | null): Promise<void | AgentProviderNotice>;
-  setFeature?(featureId: string, value: unknown): Promise<void>;
-  tryHandleOutOfBand?(prompt: AgentPromptInput): {
-    run(ctx: { emit: (event: AgentStreamEvent) => void }): Promise<void>;
-  } | null;
-}
-```
-
-`setMode` and `setThinkingOption` may return an `AgentProviderNotice` when the provider knows the change needs user-facing context. For example, providers that stage changes until the next turn should return an `info` notice while a turn is already running. The app renders the notice generically as a toast; provider-specific lifecycle behavior stays in the provider implementation.
-
-### Steps
-
-1. Create `packages/server/src/server/agent/providers/{name}-agent.ts` implementing both interfaces
-2. Add to the provider manifest (same as ACP step 2 above)
-3. Add factory to the registry (same as ACP step 3 above)
-4. Add icon (same as ACP step 4 above)
-5. Add E2E config (same as ACP step 5 above)
-6. Run typecheck
-
----
-
-## Testing
-
-### Manual testing with the CLI
-
-Start the daemon if not already running, then:
-
-```bash
-# Launch an agent with your provider
-paseo run --provider my-provider
-
-# Launch with a specific model and mode
-paseo run --provider my-provider --model some-model --mode default
-
-# List running agents
-paseo ls -a -g
-
-# Check if the provider reports models
-paseo models --provider my-provider
-```
-
-### E2E test patterns
-
-The E2E configs in `agent-configs.ts` expose two helpers:
-
-- `getFullAccessConfig(provider)` -- returns config for a session with no permission prompts
-- `getAskModeConfig(provider)` -- returns config for a session that triggers permission requests
-
-Tests use `isProviderAvailable(provider)` to skip when the binary or credentials are missing, so CI will not fail for providers that are not installed.
-
----
-
-## Gotchas
-
-**Mode IDs can be URIs.** ACP providers like Copilot use full URIs as mode IDs (e.g., `"https://agentclientprotocol.com/protocol/session-modes#agent"`). Never assume mode IDs are simple strings. The manifest `defaultModeId` must match exactly.
-
-**Models and modes are discovered dynamically.** ACP providers report available models and modes at runtime via the protocol. The static definitions in `provider-manifest.ts` are used for UI scaffolding (icons, color tiers) but the runtime values from the agent process are the source of truth.
-
-**`AgentProvider` is always `string`.** The type alias is `type AgentProvider = string`. Provider IDs are validated against the manifest at runtime, not at the type level.
-
-**Auth patterns vary.** Some providers need API keys in env vars (`ANTHROPIC_API_KEY`, `OPENAI_API_KEY`), some use OAuth tokens (`CLAUDE_CODE_OAUTH_TOKEN`), some use auth files (`~/.codex/auth.json`), and some handle auth entirely in their CLI binary (Copilot). Your `isAvailable()` method should check whatever is needed.
-
-**The manifest mode list and the agent class mode list are separate.** The manifest in `provider-manifest.ts` includes UI metadata (`icon`, `colorTier`). The agent class defines modes without UI metadata (just `id`, `label`, `description`). Keep them in sync.
-
-**`defaultCommand` is a tuple.** The first element is the binary name, the rest are default arguments. The base class uses this to find the executable and spawn the process.
-
-**Runtime settings can override the command.** Users can configure custom binary paths or environment variables per provider via `ProviderRuntimeSettings`. Your factory in the registry should pass `runtimeSettings?.["your-provider"]` through to the constructor.
-
-**Session-scoped cancellation needs a stop boundary inside the provider.** Some agents cancel the whole session rather than one turn — OpenCode's `session.abort` is the example. A cancel that is still in flight when the next run starts will kill that replacement run, which is what makes "stop, then immediately prompt again" (`replaceRunning`, `notifyOnFinish` wakes, schedules) flaky. Own this in the provider session, not in `AgentManager`:
-
-- Model the stop as an explicit `stopping` turn-state variant carrying the canceled run's terminal and the cancellation the caller is still owed. Pressing Stop again retries the stop already in progress rather than opening a second one; never fire a detached retry, it will outlive its boundary.
-- **Scope the cancel settlement the way the provider scopes the cancel.** If cancellation is session-scoped, so is its settlement: track it on the session, accumulating every request issued, and let it outlive the stop that issued it. A request still in flight lands on the runner whenever the server gets to it — however many stops have come and gone since. Scoping it to the current stop looks right and quietly drops older requests from the gate. Only the newest may hold the gate closed, since recovering from a failed cancel is what pressing Stop again is for.
-- Gate the operations **the daemon issues** (prompt, slash command, summarize) on both the terminal and cancel settlement. Permission and question responses are not runner operations and must stay outside the gate, or an auto-approve deadlocks the stop. Runs the _provider_ starts on its own — plugin or autonomous wakes — are observed, not gated: the daemon does not choose when they begin, and holding their events back does not protect them from a cancel already in flight, it only hides a run that may already be dead.
-- Fail closed: if the cancel never succeeded you never proved the run stopped, so refuse new runs until the next Stop issues a fresh cancel. `AgentManager` already turns a rejected `interrupt()` into a refused cancel.
-- Suppress the canceled run's residue only until its authoritative terminal. Anything the provider publishes after that terminal is a new run by construction and must take the normal live path — buffering it and replaying it later is how autonomous/plugin wakes get lost.

docs/qa.md

@@ -1,80 +0,0 @@
-# QA
-
-QA is the main bottleneck of Paseo's product development.
-
-The bar is four questions:
-
-1. Does it work well?
-2. Does it regress anything else?
-3. Was it tested on every platform it affects?
-4. Is there automated coverage, and is that coverage real?
-
-Every pull request needs evidence for the questions its change touches. Pull requests without evidence get closed.
-
-For plugin changes, verify the [SDK import boundaries](plugins.md#sdk-import-boundaries) before
-exercising contributions. Include the boundary tests and both runtime loaders in the evidence.
-
-## Evidence
-
-Evidence is something someone else can look at:
-
-- The commands you ran, pasted with their output
-- The tests you added and their results
-- Before and after screenshots
-- A video of the interaction
-- Logs, requests, responses
-
-Redact what you need to, keep the technical details. If an agent did the work, submit its raw output. A summary drops the details someone else needs to check it.
-
-## Does it work well
-
-A feature that works but stutters, shifts the layout, or misaligns by two pixels is not done.
-
-For UI, that means matching the design system in visuals, in interaction, and in performance. [design.md](design.md) is the reference.
-
-The two things that go wrong most often:
-
-- **Layout shift.** Content that jumps as data arrives, a row that resizes when a badge appears, a panel that reflows on first render. Watch the change on a slow connection and on first load, not just after everything is warm.
-- **Alignment.** Things align to their glyphs, not to their touch targets. See the alignment rules in [design.md](design.md).
-
-## Does it regress anything else
-
-Paseo is composable by design, which means your change sits next to features you didn't touch. Open the surfaces around it. A change to the agent list affects archive, subagents, and tabs; a change to git actions affects worktrees and the checkout flow.
-
-Performance is part of this. The app is Expo React Native, not a web app in a native shell. You are not writing CSS, styles resolve differently, and performance characteristics differ per platform. What feels instant in a desktop dev build can be visibly slow on a phone.
-
-If your change touches a hot path such as the terminal, the message list, or git polling, submit before and after numbers. [terminal-performance.md](terminal-performance.md) has the terminal pipeline and its benchmarks, and [development.md](development.md) covers renderer and React profiling.
-
-## Every platform it affects
-
-Your code does not only run on the platform you tested it on. The same app ships to iOS, Android, browser web, and Electron on macOS, Windows, and Linux, and the daemon runs on all three desktop operating systems plus Docker.
-
-You aren't expected to own every device. You are expected to say what you covered:
-
-| Platform        | Tested | Notes |
-| --------------- | ------ | ----- |
-| iOS             |        |       |
-| Android         |        |       |
-| Web             |        |       |
-| Desktop macOS   |        |       |
-| Desktop Windows |        |       |
-| Desktop Linux   |        |       |
-
-Install what you reasonably can. An iOS simulator and an Android emulator cover most of the gap on a single machine, see [development.md](development.md) and [android.md](android.md).
-
-For the rules about which code runs where, read the platform gating section in [CLAUDE.md](../CLAUDE.md). The recurring traps have their own docs: [hover.md](hover.md), [unistyles.md](unistyles.md), [floating-panels.md](floating-panels.md), [mobile-panels.md](mobile-panels.md), [expo-router.md](expo-router.md).
-
-App and daemon versions also drift, in both directions. That has its own contract: [protocol-compatibility.md](protocol-compatibility.md).
-
-## Automated coverage that means something
-
-Tests are evidence only when they exercise the real thing.
-
-- A bug fix needs a regression test that fails on the old code for the reported reason.
-- A feature needs tests that go through the same interface a user or a caller uses.
-- Web flows need an actual Playwright run, not a mocked-out approximation of one.
-- Agent provider work needs manual verification against the real provider by someone who can tell that it worked. A fixture and a mock prove the fixture parses, nothing more.
-
-Tests that mock away the behavior, assert on internals, or pass against the broken code claim coverage that isn't there.
-
-[testing.md](testing.md) is the standard, including how to run suites without freezing your machine. For driving a real daemon in a test, see [ad-hoc-daemon-testing.md](ad-hoc-daemon-testing.md). For mobile flows, [mobile-testing.md](mobile-testing.md). For Electron screenshots, [browser-capture-harness.md](browser-capture-harness.md).

docs/refactors/session-decomposition-plan.md

@@ -1,129 +0,0 @@
-# Session God-File Decomposition Plan
-
-`packages/server/src/server/session.ts` — 9116 lines, one `Session` class (declared line 724), 128 handlers, ~60 instance fields, 7 entangled domains. Goal: a **strictly behavior-preserving, incremental** decomposition into per-domain controllers, mirroring the existing `TerminalSessionController`.
-
-## Chosen strategy: controller-context (per-domain option-bag controllers)
-
-Each domain becomes a controller class in its own file with the **exact** contract the repo already proved twice (`TerminalSessionController` at `packages/server/src/terminal/terminal-session-controller.ts`, and `CreateAgentLifecycleDispatch`):
-
-- An **options-bag constructor** injecting only what that domain reads.
-- An **owned-type `ReadonlySet`** of message types.
-- A **NON-async `dispatch(msg): Promise<void> | undefined`** that checks the owned-type set FIRST and returns `undefined` synchronously on a miss (verified at terminal-session-controller.ts:140-143).
-- `start()` wired from `subscribeToOptionalManagers`, `dispose()` called by the shell's ordered `cleanup()`.
-
-Session shrinks to a connection/dispatch shell: it keeps `handleMessage`, the `??` chain (1739-1751), `emit`/`emitBinary`, `sessionLogger`, connection identity, inflight metrics, lifecycle intents, and the **ordered** `cleanup()`. Each `dispatchXMessage` collapses to `return this.xController.dispatch(msg)`.
-
-## Progress (shipped — diverged from the original filenames)
-
-The first carves shipped as **deep modules with a narrow Host seam**, not the `dispatch(msg)`-owned-set controllers sketched below: `session.ts` keeps each `dispatchXMessage` switch and delegates per case to the subsystem. Home convention that emerged: session subsystems live at **`session/<domain>/`**, with `session.ts` as the orchestrator shell.
-
-- **#1640 — VoiceSession** (`session/voice/voice-session.ts`, seam `VoiceSessionHost`): the STT/TTS/dictation/turn-detection subsystem. _(Originally landed at `server/voice/`; relocated under `session/` so all session subsystems share one home.)_
-- **#1644 — CheckoutSession, read side** (`session/checkout/checkout-session.ts`, seam `CheckoutSessionHost`, port `CheckoutDiffSubscriber`): status, branch validate/suggest, diff subscribe/unsubscribe, manual refresh. The workspace-git observer already delegates `emitStatusUpdate`/`scheduleDiffRefresh` to it.
-- **ScheduleSession** (`session/schedule/schedule-session.ts`, seam `ScheduleSessionHost`): scheduled-agent request handling.
-
-**Next carve — CheckoutSession mutation side (Slice 4 below).** The 17 checkout _write_ handlers still inline in `session.ts` (`dispatchCheckoutMessage`, ~2010) — branch switch/rename, commit, merge, merge-from-base, pull, push, PR create/merge, github set-auto-merge/get-check-details, PR status, PR timeline, github search, stash save/pop/list — move into the existing `session/checkout/checkout-session.ts` behind `CheckoutSessionHost`. The Slice-3 observer entanglement the table fears is already resolved: #1644 moved the status/diff read side into CheckoutSession, so the workspace observer delegates today and this no longer blocks on the WorkspaceController split.
-
-### Why this is safe at the dispatch seam (verified)
-
-`dispatchInboundMessage` builds `a() ?? b() ?? ... ?? dispatchMiscMessage()` and short-circuits on the first non-`undefined` **Promise object** (not its resolved value). Message-type spaces are **disjoint** (no duplicate `case` labels across switches), so at most one dispatcher matches any message — collapsing to delegation cannot change which handler runs. `dispatchTerminalMessage` (2150-2153) already proves this. `start_workspace_script_request` (a workspace type) is special-cased before terminal delegation (2150).
-
-Rejected alternatives: **feature-module** (free functions + wide context bag) cannot own the live state machines (workspaceUpdatesSubscription, agentUpdatesSubscription, ~25 voice fields) and adds a competing idiom; **mixin-composition** preserves the shared-`this` god object verbatim and requires widening ~325 private fields to protected.
-
-## Slice ordering (least-coupled first)
-
-The task recommended **git/checkout as the first slice — OVERRIDDEN.** Verification: `emitCheckoutStatusUpdate` is called from exactly ONE site (session.ts:4915), inside the workspace-owned `syncWorkspaceGitObserver` callback that ALSO fires workspace effects over shared watch-target maps. Extracting checkout first forces splitting the hardest workspace/git seam before workspace is touched. The safer first cut is **provider-catalog** (one shared collaborator + injected predicates).
-
-| #   | Slice                                                                         | Effort | Risk   |
-| --- | ----------------------------------------------------------------------------- | ------ | ------ |
-| 2   | ProviderCatalogController                                                     | M      | medium |
-| 3   | Split shared workspace-git observer + agent-subscribe fan-out (no controller) | M      | high   |
-| 4   | GitCheckoutController                                                         | L      | medium |
-| 5   | WorkspaceController                                                           | XL     | high   |
-| 6   | Voice prereqs: emit() purity + abortController ownership                      | M      | high   |
-| 7   | VoiceSessionController                                                        | XL     | high   |
-| 8a  | Agent-lifecycle config setters                                                | M      | medium |
-| 8b  | AgentLifecycleController                                                      | XL     | high   |
-
----
-
-## Slice 2 — ProviderCatalogController
-
-**Move:** 7 provider handlers + `emitProviderDisabledResponse` + `getProviderSnapshotEntryForRead` → `packages/server/src/server/provider/provider-catalog-controller.ts`. Move the `providers_snapshot_update` PUSH wiring (1235-1254) into the controller's `start()`/`dispose()`. Collapse `dispatchProviderMessage`.
-
-**SessionContext surface:** `emit`, `sessionLogger`, `providerSnapshotManager` (**shared by reference** — stays a daemon singleton read by checkout/lifecycle/workspace), `isProviderVisibleToClient` (predicate closing over `this`, reads `appVersion` live), `downgradeModeIconsForClient`, `downgradeEntryModesForClient`, agent-control reads `{ listProviderAvailability, listDraftFeatures }`.
-
-**Behavior note:** COMPAT correctness — PUSH and PULL paths MUST call the SAME injected visibility/downgrade closures, reading `appVersion` LIVE (mutated post-construction via `updateAppVersion`). Keep `COMPAT(providersSnapshot)` and `COMPAT(customModeIcons)` comments verbatim. Do NOT pull `resolveStructuredGenerationProviders`/`getFocusedAgentSelectionForCwd` in. **Tests:** `session.dispatch-seam.test.ts`, `daemon-e2e/models.e2e.test.ts`, `session.test.ts`.
-
----
-
-## Slice 3 — Split the shared observer seams (prerequisite, no controller)
-
-In-place refactor on the shell, two named fan-outs:
-
-1. **workspace-git observer** (4910-4917): make `emitCheckoutStatusUpdate` and `onBranchChanged` injectable callbacks; keep `workspaceGitWatchTargets`/`workspaceGitSubscriptions` shared by reference.
-2. **agentManager.subscribe callback** (~1298): refactor into `{ onAgentUpdate, shouldAutoAllowVoicePermission(event), onStreamEvent }`.
-
-**Behavior note:** the single hardest seam, split exactly once before the two domains that co-own it. The observer fires BOTH workspace (`handleWorkspaceGitBranchSnapshot`, `emitWorkspaceUpdateForCwd`) and checkout (`emitCheckoutStatusUpdate`) effects; the agent-subscribe callback is invoked by agent EVENTS (not the `??` chain) and does lifecycle + voice work. Add a test asserting BOTH a `workspace_update` and a `checkout_status_update` fire from one simulated git snapshot change, and a voice-permission test for the auto-allow path. **Tests:** `session.workspace-git-watch.test.ts`, `session.workspaces.test.ts`, `voice-permission-policy.test.ts`, `session.test.ts`.
-
----
-
-## Slice 4 — GitCheckoutController
-
-**Move:** ~22 `checkout_*`/`stash_*`/PR/github handlers + `handleSubscribeCheckoutDiffRequest`/`handleUnsubscribeCheckoutDiffRequest` + `emitCheckoutStatusUpdate` + `checkoutDiffSubscriptions` → `packages/server/src/server/checkout/git-checkout-controller.ts`. Collapse `dispatchCheckoutMessage`.
-
-**SessionContext surface:** `emit`, `sessionLogger`, `checkoutDiffManager` (move in + dispose teardown), `github` (shared), `workspaceGitService` (**shared spine**), `workspaceGitWatchTargets`/`workspaceGitSubscriptions` (**shared**), `providerSnapshotManager.listRegisteredProviderIds`. `emitCheckoutStatusUpdate` is now owned here and injected back into the workspace observer seam from Slice 3.
-
-**Behavior note:** safe now that Slice 3 split the observer. `checkoutDiffSubscriptions` teardown moves to `dispose()`, called by `cleanup()` at its current ordinal (8530). **Tests:** `session.dispatch-seam.test.ts`, `checkout-diff-manager.test.ts`, `daemon-e2e/checkout-diff-subscription.e2e.test.ts`, `session.test.ts`.
-
----
-
-## Slice 5 — WorkspaceController (XL)
-
-**Move:** all workspace handlers (incl. re-homed `handleProjectRenameRequest` and `start_workspace_script_request`) + ~25 private workspace helpers + the whole `workspaceUpdatesSubscription` state machine → `packages/server/src/server/workspace/workspace-controller.ts`.
-
-**SessionContext surface:** `emit`, `sessionLogger`, `projectRegistry`/`workspaceRegistry`/`downloadTokenStore`/script stores/editor cache (**owned**), `workspaceGitService` + watch maps (**shared with checkout**), injected `emitCheckoutStatusUpdate`/`onBranchChanged`, `terminalManager`/`killTerminalsUnderPath`, an `agentUpdatesSubscription` write via a narrow `bufferAgentUpdate` command, `providerSnapshotManager.listRegisteredProviderIds`.
-
-**Behavior note:** the workspaceUpdatesSubscription machine moves WHOLE. The eight already-public workspace methods stay a public surface re-exposed via the shell. Re-homes are atomic remove-from-old-dispatcher + add-to-new-owned-set. **Tests:** `session.workspaces.test.ts`, `session.workspace-git-watch.test.ts`, `session.workspace-resolution-invariants.test.ts`, `session.test.ts`.
-
----
-
-## Slice 6 — Voice prerequisites (emit purity + abort ownership)
-
-In-place, separately reviewable. Split the `audio_output` TTS-debug branch out of `emit()` (8421-8468, bypasses to `onMessage` at 8454) so `emit` is a pure trace+onMessage sink. Move `convertPCMToWavBuffer` (674-701) to `speech/audio.ts`. Decide abortController ownership.
-
-**Behavior note:** TTS-debug split and abortController ownership are the SAME decision (`ttsDebugStreams.clear()` is tied to `createAbortController` reassignment at 8359). Keep `emit` (with the universal trace) on the shell and inject it everywhere — no trace-less emit. Do NOT inject the AbortController by value. Add: a TTS-debug persistence test (with the debug env flag) before the move, and a barge-in→cleanup regression test asserting the NEW run's signal is aborted. **Tests:** `voice-roundtrip.e2e.test.ts`, `voice-permission-policy.test.ts`, `session.test.ts`.
-
----
-
-## Slice 7 — VoiceSessionController (XL)
-
-**Move:** voice handlers + ~25 voice fields + the TTS-debug hook (Slice 6) + `voiceModeAgentId`/`isVoiceMode` + the `shouldAutoAllowVoicePermission` predicate (Slice 3) → the existing `packages/server/src/server/session/voice/voice-session.ts` (see Progress above). Carve voice types out of `dispatchVoiceAndControlMessage`, leaving infra (restart/shutdown/heartbeat/ping/abort) on the shell.
-
-**SessionContext surface:** pure `emit`, `emitBinary`, `hasBinaryChannel`, `sessionLogger`/`sessionId`/`paseoHome`, `getSpeechReadiness`, agent-control port `{ loadAgent, reloadWithSystemPrompt, interruptIfRunning, isRunning, sendSpokenText, buildAgentPrompt }`, `getSignal`/`abortCurrent` (Slice 6).
-
-**Behavior note:** depends on Slices 3 + 6. `cleanup()` stays the ordered orchestrator and calls `voiceController.dispose()` at the position the inlined voice teardown occupies today (8505-8525). **Tests:** `voice-roundtrip.e2e.test.ts`, `voice-local-agent.e2e.test.ts`, `session.voice-mcp-config.test.ts`, `session.test.ts`.
-
----
-
-## Slice 8a — Agent-lifecycle config setters
-
-Parameterize the 4 setter envelopes `handleSetAgentMode/Model/Feature/Thinking` (4209-4390) into one helper; re-home `handleListCommandsRequest` (misfiled in `dispatchMiscMessage`). Add a handleMessage-driven **failure** test per setter (force the command to reject, assert both the `*_response{accepted:false}` AND the `activity_log` error frame in order) BEFORE collapsing. **Tests:** `session.test.ts`, `session.lifecycle-boundary.test.ts`.
-
-## Slice 8b — AgentLifecycleController (XL, LAST)
-
-**Move:** remaining lifecycle handlers + the `agentUpdatesSubscription` fan-out (`bufferOrEmitAgentUpdate`, `flushBootstrappedAgentUpdates`, `matchesAgentFilter`, `forwardAgentUpdate`) → `packages/server/src/server/agent/agent-lifecycle-controller.ts`. Collapse the three lifecycle dispatchers.
-
-**SessionContext surface:** `emit`, `sessionLogger`, `agentManager`/`agentStorage` (**owned**), injected `forwardAgentUpdate` → `buildProjectPlacementForCwd` (backed by WorkspaceController), `agentUpdatesSubscription` accessor (owned; workspace writes via `bufferAgentUpdate`), `isProviderVisibleToClient`, `resolveCreateAgentWorkspace`, `supports`, `mcpBaseUrl`, `terminalController.killTerminalForClose`.
-
-**Behavior note:** done LAST — the shared-projection hub. `handleCloseItemsRequest` splits its terminal-kill half from its agent-archive half. **Tests:** `session.test.ts`, `session.wait-for-finish.test.ts`, `session.create-agent-title.test.ts`, `session.lifecycle-boundary.test.ts`, `daemon-client.e2e.test.ts`.
-
----
-
-## Cross-cutting invariants (every slice)
-
-- **Always** run `npm run typecheck` and `npm run lint` after each slice; run `npm run build:server` before diagnosing cross-package type errors.
-- Controller `dispatch` is **NON-async**, guarded by an owned-type `ReadonlySet` check returning `undefined` synchronously on miss. Never `async dispatch`.
-- Controllers add **no** try/catch inside `dispatch` — error handling stays in `handleMessage`.
-- `cleanup()` stays the single ordered teardown orchestrator on the shell.
-- Move domain error emitters **verbatim**; treat any cross-domain emitter merge as a separate, test-guarded change.
-- Per-slice typecheck/lint/format via `npm run` scripts; never re-run the full suite locally (run only the listed files with `--bail=1`).

docs/release.md

@@ -1,687 +0,0 @@
-# Release
-
-All workspaces share one version and release together.
-
-## Two steps
-
-A release has exactly two steps. The agent does the first, the user authorizes the second.
-
-**Preparation** (local, reversible — agent does this):
-
-- format, lint, typecheck all green
-- resolve the release source to one commit and confirm that commit's existing CI is green
-- classify the diff from the previous stable to the release source as patch or minor, then show the
-  target version and rationale to the user
-- draft the changelog, show it to the user, wait for review
-- run the pre-release sanity check, surface findings to the user
-
-**Go-ahead** (user says "go ahead"):
-
-- commit the approved release inputs locally
-- run the release, which publishes npm and pushes the prepared branch and tag
-- create the release heartbeat immediately and babysit it to completion
-
-Rules that apply to both steps:
-
-- Last-minute changes always need approval. Every time.
-- No code changes bundled into the changelog commit or the release commit. Code shims live in their own commit, reviewed on their own merits.
-- A sanity-check finding is information, not a directive. The agent surfaces it; the user decides.
-- Invoking a release skill is intent to start the flow, not blanket authorization to publish.
-- If the user asks for a release preview, show the prospective changelog/release contents and answer questions, but do not commit, tag, publish, or run release commands until they explicitly authorize the release.
-
-## Release source and CI
-
-The default release source is `origin/main`. Fetch `origin`, then record the
-resolved commit. The default release checkout is a clean local `main` whose
-`HEAD` equals `origin/main`.
-
-An explicit user instruction can select another ref, such as a hotfix commit or
-tag. Resolve that ref once and apply every source, diff, and CI check to that
-commit instead of `origin/main`.
-
-Before making release-preparation commits, confirm the existing CI run for the
-resolved commit is green. Pending CI is watched to completion. Release
-preparation then stays local through the changelog, any explicitly requested ACP
-catalog update, lockfile preparation, and the version commit. After approval,
-commit the prepared inputs locally and run the release command. Its branch and
-tag push is the one remote release batch and starts CI for the complete release
-commit.
-
-## Release branch discipline
-
-While you finalize a release on `main`, use a temporary `next` branch for work intended for the following
-release. This applies to both beta and stable releases.
-
-- Create each new `next` from freshly fetched `origin/main`. Reuse it while active.
-- "This goes to next" means create the PR against `next` or retarget an existing
-  PR, and keep that destination through delivery.
-- Keep `next` current by merging `origin/main` into it as release fixes land.
-  Avoid rebasing this shared branch because agents and open PRs depend on its history.
-- After the release ships, bring `next` up to date and open a `next` → `main` PR.
-  Pass CI and merge without squashing away the individual PR commits needed for
-  the changelog. Retarget remaining PRs based on `next` to `main` and delete the integrated
-  `next`. Create it fresh when needed again.
-
-**Setup still needed:** CI, Docker, and Nix PR checks currently target only `main`,
-and GitHub permits only squash merges. Enable checks and required-check protection
-for `next`, CI on its pushes, and merge commits for the integration PR. Handle PR
-base changes (`edited` events) so retargeting runs checks against the new base;
-GitHub's default PR events do not cover this. Deployment triggers stay unchanged.
-
-### Hotfix from a release tag
-
-If `main` contains changes you do not want to release, branch from the affected
-release tag and cherry-pick only the required fixes. Run CI on that branch, then
-use the normal release flow with it as the explicit source, choosing a new patch
-or beta version. Ensure the fixes and changelog also reach `main` and any active
-`next`, preserving newer development and version changes there. This is a
-short-lived hotfix branch, not another maintained release track.
-
-## ACP catalog updates
-
-ACP catalog work enters a release through an explicit user request:
-
-- **Check ACP drift** — run `npm run acp:version-drift:check`. When drift exists,
-  run `npm run acp:version-drift:update`, verify the catalog, and include the
-  update in the local release-preparation commits.
-- **Update ACP** — run `npm run acp:version-drift:update`, verify the catalog, and
-  include the update in the local release-preparation commits.
-
-The release authorization covers the requested ACP commit. It ships in the same
-release push as the changelog and version commit.
-
-## Two paths
-
-There are two supported release paths:
-
-1. **Direct stable release**: you are ready to ship the resolved release source to everyone immediately (default `origin/main`).
-2. **Beta flow**: release candidates on the `beta` channel. Each beta folds into the series' single changelog entry, publishes npm only on the explicit `beta` dist-tag, and stays behind the Stable/Beta switch on `/download`.
-
-Paseo has one linear release track even though npm dist-tags are independent
-pointers. The npm invariant is:
-
-- A beta release moves only `beta`; `latest` remains on the newest stable.
-- A stable release moves both `latest` and `beta` to that stable version. This
-  keeps users who install `@getpaseo/cli@beta` on the newest Paseo release after
-  a beta is promoted or superseded by a direct stable release.
-
-## Release version decision
-
-Every fresh release starts by classifying the full diff from the previous
-stable to the resolved release source. The highest-impact change determines the
-version:
-
-- **Minor** — a user would experience the release as a significant upgrade. This
-  includes substantial new workflows, providers, forges, platforms, integrations,
-  or meaningful expansions of existing capabilities. Foundational internal work
-  also qualifies when it materially changes reliability, performance,
-  compatibility, deployment, or operation; diff size alone does not.
-- **Patch** — fixes, polish, small enhancements, and reliability or performance
-  improvements within existing capabilities. Follow-up corrections to a minor
-  release are patches.
-
-The release agent selects patch or minor during preparation and presents the
-target version with the changelog for approval. Agents never select a major
-version autonomously. A major release requires an explicit user instruction and
-approval; Paseo remains on major version zero until that deliberate decision.
-
-Version bumps are never used to retry a failed build. Retry the existing version
-as described in **Fixing a failed release build**.
-
-## Standard release (stable)
-
-Before running any stable release command:
-
-- Make sure the resolved release source passed CI, the approved release inputs are committed locally on the intended branch, and the working tree is clean.
-- **Run `npm run format`, `npm run lint`, and `npm run typecheck` and commit any resulting changes BEFORE you start any `release:*` command.** `release:check` runs `npm install --workspaces --include-workspace-root` as part of `release:prepare`, which can mutate `package-lock.json` (e.g. churning `"dev": true` markers on optional deps). The next step, `version:all:*`, runs `npm version` which aborts when the working tree is dirty. If this happens mid-flight you have to commit the lockfile churn before retrying — and the pre-commit format hook will reject a lockfile-only commit because oxfmt internally skips `package-lock.json` while lefthook's glob still matches it. Avoid the whole mess by running format/lint/typecheck first, then `release:prepare` once on its own to absorb any lockfile churn into a normal commit, then start the release.
-- Do not use a release command as a substitute for checking whether the current commit is actually ready.
-
-```bash
-# Run exactly one, matching the approved decision:
-npm run release:patch
-npm run release:minor
-```
-
-This bumps the version across all workspaces, runs checks, publishes to npm, and pushes the branch + tag. The tag push triggers `Desktop Release`, `Android APK Release`, `Docker`, and `Release Notes Sync` on GitHub Actions. The workflows create the GitHub Release as a draft while builds and release-note sync run. EAS picks up the same tag via the EAS GitHub app and starts the iOS + Android store builds in parallel (see "Mobile builds (EAS)" below) — there is no mobile-release workflow under `.github/workflows`.
-
-After the stable release succeeds, move npm's `beta` pointer to the new stable
-version for every published package. This changes dist-tags only; do not
-republish the packages:
-
-```bash
-PASEO_VERSION=$(node -p "require('./package.json').version")
-for package in highlight relay protocol client plugin server cli; do
-  npm dist-tag add "@getpaseo/$package@$PASEO_VERSION" beta
-done
-```
-
-Verify both npm tags now resolve to `PASEO_VERSION` before considering the
-stable release complete.
-
-The Docker workflow builds images from the checked-out source tree on pull requests and on `main` as non-publishing checks. Stable `vX.Y.Z` tag pushes publish `ghcr.io/getpaseo/paseo:X.Y.Z` and `ghcr.io/getpaseo/paseo:latest`; beta `vX.Y.Z-beta.N` tag pushes publish only `ghcr.io/getpaseo/paseo:X.Y.Z-beta.N` and never move `latest`.
-
-The production relay is the Elixir service in [getpaseo/paseo-relay](https://github.com/getpaseo/paseo-relay), with its own deployment process. Paseo releases and pushes to this repository do not deploy it. The Cloudflare relay code and workflow in this repository are legacy and are not used in production.
-
-**Stable means stable.** If the user says "stable" or "ship stable", do not ask whether they want a beta first. They picked stable; treat it as a direct stable release. Only run the beta flow when the user explicitly says "beta".
-
-## Manual step-by-step
-
-```bash
-npm run typecheck            # Verify the exact commit you intend to release
-npm run release:check        # Typecheck, build, dry-run pack
-# Run exactly one approved version command:
-npm run version:all:patch
-npm run version:all:minor
-npm run release:publish      # Publish to npm
-npm run release:push         # Push HEAD + tag (triggers CI workflows)
-# Then move npm's beta dist-tag to this stable version using the command above.
-```
-
-## Beta flow
-
-```bash
-npm run release:beta:patch       # Start the next patch beta line
-npm run release:beta:minor       # Start the next minor beta line
-# ... test desktop and APK prerelease assets from GitHub Releases ...
-npm run release:beta:next        # Optional: cut X.Y.Z-beta.2, beta.3, ...
-npm run release:promote          # Promote X.Y.Z-beta.N to stable X.Y.Z
-```
-
-- Beta tags are published GitHub prereleases like `v0.1.41-beta.1`
-- Betas publish npm packages with `--tag beta`, so `npm install @getpaseo/cli@beta` opts in while plain `npm install @getpaseo/cli` stays on `latest`
-- Betas publish desktop assets and APKs for testing. They also build iOS, upload it to TestFlight, add it to the `Paseo Beta` external group, and submit it for Beta App Review. They do not submit mobile builds to the production stores.
-- `release:promote` creates a fresh stable tag like `v0.1.41`; the final release never reuses the beta tag
-- Desktop assets now come from the Electron package at `packages/desktop`
-- Require the Linux artifact CI checks with both restricted and usable user namespaces to pass before publication; see [packaged desktop smoke](testing.md#packaged-desktop-smoke). Keep the installed-package and AppImage checks together.
-- Beta releases use Electron's `beta` update channel. Users on the stable channel only receive stable releases; users on the beta channel receive beta releases and the final stable release when it is published.
-- **A beta series has one changelog entry.** Each beta folds into it and renames its heading to the new `## X.Y.Z-beta.N`, which `Release Notes Sync` mirrors into that prerelease body. Promotion renames it to the stable heading. See the Changelog policy section.
-
-Use the beta path when you need to:
-
-- smoke a build yourself before promoting it to everyone
-- test a build manually in a Linux or Windows VM
-- send a build to a user who is hitting a specific problem
-- iterate on `beta.1`, `beta.2`, `beta.3`, and so on before deciding to ship broadly
-
-## Staged rollout (stable channel)
-
-Stable desktop releases go out via a linear time-based rollout for automatic update checks: 0% admitted when the updater manifests appear, 100% admitted 36 hours later, linear ramp in between. Manual checks bypass the rollout so a user can install immediately when they click **Check**. Beta releases bypass the rollout entirely — beta users always receive updates immediately.
-
-The rollout is driven by a `rolloutHours` field stamped into the GitHub Release manifests (`latest-mac.yml`, `latest-linux.yml`, `latest.yml`) by the `finalize-rollout` job in `desktop-release.yml`.
-
-Desktop release builds now publish in two phases:
-
-- The GitHub Release stays a draft while platform build jobs upload the installers/packages (`.dmg`, `.zip`, `.exe`, `.AppImage`, etc.).
-- The final job merges and stamps every channel manifest, uploads them with the final `releaseDate` and `rolloutHours`, then publishes the GitHub Release.
-
-Drafts do not appear in GitHub's releases feed. Updater clients continue to see the previous complete release until all three manifests are available. If a desktop build or manifest upload fails, the new release stays a draft.
-
-### Default behavior
-
-`npm run release:patch` or `npm run release:minor` → tag push → 36h ramp. No extra action needed.
-
-The `rollout_hours` input on `desktop-release.yml` is **only read on `workflow_dispatch`** — tag-push runs always default to 36. To get any other rollout duration on a fresh release, use the post-publish flip below.
-
-### Instant-admit release (rollout_hours=0 from publish)
-
-For a fresh release that should admit everyone immediately (low-risk change, doc-only, hotfix, or just a release you want out fast), cut the release normally and queue the rollout flip immediately after:
-
-```bash
-# 1. Cut and publish (default 36h ramp from tag push).
-npm run release:patch
-
-# 2. Immediately queue the flip — runs as soon as finalize-rollout completes.
-gh workflow run desktop-rollout.yml \
-  -f tag=v0.1.64 \
-  -f rollout_hours=0
-```
-
-**Why this is gap-free:** `desktop-release.yml`'s `finalize-rollout` job and `desktop-rollout.yml` share the concurrency group `desktop-rollout-<tag>`. Dispatching `desktop-rollout.yml` while the tag-push pipeline is still running queues it safely behind `finalize-rollout`. The first public manifests already carry `rolloutHours=36`, then `desktop-rollout.yml` flips them to `rolloutHours=0` shortly afterward. The renderer polls every 30 minutes, so active stable users pick up the new manifest on their next check.
-
-Run the dispatch right after `release:patch` or `release:minor` returns. Don't wait for the tag-push CI to finish.
-
-### Adjusting an already-published release
-
-To change the rollout duration on a release that's already shipped — e.g. flip a hotfix to instant admit, or slow a release down — use the dedicated `desktop-rollout.yml` workflow. It edits the manifests in place on the GitHub release without rebuilding anything. It only rewrites `rolloutHours`; `releaseDate` is preserved, so the rollout clock keeps ticking from the original publish time.
-
-**Hotfix (instant admit) on an already-shipped release:**
-
-```bash
-gh workflow run desktop-rollout.yml \
-  -f tag=v0.1.42 \
-  -f rollout_hours=0
-```
-
-`rollout_hours=0` admits 100% of stable users on their next update check (within ~30 min for active clients).
-
-**Slow a rollout down** (e.g. extend total duration to 72h since the original release):
-
-```bash
-gh workflow run desktop-rollout.yml \
-  -f tag=v0.1.42 \
-  -f rollout_hours=72
-```
-
-`rollout_hours` is **total duration since the original release date**, not "extend by N more hours from now." If `v0.1.42` was published 2h ago and you set `rollout_hours=72`, the ramp finishes 70h from now.
-
-The dispatch is idempotent and shares the `desktop-rollout-<tag>` concurrency group with `desktop-release.yml`'s `finalize-rollout` job, so it serializes safely against an in-flight tag-push pipeline targeting the same release.
-
-### Custom ramp on a manually-dispatched build
-
-`desktop-release.yml` accepts `rollout_hours` only on `workflow_dispatch`, which is the path used to **rebuild an existing tag** (retry a failed release, force a rebuild on a different ref). When you go that route, you can stamp a non-default ramp directly:
-
-```bash
-gh workflow run desktop-release.yml \
-  -f tag=v0.1.43 \
-  -f rollout_hours=6
-```
-
-This does **not** apply to fresh releases cut via `npm run release:patch` or `npm run release:minor` — those paths always tag-push and stamp 36. For a fresh release with a custom ramp, cut normally and then dispatch `desktop-rollout.yml` (same pattern as the instant-admit flow above, with your chosen `rollout_hours`).
-
-### Releasing during an active rollout
-
-If you ship N+1 while N is still ramping, N+1 starts a fresh rollout from its own publish timestamp. N's rollout effectively ends — the newer manifest supersedes it. Rollout-aware clients revalidate the manifest for up to five seconds before installing a downloaded update on quit. If N+1 has replaced N but the client is not admitted to N+1 yet, it skips the downloaded N and waits rather than installing two updates in succession. If revalidation times out, the app exits without installing the cached update.
-
-If N+1 is a hotfix for a bug in N, dispatch `desktop-rollout.yml -f tag=v0.1.<N+1> -f rollout_hours=0` after N+1 publishes so the users who already got N reach the fix fast.
-
-### macOS system floor
-
-The desktop app requires macOS 13 or newer. Keep both release guards when the floor changes:
-
-- `packages/desktop/electron-builder.yml` writes the macOS version to `LSMinimumSystemVersion` for new installs.
-- `scripts/merge-mac-manifest.mjs` writes the matching Darwin kernel version to `minimumSystemVersion` in the update manifest. Existing clients check this before downloading an update.
-
-macOS 13 maps to Darwin 22. The two values use different version domains; do not copy the macOS version into the update manifest.
-
-### Limitations
-
-- **No pause / kill switch.** To stop new admissions, ship a superseding release. Clients revalidate on quit and will not install the superseded download, but a client that already completed installation cannot be recalled; ship a hotfix `+1` patch.
-- **No rollback.** `allowDowngrade = false`. Bad release = ship a hotfix.
-- **Bootstrap caveat.** Clients running a build older than the rollout feature ignore `rolloutHours` and admit immediately. Rollout protection only applies to clients running the rollout-aware version or later.
-- **Up to ~30 min automatic admission latency.** Renderer polls every 30 minutes, so a stable user may take up to that long to be evaluated against the rollout window. Clicking **Check** is manual and bypasses rollout admission.
-
-## Mobile builds (EAS)
-
-iOS and Android store builds are not in `.github/workflows`. They are triggered by the EAS GitHub app the moment the `v*` tag is pushed:
-
-- **Android (Play Store)** — EAS builds with profile `production` and auto-submits to the Play Store via `eas submit` (EAS-managed credentials, no Fastlane).
-- **iOS (TestFlight + App Store)** — EAS builds with profile `production`, uploads to TestFlight, and a Fastlane lane submits the build for App Store review.
-- **Android APK (GitHub Release asset)** — separate, via `.github/workflows/android-apk-release.yml`. This is the only Android-related workflow that lives in this repo.
-
-EAS uses the local app version source. `packages/app/app.config.js` derives the native version from the package version. Android `versionCode` is `major * 1_000_000 + minor * 1_000 + patch`. iOS reserves 1,000 build slots per app version: beta `N` uses slot `N`, and stable uses slot `999`. For example, `0.2.6-beta.2` appears in App Store Connect as version `0.2.6` build `2006002`; stable uses build `2006999`. Rebuilding the same tag produces the same native build number; if a store has already accepted a binary and you need a different binary, cut the next beta or patch instead of relying on EAS remote auto-increment.
-
-Beta tags run `Release iOS Beta`. The workflow uploads the build to TestFlight, distributes it to the persistent `Paseo Beta` external group, and submits it for Beta App Review. Testers and the group are managed once in App Store Connect; releases require no dashboard action.
-
-There is no mobile-release workflow under `.github/workflows`. The EAS GitHub app reads the workflows under `packages/app/.eas/workflows` and handles tag triggering directly.
-
-### Watching mobile builds from the terminal
-
-Use the EAS CLI from `packages/app/`:
-
-```bash
-cd packages/app
-
-# Recent builds (newest first). Pipe to jq for status only.
-npx eas build:list --limit 8 --non-interactive --json | jq '.[] | {platform, status, appVersion, gitCommitHash}'
-
-# Recent EAS workflow runs. This is the source of truth for submit/review jobs.
-npx eas workflow:runs --json | jq '.[] | {status, workflowName, trigger, gitCommitHash, startedAt, finishedAt}'
-
-# Filter by platform.
-npx eas build:list --platform ios --limit 5 --non-interactive --json
-npx eas build:list --platform android --limit 5 --non-interactive --json
-
-# Inspect a specific build.
-npx eas build:view <build-id>
-
-# Inspect the full release workflow, including submit_ios, submit_android,
-# and submit_ios_for_review.
-npx eas workflow:view <workflow-run-id> --json
-
-# Read failed submit/review job logs.
-npx eas workflow:logs <workflow-job-id> --all-steps --non-interactive
-
-# Stream logs for a build.
-npx eas build:view <build-id> --json | jq '.logFiles[]'
-```
-
-A build's `gitCommitHash` must match the release tag commit. `status` walks through `NEW` → `IN_QUEUE` → `IN_PROGRESS` → `FINISHED` (or `ERRORED`/`CANCELED`). The EAS workflow run's `gitCommitHash` and `trigger` must also match the release tag.
-
-Once a build is `FINISHED`, EAS still has release-critical work to do: Android must submit to the Play Store, and iOS must upload to TestFlight **and** submit the build for App Store review. The release is not done until all platforms are on their way through the stores.
-
-For the `Release Mobile` EAS workflow, these jobs must pass:
-
-- `build_ios` — iOS binary built
-- `submit_ios` — iOS binary uploaded to App Store Connect/TestFlight
-- `submit_ios_for_review` — iOS build submitted for App Store review via Fastlane
-- `build_android` — Android store binary built
-- `submit_android` — Android binary submitted to the Play Store
-
-Do not treat `build_ios: SUCCESS` or `submit_ios: SUCCESS` as a completed iOS release. `submit_ios_for_review: FAILURE` means the iOS release is blocked even if the build is visible in TestFlight.
-
-To confirm the submission landed, inspect the EAS workflow with `npx eas workflow:view <workflow-run-id> --json`. App Store Connect (review state for the matching version/build) and the Play Console track are the final ground truth.
-
-## Release completion and heartbeat
-
-A release is **in progress** after npm publication and tag push. Report it as
-**shipped** only after every applicable build, publication, asset, manifest, and
-store submission passes the completion checklist.
-
-Immediately after every beta, stable, or promotion tag push, create a heartbeat
-that resumes the release in the current conversation. Create it automatically
-with `create_heartbeat`. The heartbeat owns the release until it either reaches
-the completion checklist or finds a failure that needs new user authority.
-
-Each heartbeat checks the release tag commit, all GitHub Actions runs for the
-release branch and tag, npm dist-tags, the GitHub Release body and assets,
-desktop updater manifests, the published Docker image, and the applicable EAS
-workflow. Inspect the GitHub Release itself and confirm that the macOS, Linux,
-Windows, and Android APK assets are present along with the channel manifests
-(`latest-mac.yml`, `latest-linux.yml`, and `latest.yml` for stable;
-`beta-mac.yml`, `beta-linux.yml`, and `beta.yml` for beta).
-
-For stable releases, also confirm every required mobile build, upload, store
-submission, and review-submission job for the release commit. For betas, confirm
-the beta EAS workflow completed its TestFlight distribution and Beta App Review
-path. Delete the heartbeat only after every applicable checklist item passes,
-then report the release as shipped.
-
-Pattern:
-
-```jsonc
-// mcp__paseo__create_heartbeat arguments
-{
-  "name": "vX.Y.Z release babysit heartbeat",
-  "cron": "*/10 * * * *",
-  "timezone": "UTC",
-  "maxRuns": 120,
-  "expiresIn": "24h",
-  "prompt": "Resume the vX.Y.Z release babysit for commit <sha>. Check npm tags; every GitHub Actions run for the release branch and tag; the published GitHub Release body, expected desktop/APK assets, and channel manifests; the Docker image; and the matching EAS workflow. Completion requires every applicable checklist item. For stable, require build_ios, submit_ios, submit_ios_for_review, build_android, and submit_android to succeed. For beta, require the beta TestFlight distribution and Beta App Review path. If work is pending, wait for the next heartbeat. If a failure can be retried safely for the same version, follow the failed-release procedure; otherwise report the blocker. When every applicable completion-checklist item passes, delete THIS heartbeat, report shipped, and stop.",
-}
-```
-
-Run an immediate status check after creating the heartbeat. The heartbeat handles
-later transitions and stops itself when the release is complete.
-
-## Release notes on GitHub
-
-The GitHub Release body is populated automatically by the `Release Notes Sync` workflow (`.github/workflows/release-notes-sync.yml`). It triggers on every `v*` tag push and on any push to `main` that touches `CHANGELOG.md`, then runs `scripts/sync-release-notes-from-changelog.mjs` to mirror the matching changelog entry into the release body. You don't need to write release notes on GitHub manually — keep `CHANGELOG.md` correct and the workflow will sync it. To force a re-sync, dispatch the workflow with the tag input.
-
-## Website behavior
-
-- The website download page defaults to GitHub's latest published **stable** release.
-- A published beta prerelease is offered behind the Stable/Beta switch on `/download` (`?channel=beta`), never as the default. The switch only appears while the newest prerelease leads stable on its core version, so promoting `X.Y.Z-beta.N` to `X.Y.Z` retires the beta channel from the page until the next beta line opens.
-- Homebrew, the Play Store, the App Store, and `app.paseo.sh` have no beta. The Beta view drops those rows, and the whole Web section, rather than showing an inert "stable only" placeholder. When a surface gains a beta path — say a public TestFlight link — add its row back in `packages/website/src/routes/download.tsx`.
-- The default download target only moves when you publish the final stable release tag like `v0.1.41`.
-- The public `/changelog` page renders `CHANGELOG.md` as-is, so the in-flight `-beta.N` entry shows there once it lands on `main` — that's intended, it's where beta users check what's coming. Only the **default download target** stays pinned to the latest stable; the download links read GitHub's releases API, not the changelog, so a `-beta.N` heading on top never affects them.
-- The download page's "What's new" link deep-links the **minor group** anchor (`/changelog#release-0.3`), not the exact entry: the beta entry is renamed on each beta and on promotion, so the minor group remains the durable target. A version with no entry in the bundled changelog — a tag whose changelog commit hasn't redeployed the site yet — links the plain `/changelog` instead of a dead anchor.
-- The website itself is deployed by `Deploy Website` (Cloudflare Workers), which redeploys on the `release: published` event emitted when a stable draft is published and on pushes to `main` that touch `CHANGELOG.md` or `packages/website/**`. Its job condition excludes beta prereleases.
-
-## Fixing a failed release build
-
-**NEVER bump the version to fix a build problem.** New versions are reserved for meaningful product changes (features, fixes, improvements). Build/CI failures are fixed on the current version.
-
-**Do not rely on `workflow_dispatch` for tagged code fixes.** The `workflow_dispatch` trigger runs the workflow file from the default branch but checks out the code at the tag ref (`ref: ${{ inputs.tag }}`). That means fixes committed to `main` won't change the tagged source tree being built. `workflow_dispatch` only helps when the fix lives in the workflow file itself.
-
-For Docker-only retries, **do not push or force-push a `v*` release tag**.
-`v*` tag pushes rebuild desktop assets, the Android APK, Docker, release notes,
-and EAS mobile release builds. Use the Docker workflow dispatch instead:
-
-```bash
-gh workflow run docker.yml \
-  --ref main \
-  -f paseo_version=X.Y.Z-beta.N \
-  -f publish=true
-```
-
-This replaces `ghcr.io/getpaseo/paseo:X.Y.Z-beta.N` in place without touching
-desktop, APK, or EAS release builders. The Docker exception is safe because the
-dispatch runs from `--ref main` and uses the explicit `paseo_version`; it does
-not check out or move the `v*` release tag.
-
-To retry a failed non-Docker release workflow, push a retry tag on the commit
-you want to build. Reusing the same tag name is expected: move it with
-`git tag -f ...` and push it with `--force` so the workflow rebuilds the commit
-you actually want.
-
-A failed desktop build leaves the GitHub Release as a draft. `finalize-rollout`
-uploads manifests from successful platforms before it fails. A later
-single-platform retry reuses those manifests, stamps the complete set with one
-release date, and publishes the draft. Use `desktop-vX.Y.Z` when more than one
-platform failed. A `workflow_dispatch` rebuild with publishing enabled follows
-the same path against the existing draft.
-
-Prefer a tag push over `workflow_dispatch` when rebuilding desktop or APK
-release assets. Prefer Docker workflow dispatch when rebuilding only the Docker
-image.
-
-The retry tag patterns below still work and remain the supported way to rebuild specific release targets:
-
-```bash
-# Desktop (all platforms)
-git tag -f desktop-v0.1.28 HEAD && git push origin desktop-v0.1.28 --force
-
-# Desktop (single platform)
-git tag -f desktop-macos-v0.1.28 HEAD && git push origin desktop-macos-v0.1.28 --force
-git tag -f desktop-linux-v0.1.28 HEAD && git push origin desktop-linux-v0.1.28 --force
-git tag -f desktop-windows-v0.1.28 HEAD && git push origin desktop-windows-v0.1.28 --force
-
-# Android APK
-git tag -f android-v0.1.28 HEAD && git push origin android-v0.1.28 --force
-
-# Beta
-git tag -f v0.1.29-beta.2 HEAD && git push origin v0.1.29-beta.2 --force
-```
-
-This ensures the checkout ref matches the actual code on `main` with the fix included.
-
-- `vX.Y.Z` or `vX.Y.Z-beta.N` rebuilds the full tagged release
-- `desktop-vX.Y.Z` rebuilds desktop for all desktop platforms only
-- `desktop-macos-vX.Y.Z`, `desktop-linux-vX.Y.Z`, and `desktop-windows-vX.Y.Z` rebuild only that desktop platform
-- `android-vX.Y.Z` rebuilds the Android APK release only
-
-If you decide to publish a release without working desktop builds, inspect its
-assets first, then publish it manually:
-
-```bash
-RELEASE_LOOKUP=$(node scripts/github-release.mjs --repo getpaseo/paseo --tag vX.Y.Z)
-gh release view "$RELEASE_LOOKUP" --json isDraft,isPrerelease,assets
-gh release edit "$RELEASE_LOOKUP" --tag vX.Y.Z --draft=false
-
-# Keep a beta marked as a prerelease:
-RELEASE_LOOKUP=$(node scripts/github-release.mjs --repo getpaseo/paseo --tag vX.Y.Z-beta.N)
-gh release edit "$RELEASE_LOOKUP" --tag vX.Y.Z-beta.N --draft=false --prerelease
-```
-
-This bypasses the updater-manifest guarantee. Use it only when the release is
-intentionally unavailable to desktop updater clients.
-
-## Notes
-
-- `version:all:*` bumps root + syncs workspace versions and `@getpaseo/*` dependency versions
-- The npm `version` lifecycle regenerates F-Droid changelog files from `CHANGELOG.md` for stable releases only (`npm run fdroid:changelogs`) and stages them, so the release tag carries them. Betas are a no-op. A stable run **aborts the release** if `CHANGELOG.md` has no entry for the version being cut — commit the changelog entry first. See [docs/android.md](android.md) for why these files are generated per ABI.
-- `release:prepare` refreshes workspace `node_modules` links to prevent stale types
-- `npm run dev:desktop` and `npm run build:desktop` target the Electron desktop package in `packages/desktop`
-- If `release:publish` partially fails, re-run it — npm skips already-published versions
-- If `release:publish:beta` partially fails, re-run it — npm skips already-published versions and keeps prereleases off `latest` because every publish uses `--tag beta`
-- The website uses GitHub's latest published release API for download links, so published beta prereleases do not replace the stable download target.
-
-## Changelog format
-
-Release notes depend on the changelog heading format. The heading **must** be strictly followed:
-
-```
-## X.Y.Z - YYYY-MM-DD
-## X.Y.Z-beta.N - YYYY-MM-DD
-```
-
-No prefix (`v`), no extra text. `Release Notes Sync` matches the `## X.Y.Z` (or `## X.Y.Z-beta.N`) line for the pushed tag to extract the version. A malformed heading breaks the release-notes sync for that tag.
-
-`CHANGELOG.md` on `main` is also what the app's **What's new** sheet fetches and renders, so the file is a shipped product surface, not just a release input. `##` starts a release and `###` starts a section; the app reads section titles from the document, so renaming or adding one needs no app change. Everything under a section is rendered as Markdown: prose, lists, links, inline code, fenced code, block quotes, tables, and images. Raw HTML does not render — the shared Markdown parser runs with `html: false`, so a `<video>`, `<iframe>` or `<embed>` tag reaches the reader as visible markup. Keep media out of the changelog, or link to it. A GitHub callout renders as a block quote with its `[!NOTE]` marker still in the text. A release entry is what a user reads on a phone the moment they are offered the update — write it for them.
-
-## Changelog policy
-
-- `CHANGELOG.md` holds stable releases and at most one entry for the current beta series.
-- The first beta of a version inserts a top entry like `## 0.1.60-beta.1 - YYYY-MM-DD`.
-- Each subsequent beta rewrites that entry in place: the heading becomes the new beta number and date, and the body describes the full change from the previous stable release to this beta. Never add a second beta entry.
-- The entry is a list of changes, not of PRs. When a later beta reverts, reworks, or follows up on something an earlier beta added, rewrite the bullet to the current behavior or delete it. A stable user never saw the earlier beta behavior, so fixes to it are not "Fixed" bullets.
-- Anything that already shipped to stable through a patch release on an older line stays out of the beta entry.
-- Stable promotion renames the entry to `## 0.1.60 - YYYY-MM-DD` after a final review.
-
-Older prerelease bodies on GitHub keep the notes they were synced with; `Release Notes Sync` only writes the release whose tag matches the top entry.
-
-## Changelog ownership
-
-- **The agent running the release writes the changelog entry — beta or stable.** The release context and final wording stay with that agent.
-- **Commit history is only an index of the changes. Never draft the changelog from commit subjects or diffs alone.** For every PR in the release range, read the full PR description and every issue it links to before deciding what changed, why users care, or how changes should be grouped. Use the implementation only to verify the resulting understanding.
-- Every entry, beta or stable, is drafted from the previous stable release to the release source. For a later beta, read the PRs since the previous beta tag, then rework the existing entry so each bullet still describes current behavior. Review the result against the changelog policy below, show it to the user, and wait for approval before committing it.
-
-## Changelog wording
-
-The changelog is shown on the Paseo homepage. Each bullet is a compact factual record of
-product behavior that changed.
-
-- **Name the exact change.** Prefer `Added <capability>`, `Removed <behavior>`,
-  `Changed <behavior>`, or `Fixed <failure> when <condition>`.
-- **Keep the scope exact.** A conditional bug is not a general reliability problem. Do not
-  broaden one failure into claims that Paseo is now faster, smoother, responsive, or reliable.
-- **Use concrete product and runtime terms.** Git polling, persisted cache, provider catalog,
-  and WebSocket reconnects can identify the affected behavior. Component names, internal
-  modules, code symbols, and implementation techniques cannot: omit `WorkingIndicator`,
-  `reconcileAndEmitWorkspaceUpdates`, remounts, memoization, and controlled inputs.
-- **State the consequence only when the change itself is unclear.** Keep the condition that
-  makes the consequence true. Do not replace a precise change with a broad benefit claim.
-- **Do not invent context.** Mention an upgrade, platform, workload, or user action only when
-  the PR or linked issue establishes that scope.
-
-| Avoid                                                        | Write                                                 |
-| ------------------------------------------------------------ | ----------------------------------------------------- |
-| Paseo stays responsive with many idle Git workspaces         | Removed periodic Git polling for idle workspaces      |
-| Incompatible saved app data no longer crashes after upgrades | Fixed crash when persisted cache was incompatible     |
-| Splitting layouts no longer remounts the active agent        | Fixed scroll position resetting when splitting a pane |
-| Mobile model selector is faster and more straightforward     | Added search to the mobile model selector             |
-
-Test each bullet against the source PR and issue: can a reviewer point to the exact behavior
-that changed, the failure that was fixed, or the capability that was added? If the bullet only
-claims a general improvement, rewrite it with the concrete change.
-
-- **Use the entry's release scope.** Include changes within the matching range in **Changelog scope**.
-- **Collapse internal iterations within that scope.** Present a feature added and fixed in one range as working.
-- **Cut low-signal entries.** "Toolbar buttons have consistent sizing" is too granular. Combine small polish items or drop them.
-
-## Changelog conciseness
-
-Every bullet must be scannable at a glance. The changelog is not release documentation — it's a list.
-
-- **One sentence per bullet, max.** If a bullet contains two sentences, the second one is doing work that belongs in product docs, not the changelog. Cut it.
-- **No trailing periods.** Bullets are list items, not prose. Drop the period at the end of every bullet, including the period inside any bolded lead-in. `**Configurable terminal scrollback**` not `**Configurable terminal scrollback.**`.
-- **One line per bullet.** If a bullet wraps to three lines in a narrow column, it's too long.
-- **Split bullets that pack multiple distinct changes.** If a bullet uses "and", "plus", a comma list, or an em-dash to chain several independent improvements, break them into separate bullets — even when they share a theme or author. One bullet = one user-facing change.
-- **Trim qualifying clauses.** Drop "with a hint shown when…", "matching the CLI's behaviour", "across common install shapes". If the detail doesn't change whether a user cares, cut it.
-- **Stop after identifying the change.** Do not explain LAN/WAN topology, TLS handshakes, IPC, or other architecture in a changelog bullet. Put necessary background in product docs.
-- **Attribution follows the split.** When you split a dense bullet, move each PR/author to the bullet it belongs to. Never duplicate the same PR across multiple bullets.
-
-## Changelog attribution
-
-Every changelog bullet must credit contributors and link to the PR(s) that delivered the change. This is not one-PR-per-line — a single bullet describes a user-facing change and may reference multiple PRs.
-
-Format: append `([#123](https://github.com/getpaseo/paseo/pull/123) by [@user](https://github.com/user))` at the end of each bullet. For changes spanning multiple PRs or contributors:
-
-```markdown
-- Voice mode now works on tablets with proper microphone permissions. ([#210](https://github.com/getpaseo/paseo/pull/210), [#215](https://github.com/getpaseo/paseo/pull/215) by [@alice](https://github.com/alice), [@bob](https://github.com/bob))
-```
-
-Rules:
-
-- **Always link the PR number** as `[#N](https://github.com/getpaseo/paseo/pull/N)`.
-- **Always link the contributor's GitHub profile** as `[@user](https://github.com/user)`.
-- **One bullet = one user-facing change**, regardless of how many PRs went into it. Group related PRs on the same bullet.
-- **De-duplicate contributors.** If the same person authored multiple PRs in one bullet, list them once.
-- **Only credit external contributors.** Skip attribution for [@boudra](https://github.com/boudra). The changelog credits community contributions — core team work is the default.
-- **Credit the commit author, not the PR opener.** A maintainer often opens a PR that lands work authored by someone else (cherry-pick, rebase of a contributor's branch, manual extraction from a stacked PR). The squash commit preserves the original commit's author, but `gh pr view N --json author` returns the PR opener — using that field will silently mis-credit the work to the maintainer (and then the "skip @boudra" rule drops the attribution entirely). Always resolve attribution from commit authors.
-
-  Use this command to get the GitHub logins for each PR:
-
-  ```bash
-  gh pr view N --json commits --jq '[.commits[].authors[].login] | unique | .[]'
-  ```
-
-  This returns every distinct GitHub login that authored or co-authored a commit in the PR. Use those logins for attribution. Fall back to `gh pr view N --json author` only if the commits command returns nothing (which should not happen for merged PRs).
-
-  When listing PR numbers, `git log --format='%H %s' v<previous>..<release-source-sha> | grep -E '\(#[0-9]+\)$'` pulls the PR number out of squash commit subjects.
-
-## Changelog ordering
-
-Entries within each section (Added, Improved, Fixed) are ordered by user impact:
-
-1. **User-facing features and changes first** — things users will notice, want to try, or that change their workflow.
-2. **Quality-of-life improvements** — polish, performance, smoother interactions.
-3. **Internal/infra changes last** — only include if they have a tangible user benefit (e.g. "faster startup" is user-facing even if the fix was internal).
-
-## Pre-release sanity check
-
-Before cutting a **stable** release, the release agent reviews the diff as a last line of defence against shipping bugs. Skip this for betas — the beta itself is the smoke test, and gating each beta on a code review defeats the point of using betas as fast release candidates.
-
-Review the diff between the latest release tag and the resolved release source. Focus on:
-
-1. **Breaking changes** — especially in the WebSocket protocol, agent lifecycle, and any server↔client contract.
-2. **Backward compatibility** — the important direction is old app clients talking to newly updated daemons. Users update desktop and daemon first, then keep running the old app for a while. Flag anything that breaks old clients against new daemons or requires both sides to update in lockstep.
-3. **Regressions** — anything that looks like it could break existing functionality.
-
-Use `git diff <latest-release-tag>..<release-source-sha>` as the review input. This is a deep sanity check, not a full code review. If anything looks risky, investigate before proceeding and surface the finding to the user.
-
-## Changelog scope
-
-Changelog scope follows the release being described:
-
-Every entry covers `previous stable release → release source`: first beta, later beta, direct stable release, and promotion alike. The beta entry always reads as the stable entry would if the beta were promoted today.
-
-## Completion checklist
-
-### Beta release
-
-- [ ] The resolved release source is the intended commit (default `origin/main`) and its existing CI is green
-- [ ] Every PR in the release range has been opened, and its full description and every linked issue have been read before drafting the changelog
-- [ ] Fold this beta into the series' single `CHANGELOG.md` entry (heading `## X.Y.Z-beta.N - YYYY-MM-DD`, previous stable → release source), review it against the changelog policy, get approval, and commit it before cutting the release
-- [ ] The diff from the previous stable to the resolved release source is classified as patch or minor, with the target version and rationale approved
-- [ ] Release preparation stayed local until the approved release command pushed the complete branch and tag
-- [ ] `npm run release:beta:patch`, `npm run release:beta:minor`, or `npm run release:beta:next` completes successfully
-- [ ] Every GitHub Actions run for the complete release commit and tag is green
-- [ ] npm shows the version under the `beta` dist-tag, not `latest`
-- [ ] The GitHub prerelease was published only after the three beta manifests were uploaded, and it has the changelog body and every expected macOS, Linux, Windows, and Android APK asset
-- [ ] GitHub `Desktop Release` workflow for the `v*-beta.N` tag is green
-- [ ] The GitHub prerelease contains `beta-mac.yml`, `beta-linux.yml`, and `beta.yml`
-- [ ] GitHub `Android APK Release` workflow for the same tag is green
-- [ ] GitHub `Docker` workflow is green and the versioned beta image is published without moving `latest`
-- [ ] GitHub `Release Notes Sync` mirrored the beta entry into the prerelease body
-- [ ] EAS `Release iOS Beta` completed its build, TestFlight distribution, external beta group, and Beta App Review path
-- [ ] The release heartbeat was created after the tag push and deleted only after every item above passed
-
-### Stable release (or promotion)
-
-- [ ] Run the pre-release sanity check (see above) and address any findings
-- [ ] The diff from the previous stable to the resolved release source is classified as patch or minor, with the target version and rationale approved
-- [ ] The resolved release source is the intended commit (default `origin/main`) and its existing CI is green
-- [ ] Every PR in the release range has been opened, and its full description and every linked issue have been read before drafting the changelog
-- [ ] Ensure the approved release inputs are committed locally and the git worktree is clean before running any release command
-- [ ] Ensure local `npm run typecheck` passes on that exact commit before running any release command
-- [ ] Update `CHANGELOG.md` with user-facing release notes (features, fixes — not refactors). Promotion renames the series' `## X.Y.Z-beta.N` entry to `## X.Y.Z - YYYY-MM-DD` and re-checks it covers the full release
-- [ ] Verify the changelog heading follows strict `## X.Y.Z - YYYY-MM-DD` format
-- [ ] Release preparation stayed local until the approved release command pushed the complete branch and tag
-- [ ] `npm run release:patch`, `npm run release:minor`, or `npm run release:promote` completes successfully
-- [ ] Every GitHub Actions run for the complete release commit and tag is green
-- [ ] Move npm's `beta` dist-tag to the new stable version for every published package and verify both `latest` and `beta` resolve to it
-- [ ] The GitHub Release was published only after the three stable manifests were uploaded, and it has the changelog body and every expected macOS, Linux, Windows, and Android APK asset
-- [ ] GitHub `Desktop Release` workflow for the `v*` tag is green
-- [ ] The GitHub Release contains `latest-mac.yml`, `latest-linux.yml`, and `latest.yml`
-- [ ] `latest-mac.yml` contains the current `minimumSystemVersion` guard
-- [ ] GitHub `Android APK Release` workflow for the same tag is green
-- [ ] GitHub `Docker` workflow is green and both the versioned and `latest` images are published
-- [ ] GitHub `Release Notes Sync` is green and the release body matches the stable changelog entry
-- [ ] EAS `Release Mobile` workflow for the same tag is green
-- [ ] EAS iOS `build_ios` completes for the same tag
-- [ ] EAS iOS `submit_ios` succeeds, uploading the build to App Store Connect/TestFlight
-- [ ] EAS iOS `submit_ios_for_review` succeeds, putting the build into App Store review
-- [ ] EAS Android `build_android` completes for the same tag
-- [ ] EAS Android `submit_android` succeeds, putting the build on its Play Store track
-- [ ] The release heartbeat was created after the tag push and deleted only after every item above passed

docs/rpc-namespacing.md

@@ -1,92 +0,0 @@
-# RPC Namespacing
-
-New WebSocket session RPCs use dotted names with the direction as the final segment:
-
-```ts
-checkout.forge.set_auto_merge.request;
-checkout.forge.set_auto_merge.response;
-```
-
-The namespace reads left to right:
-
-- Domain: `checkout`
-- Namespace segment: `forge`
-- Operation: `set_auto_merge`; this segment is a verb, not a noun. If you would name an RPC `noun.request`, name it `get_noun.request` instead.
-- Direction: `request` or `response`
-
-Use dots, not slashes. Dots are protocol namespaces; slashes imply paths or transport routing.
-
-## Request/Response Pairs
-
-For ordinary correlated RPCs, a `.request` has a matching `.response` with the same prefix. The daemon client may derive the response type mechanically:
-
-```ts
-checkout.forge.set_auto_merge.request;
-// -> checkout.forge.set_auto_merge.response
-```
-
-A finite streaming request can emit `.update` messages before its terminal `.response`.
-`usage.list_reports.request` uses this shape: each `.update` carries one settled report, and
-`.response` carries the request-level error or `null`. All three share `requestId`; no updates
-follow the response. An empty successful stream is an empty list. Register updates as replies
-of the originating request so source-owned delivery routes them to the requesting connection.
-
-Most new RPCs should follow these shapes. If a request does not have a one-to-one terminal response, call that out in the code near the schema.
-
-## Message Shape
-
-Requests keep their parameters at the top level:
-
-```ts
-{
-  type: "checkout.forge.set_auto_merge.request",
-  cwd: "/repo",
-  enabled: true,
-  mergeMethod: "squash",
-  requestId: "req_123"
-}
-```
-
-Responses put correlated result data under `payload`:
-
-```ts
-{
-  type: "checkout.forge.set_auto_merge.response",
-  payload: {
-    cwd: "/repo",
-    enabled: true,
-    success: true,
-    error: null,
-    requestId: "req_123"
-  }
-}
-```
-
-Keep `requestId` in both request and response payloads. It is the correlation key.
-
-## Forge Namespacing
-
-Forge-neutral behavior currently uses `checkout.forge.*` for checkout-scoped operations and `forge.search.*` for forge search; forge-specific names belong here only after schema and session handlers exist:
-
-- `checkout.forge.*` for operations whose request/response shape is genuinely
-  forge-neutral and whose implementation dispatches through the forge resolver.
-- `checkout.github.*` for existing GitHub-specific compatibility RPCs while
-  callers migrate to the neutral `checkout.forge.*` shape
-
-Do not put GitHub-specific enums or semantics into `checkout.forge.*` RPC names. A generic forge RPC should only exist when the behavior is genuinely forge-neutral.
-
-## Compatibility
-
-The existing flat RPC names remain part of the protocol until they are intentionally migrated:
-
-```ts
-checkout_pr_merge_request;
-checkout_pr_merge_response;
-```
-
-Do not add new flat names. When migrating old RPCs, keep protocol compatibility rules in mind:
-
-- Add the new names first.
-- Gate new feature behavior through `server_info.features.*` when an old host cannot support it.
-- Keep old names accepted until the compatibility window expires.
-- Mark shims with `COMPAT(...)` and a removal date.

docs/service-proxy.md

@@ -1,141 +0,0 @@
-# Service Proxy
-
-Paseo proxies HTTP traffic to services running inside your workspaces. Localhost service URLs are always enabled; optional public aliases and a separate service-only listener can be layered on through config.
-
-## How it works
-
-When a `paseo.json` script of `"type": "service"` starts, Paseo assigns it a local port and registers a route in the service proxy. Incoming requests whose `Host` header matches the script's generated hostname are forwarded to that port.
-
-The generated hostname is built from the script name, branch, and project:
-
-```
-<script>--<branch>--<project>.localhost
-```
-
-If the branch is `main` or `master`, the branch segment is omitted:
-
-```
-<script>--<project>.localhost
-```
-
-**Example:** a script named `dev` in the `miniweb` project on branch `feature/auth` would be reachable at:
-
-```
-dev--feature-auth--miniweb.localhost
-```
-
-Local and public routes use one combined leftmost label (`script--branch--project`). This keeps the hostname compatible with normal single-level wildcard DNS and TLS. If the combined label would exceed DNS's 63-character label limit, Paseo truncates it with a deterministic hash suffix to avoid collisions.
-
-## Managing workspace scripts
-
-Configured `paseo.json` scripts can be managed without addressing their backing terminal directly:
-
-```bash
-paseo script ls [--cwd <path> | --workspace <workspace-id>]
-paseo script start <name> [--cwd <path> | --workspace <workspace-id>]
-paseo script stop <name> [--cwd <path> | --workspace <workspace-id>]
-```
-
-The commands return the same script metadata shown by the workspace: lifecycle, service port, proxy URLs, health, exit code, and supervised terminal ID. `stop` terminates the managed terminal rather than only removing the proxy route, so normal script lifecycle cleanup remains authoritative. MCP exposes matching `list_workspace_scripts`, `start_workspace_script`, and `stop_workspace_script` tools; those require an explicit workspace ID.
-
-## Configuration
-
-Add a `serviceProxy` block under `daemon` in `~/.paseo/config.json`:
-
-```json
-{
-  "version": 1,
-  "daemon": {
-    "serviceProxy": {
-      "listen": "0.0.0.0:8080",
-      "publicBaseUrl": "https://paseoapps.my.domain.com"
-    }
-  }
-}
-```
-
-| Field           | Required | Description                                                                                                                                   |
-| --------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
-| `listen`        | No       | Starts a separate service-only listener at this address. If omitted, services are still reachable on the daemon listener via localhost hosts. |
-| `publicBaseUrl` | No       | Adds public service host aliases and public service links. If omitted, links use localhost addresses only.                                    |
-
-`enabled` is accepted for old configs but no longer enables a mode. `enabled: false` suppresses optional `listen`/`publicBaseUrl` layers only; localhost service proxying remains always enabled.
-
-## DNS and reverse proxy setup
-
-For generated URLs to be reachable, you need wildcard DNS pointing to the machine running the Paseo daemon.
-
-**Example:** to expose services at `https://dev--miniweb.paseoapps.my.domain.com` where the daemon host is `10.1.1.1`:
-
-1. Configure a wildcard DNS record:
-
-   ```
-   *.paseoapps.my.domain.com  →  10.1.1.1
-   ```
-
-2. Set `publicBaseUrl` to `https://paseoapps.my.domain.com` in your config.
-
-3. If you put a reverse proxy (nginx, Caddy, Traefik, etc.) in front of Paseo, point it at either the daemon listener or the optional service-only listener and ensure it forwards the `Host` header unchanged. The proxy uses the `Host` header to route requests to the correct service — rewriting it will break routing.
-
-Public service URLs expose the workspace service itself. Daemon password authentication protects daemon APIs; it does not protect proxied dev services.
-
-If the same reverse proxy serves the daemon web UI over HTTPS, it must also set `X-Forwarded-Proto` so the web UI can auto-connect with `wss://`. The daemon trusts forwarded headers from loopback proxies by default. If your proxy reaches the daemon from another address, configure the proxy ranges explicitly:
-
-```json
-{
-  "version": 1,
-  "daemon": {
-    "trustedProxies": ["loopback", "172.16.0.0/12"]
-  }
-}
-```
-
-`PASEO_TRUSTED_PROXIES` accepts the same comma-separated values, for example `loopback,172.16.0.0/12`. Use `true` only when the final trusted proxy overwrites client-supplied `X-Forwarded-*` headers.
-
-Nginx example:
-
-```nginx
-server {
-    listen 443 ssl;
-    server_name *.paseoapps.my.domain.com;
-
-    location / {
-        proxy_pass http://10.1.1.1:8080;
-        proxy_set_header Host $host;
-        proxy_set_header X-Forwarded-Proto $scheme;
-    }
-}
-```
-
-Nginx's `$host` drops the port. If you terminate on a non-default port, use `$http_host` instead so the port survives — that is what "forwards the `Host` header unchanged" means here.
-
-## Forwarded headers
-
-Paseo sets these when it forwards a request to a workspace service:
-
-| Header              | Value                                                                                                                                   |
-| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
-| `X-Forwarded-Host`  | The `Host` header verbatim, including the port when the client used one                                                                 |
-| `X-Forwarded-Proto` | The request scheme (`http` on the WebSocket upgrade path)                                                                               |
-| `X-Forwarded-For`   | The immediate peer address. Replaces any existing chain, so behind your own reverse proxy this is the proxy's address, not the client's |
-| `X-Forwarded-Port`  | The port from the `Host` header when it has one, otherwise whatever your proxy already set                                              |
-
-`X-Forwarded-Port` follows the same trust rule as `X-Forwarded-Host`: the authority Paseo observed wins. When the `Host` header carries a port, that port is reported and replaces any inbound `X-Forwarded-Port`, so a client cannot forge one. When `Host` carries no port there is nothing to observe, so a value your reverse proxy set survives untouched — that is the case where nginx's `$host` drops the port and `X-Forwarded-Port` is the only source. Paseo never derives the port from the scheme. Any other `X-Forwarded-*` header your proxy sends is passed through untouched.
-
-Services that build absolute URLs should prefer `Host` or `X-Forwarded-Host`.
-
-### The forwarded authority is not authenticated
-
-Route lookup normalizes the port away before matching a service hostname, so a client can address the daemon with any port in `Host` and still reach the service. That port is what lands in `X-Forwarded-Host` and `X-Forwarded-Port`. Paseo also does not check whether an inbound `X-Forwarded-Port` came from a proxy in `trustedProxies` — when `Host` carries no port, a client-supplied value is passed through.
-
-Treat the forwarded authority as client-influenced input. A service that builds password reset links, absolute redirects, or cached URLs from it should pin its own public origin in configuration rather than deriving one from request headers. This is not specific to `X-Forwarded-Port`: the `Host` header has always carried a client-chosen port.
-
-## Environment variables
-
-The listen address and public base URL can also be set via environment variables, which take precedence over `config.json`:
-
-| Variable                              | Description                                                               |
-| ------------------------------------- | ------------------------------------------------------------------------- |
-| `PASEO_SERVICE_PROXY_ENABLED`         | Compatibility shim; `false` suppresses optional public/listen layers only |
-| `PASEO_SERVICE_PROXY_LISTEN`          | Starts the optional service-only listener, e.g. `0.0.0.0:8080`            |
-| `PASEO_SERVICE_PROXY_PUBLIC_BASE_URL` | Adds public service aliases and links                                     |