feat: complete Forkara runtime identity break

Move runtime, packaging, protocol, and release identities to Forkara and add a verified copy-only legacy profile import boundary.

Author: redxzeta

.claude/skills/verify/SKILL.md

@@ -1,13 +1,13 @@
-# Verify: run Synara locally for runtime verification
+# Verify: run Forkara locally for runtime verification
 
-How to launch an isolated Synara instance (server + web) to observe UI changes, without touching `~/.synara` or the default dev ports.
+How to launch an isolated Forkara instance (server + web) to observe UI changes, without touching `~/.forkara` or the default dev ports.
 
 ## Launch
 
 ```bash
 # 1. Server (from the directory you want as the workspace/project cwd):
-SYNARA_HOME=<scratch>/synara-home \
-SYNARA_PORT=3899 SYNARA_MODE=web SYNARA_NO_BROWSER=1 \
+FORKARA_HOME=<scratch>/forkara-home \
+FORKARA_PORT=3899 FORKARA_MODE=web FORKARA_NO_BROWSER=1 \
 VITE_DEV_SERVER_URL=http://localhost:5899 \
 bun <repo>/apps/server/src/index.ts &
 

.docs/architecture.md

@@ -1,12 +1,12 @@
 # Architecture
 
-Synara is a local-first orchestration application with three main runtime surfaces:
+Forkara is a local-first orchestration application with three main runtime surfaces:
 
 - the React web client in `apps/web`;
 - the server/runtime in `apps/server`;
 - the Electron desktop shell in `apps/desktop`.
 
-The server owns durable orchestration, provider sessions, Git/worktree state, terminals, automation, device/browser integrations, and the typed HTTP/WebSocket RPC surface. Provider-native protocols stay behind adapter boundaries; the web app consumes Synara contracts rather than talking to coding-agent CLIs directly.
+The server owns durable orchestration, provider sessions, Git/worktree state, terminals, automation, device/browser integrations, and the typed HTTP/WebSocket RPC surface. Provider-native protocols stay behind adapter boundaries; the web app consumes Forkara contracts rather than talking to coding-agent CLIs directly.
 
 ```text
 ┌──────────────────────────────────────────────┐
@@ -124,7 +124,7 @@ Provider-specific session ids, process lifecycle, wire formats, model discovery,
 
 ## Persistence and local resources
 
-Synara's server owns the local durable state and resource lifecycles:
+Forkara's server owns the local durable state and resource lifecycles:
 
 - SQLite persistence and projections under `apps/server/src/persistence`;
 - managed Git/worktree operations under `apps/server/src/git` and checkpointing/orchestration services;
@@ -136,7 +136,7 @@ This ownership is why the web client can reload or reconnect without becoming th
 
 ## Desktop shell
 
-`apps/desktop` is a native host, not a second orchestration implementation. It supervises a desktop-scoped Synara backend, loads the shared web UI, and provides OS/Electron integrations such as window lifecycle, native menus/shortcuts, updates, and platform-specific bridges.
+`apps/desktop` is a native host, not a second orchestration implementation. It supervises a desktop-scoped Forkara backend, loads the shared web UI, and provides OS/Electron integrations such as window lifecycle, native menus/shortcuts, updates, and platform-specific bridges.
 
 Browser/web mode and desktop mode therefore share the same server contracts and most UI code.
 
@@ -149,7 +149,7 @@ For orchestration state, the client uses two principal subscription shapes:
 - a lightweight shell stream for projects/thread summaries and application-level navigation state;
 - scoped thread-detail streams for full conversation/activity state.
 
-Streams support snapshot/replay recovery and client-side sequence fences. A late query or replay must not roll the client behind a newer live sequence; when recovery cannot be proven safe, Synara prefers a fresh snapshot.
+Streams support snapshot/replay recovery and client-side sequence fences. A late query or replay must not roll the client behind a newer live sequence; when recovery cannot be proven safe, Forkara prefers a fresh snapshot.
 
 ## Design rules
 

.docs/ci.md

@@ -6,7 +6,7 @@
 
 `Format, Lint, Typecheck, Test, Browser Test, Build` runs on Ubuntu and blocks on:
 
-- Synara identity/brand validation;
+- Forkara identity/brand validation;
 - `bun run fmt:check`;
 - `bun run lint`;
 - `bun run typecheck`;

.docs/codex-prerequisites.md

@@ -1,5 +1,5 @@
 # Codex prerequisites
 
 - Install Codex CLI so `codex` is on your PATH.
-- Authenticate Codex before running Synara (for example via API key or ChatGPT auth supported by Codex).
-- Synara starts the server via `codex app-server` per session.
+- Authenticate Codex before running Forkara (for example via API key or ChatGPT auth supported by Codex).
+- Forkara starts the server via `codex app-server` per session.

.docs/encyclopedia.md

@@ -1,6 +1,6 @@
 # Encyclopedia
 
-This is a living glossary for Synara. It explains what common terms mean in this codebase.
+This is a living glossary for Forkara. It explains what common terms mean in this codebase.
 
 ## Table of contents
 

.docs/provider-architecture.md

@@ -1,6 +1,6 @@
 # Provider architecture
 
-Synara treats provider integrations as adapters behind server-owned orchestration and discovery boundaries. The web app does not talk to Codex, Claude, Cursor, or another coding-agent runtime directly: provider operations enter the server through the typed contracts in `@forkara/contracts`. Session and turn lifecycle calls route through `ProviderService`; model, agent, skill, command, and plugin discovery routes through `ProviderDiscoveryService`; both ultimately resolve concrete `ProviderAdapter` implementations from the registry. Voice operations may access the registry directly where the provider capability is itself the boundary.
+Forkara treats provider integrations as adapters behind server-owned orchestration and discovery boundaries. The web app does not talk to Codex, Claude, Cursor, or another coding-agent runtime directly: provider operations enter the server through the typed contracts in `@forkara/contracts`. Session and turn lifecycle calls route through `ProviderService`; model, agent, skill, command, and plugin discovery routes through `ProviderDiscoveryService`; both ultimately resolve concrete `ProviderAdapter` implementations from the registry. Voice operations may access the registry directly where the provider capability is itself the boundary.
 
 ## Implemented providers
 

.docs/quick-start.md

@@ -12,7 +12,7 @@ bun run dev
 bun run dev:desktop
 
 # Desktop development on an isolated port set
-SYNARA_DEV_INSTANCE=feature-xyz bun run dev:desktop
+FORKARA_DEV_INSTANCE=feature-xyz bun run dev:desktop
 ```
 
 ## Production-style local run
@@ -37,10 +37,10 @@ bun run dist:desktop:win
 
 ## Published CLI package
 
-The server package is published as `@forkara/cli` and exposes the `synara` executable. To run an npm-published version without installing it globally:
+The server package is published as `@forkara/cli` and exposes the `forkara` executable. To run an npm-published version without installing it globally:
 
 ```bash
-npx --yes --package=@forkara/cli synara --help
+npx --yes --package=@forkara/cli forkara --help
 ```
 
 For repository scripts, release packaging, and multi-instance development details, see [scripts.md](./scripts.md).

.docs/runtime-modes.md

@@ -1,6 +1,6 @@
 # Runtime modes
 
-Synara exposes three runtime modes in the permission picker:
+Forkara exposes three runtime modes in the permission picker:
 
 - **Supervised**: asks the user before protected actions. Codex uses
   `approvalPolicy: untrusted`, `sandbox: read-only`, and

.docs/scripts.md

@@ -3,9 +3,9 @@
 - `bun run dev` — Starts contracts, server, and web in `turbo watch` mode.
 - `bun run dev:server` — Starts just the WebSocket server (uses Bun TypeScript execution).
 - `bun run dev:web` — Starts just the Vite dev server for the web app.
-- Dev commands default `SYNARA_HOME` to `~/.synara`, which keeps dev state under `~/.synara/dev`.
+- Dev commands default `FORKARA_HOME` to `~/.forkara`, which keeps dev state under `~/.forkara/dev`.
 - Override server CLI-equivalent flags from root dev commands with `--`, for example:
-  `bun run dev -- --home-dir ~/.synara-2`
+  `bun run dev -- --home-dir ~/.forkara-2`
 - `bun run start` — Runs the production server (serves built web app as static files).
 - `bun run build` — Builds contracts, web app, and server through Turbo.
 - `bun run typecheck` — Strict TypeScript checks for all packages.
@@ -20,8 +20,8 @@
 
 - Default local builds are unsigned/not notarized unless `--signed` is supplied with the required platform credentials.
 - Production icon sources are centralized in `scripts/lib/brand-assets.ts`. The current macOS source is `assets/prod/black-macos-1024.png` (with the legacy macOS variant alongside it); do not hard-code a separate packaging icon path in docs or scripts.
-- Desktop production windows load the bundled UI from `synara://app/index.html` (not a `127.0.0.1` document URL).
-- Desktop packaging includes `apps/server/dist` (the `synara` backend) and starts it on loopback with an auth token for WebSocket/API traffic.
+- Desktop production windows load the bundled UI from `forkara://app/index.html` (not a `127.0.0.1` document URL).
+- Desktop packaging includes `apps/server/dist` (the `forkara` backend) and starts it on loopback with an auth token for WebSocket/API traffic.
 - Your tester can still open an unsigned local macOS build by right-clicking the app and choosing **Open** on first launch.
 - To keep staging files for debugging package contents, run: `bun run dist:desktop:dmg -- --keep-stage`.
 - To enable code-signing/notarization when the required credentials are configured, add `--signed`.
@@ -35,10 +35,10 @@
 
 ## Running multiple dev instances
 
-Set `SYNARA_DEV_INSTANCE` to any value to deterministically shift all dev ports together.
+Set `FORKARA_DEV_INSTANCE` to any value to deterministically shift all dev ports together.
 
 - Default ports: server `3773`, web `5733`
-- Shifted ports: `base + offset` (offset is hashed from `SYNARA_DEV_INSTANCE`)
-- Example: `SYNARA_DEV_INSTANCE=branch-a bun run dev:desktop`
+- Shifted ports: `base + offset` (offset is hashed from `FORKARA_DEV_INSTANCE`)
+- Example: `FORKARA_DEV_INSTANCE=branch-a bun run dev:desktop`
 
-If you want full control instead of hashing, set `SYNARA_PORT_OFFSET` to a numeric offset.
+If you want full control instead of hashing, set `FORKARA_PORT_OFFSET` to a numeric offset.

.docs/transport.md

@@ -2,7 +2,7 @@
 
 How the browser and server talk: connect negotiation, WebSocket compression, and static asset delivery.
 
-Synara's transport was originally built for localhost, where bandwidth is free and latency is negligible. The mechanisms below exist because neither holds over a real network — they are also what makes running a session against a remote host practical.
+Forkara's transport was originally built for localhost, where bandwidth is free and latency is negligible. The mechanisms below exist because neither holds over a real network — they are also what makes running a session against a remote host practical.
 
 ## Connect negotiation