feat: complete Forkara runtime identity break (#187)

* 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.

* chore: format identity guard

* test: keep MCP header fixture Forkara-only

* fix(brand): keep rebased runtime references canonical

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/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

@@ -2,7 +2,7 @@
 
 This document expands the provider boundary in the [canonical architecture](./architecture.md); it does not define a second ownership model. Current registry/adapters and their deterministic tests are the inventory authority.
 
-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
 

.docs/workspace-layout.md

@@ -1,10 +1,10 @@
 # Workspace layout
 
-Synara is a Bun/Turbo monorepo. Runtime ownership is split across the app workspaces, while shared schemas and cross-runtime helpers live under `packages`.
+Forkara is a Bun/Turbo monorepo. Runtime ownership is split across the app workspaces, while shared schemas and cross-runtime helpers live under `packages`.
 
-- `/apps/server` — The authoritative Synara backend and published `@forkara/cli` package. Owns orchestration/persistence, provider adapters and health/discovery, Git/worktrees, terminals, automation, workspace files, HTTP/WebSocket RPC, and the bundled web client used outside Vite development.
+- `/apps/server` — The authoritative Forkara backend and published `@forkara/cli` package. Owns orchestration/persistence, provider adapters and health/discovery, Git/worktrees, terminals, automation, workspace files, HTTP/WebSocket RPC, and the bundled web client used outside Vite development.
 - `/apps/web` — React + Vite application. Owns presentation, client transport/state coordination, chat/composer/editor/dock surfaces, and subscription-driven projection of server-authoritative state.
-- `/apps/desktop` — Electron host for the shared web client. Supervises a desktop-scoped Synara server process and provides native window, update, IPC, browser-automation, and other OS/Electron integrations.
+- `/apps/desktop` — Electron host for the shared web client. Supervises a desktop-scoped Forkara server process and provides native window, update, IPC, browser-automation, and other OS/Electron integrations.
 - `/apps/marketing` — Public marketing/download site. Kept separate from the product runtime and desktop/web application bundles.
 - `/packages/contracts` — Shared Effect Schema and TypeScript contracts for orchestration, provider/session/model data, RPC methods, settings, keybindings, automation, device/browser surfaces, and other cross-process payloads.
 - `/packages/shared` — Shared runtime utilities consumed by multiple apps/packages, including pure helpers as well as intentionally cross-runtime logging, worker, filesystem/network, and platform-boundary utilities. Uses explicit subpath exports (for example `@forkara/shared/git` and `@forkara/shared/threadWorkspace`) rather than one catch-all barrel.