Add preferred Pi model settings and pickers

.devcontainer/devcontainer.json

@@ -1,5 +1,5 @@
 {
-  "name": "T3 Code Dev",
+  "name": "Workbench Dev",
   "image": "debian:bookworm",
   "features": {
     "ghcr.io/devcontainers-extra/features/bun:1": {},

.docs/architecture.md

@@ -1,6 +1,6 @@
 # Architecture
 
-T3 Code runs as a **Node.js WebSocket server** that wraps `codex app-server` (JSON-RPC over stdio) and serves a React web app.
+Workbench runs as a **Node.js WebSocket server** that wraps `codex app-server` (JSON-RPC over stdio) and serves a React web app.
 
 ```
 ┌─────────────────────────────────┐

.docs/codex-prerequisites.md

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

.docs/encyclopedia.md

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

.docs/remote-architecture.md

@@ -1,14 +1,14 @@
 # Remote Architecture
 
-This document describes the target architecture for first-class remote environments in T3 Code.
+This document describes the target architecture for first-class remote environments in Workbench.
 
 It is intentionally architecture-first. It does not define a complete implementation plan or user-facing rollout checklist. The goal is to establish the core model so remote support can be added without another broad rewrite.
 
 ## Goals
 
 - Treat remote environments as first-class product primitives, not special cases.
 - Support multiple ways to reach the same environment.
-- Keep the T3 server as the execution boundary.
+- Keep the Workbench server as the execution boundary.
 - Let desktop, mobile, and web all share the same conceptual model.
 - Avoid introducing a local control plane unless product pressure proves it is necessary.
 
@@ -21,7 +21,7 @@ It is intentionally architecture-first. It does not define a complete implementa
 
 ## High-level architecture
 
-T3 already has a clean runtime boundary: the client talks to a T3 server over HTTP/WebSocket, and the server owns orchestration, providers, terminals, git, and filesystem operations.
+Workbench already has a clean runtime boundary: the client talks to a Workbench server over HTTP/WebSocket, and the server owns orchestration, providers, terminals, git, and filesystem operations.
 
 Remote support should preserve that boundary.
 
@@ -44,10 +44,10 @@ Remote support should preserve that boundary.
 │ - desktop-managed ssh bootstrap + forward   │
 └───────────────┬──────────────────────────────┘
                 │
-                │ connects to one T3 server
+                │ connects to one Workbench server
                 │
 ┌───────────────▼──────────────────────────────┐
-│ Execution environment = one T3 server       │
+│ Execution environment = one Workbench server       │
 │                                              │
 │ - environment identity                       │
 │ - provider state                             │
@@ -56,13 +56,13 @@ Remote support should preserve that boundary.
 └──────────────────────────────────────────────┘
 ```
 
-The important decision is that remoteness is expressed at the environment connection layer, not by splitting the T3 runtime itself.
+The important decision is that remoteness is expressed at the environment connection layer, not by splitting the Workbench runtime itself.
 
 ## Domain model
 
 ### ExecutionEnvironment
 
-An `ExecutionEnvironment` is one running T3 server instance.
+An `ExecutionEnvironment` is one running Workbench server instance.
 
 It is the unit that owns:
 
@@ -128,7 +128,7 @@ That means:
 
 Access methods answer one question:
 
-How does the client speak WebSocket to a T3 server?
+How does the client speak WebSocket to a Workbench server?
 
 They do not answer:
 
@@ -149,7 +149,7 @@ Benefits:
 
 - works for desktop, mobile, and web
 - no client-specific process management required
-- best fit for hosted or self-managed remote T3 deployments
+- best fit for hosted or self-managed remote Workbench deployments
 
 ### 2. Tunneled WebSocket access
 
@@ -161,7 +161,7 @@ Examples:
 
 This is still direct WebSocket access from the client's perspective. The difference is that the route is mediated by a tunnel or relay.
 
-For T3, tunnels are best modeled as another `AccessEndpoint`, not as a different kind of environment.
+For Workbench, tunnels are best modeled as another `AccessEndpoint`, not as a different kind of environment.
 
 This is especially useful when:
 
@@ -178,7 +178,7 @@ The desktop main process can use SSH to:
 
 - reach a machine
 - probe it
-- launch or reuse a remote T3 server
+- launch or reuse a remote Workbench server
 - establish a local port forward
 
 After that, the renderer should still connect using an ordinary WebSocket URL against the forwarded local port.
@@ -189,15 +189,15 @@ This keeps the renderer transport model consistent with every other access metho
 
 Launch methods answer a different question:
 
-How does a T3 server come to exist on the target machine?
+How does a Workbench server come to exist on the target machine?
 
 Launch and access should stay separate in the design.
 
 ### 1. Pre-existing server
 
 The simplest launch method is no launch at all.
 
-The user or operator already runs T3 on the target machine, and the client connects through a direct or tunneled WebSocket endpoint.
+The user or operator already runs Workbench on the target machine, and the client connects through a direct or tunneled WebSocket endpoint.
 
 This should be the first remote mode shipped because it validates the environment model with minimal extra machinery.
 
@@ -213,23 +213,23 @@ Useful ideas to borrow from Zed:
 - reconnect-friendly launcher behavior
 - desktop-owned connection UX
 
-What should be different in T3:
+What should be different in Workbench:
 
 - no custom stdio/socket proxy protocol between renderer and remote runtime
 - no attempt to make the remote runtime look like an editor transport
 - keep the final client-to-server connection as WebSocket
 
-The recommended T3 flow is:
+The recommended Workbench flow is:
 
 1. Desktop connects over SSH.
-2. Desktop probes the remote machine and verifies T3 availability.
-3. Desktop launches or reuses a remote T3 server.
+2. Desktop probes the remote machine and verifies Workbench availability.
+3. Desktop launches or reuses a remote Workbench server.
 4. Desktop establishes local port forwarding.
 5. Renderer connects to the forwarded WebSocket endpoint as a normal environment.
 
 ### 3. Client-managed local publish
 
-This is the inverse of remote launch: a local T3 server is already running, and the client publishes it through a tunnel.
+This is the inverse of remote launch: a local Workbench server is already running, and the client publishes it through a tunnel.
 
 This is useful for:
 
@@ -244,7 +244,7 @@ These concerns are easy to conflate, but separating them prevents architectural
 
 Examples:
 
-- A manually hosted T3 server might be reached through direct `wss`.
+- A manually hosted Workbench server might be reached through direct `wss`.
 - The same server might also be reachable through a tunnel.
 - An SSH-managed server might be launched over SSH but then reached through forwarded WebSocket.
 - A local desktop server might be published through a tunnel for mobile.
@@ -263,7 +263,7 @@ That means:
 - tunnel exposure should not rely on obscurity
 - client-saved endpoints should carry enough auth metadata to reconnect safely
 
-T3 already supports a WebSocket auth token on the server. That should become a first-class part of environment access rather than remaining an incidental query parameter convention.
+Workbench already supports a WebSocket auth token on the server. That should become a first-class part of environment access rather than remaining an incidental query parameter convention.
 
 For publicly reachable environments, authenticated access should be treated as required.
 
@@ -282,14 +282,14 @@ The important mismatch is transport shape.
 
 Zed needs a custom proxy/server protocol because its remote boundary sits below the editor and project runtime.
 
-T3 should not copy that part.
+Workbench should not copy that part.
 
-T3 already has the right runtime boundary:
+Workbench already has the right runtime boundary:
 
-- one T3 server per environment
+- one Workbench server per environment
 - ordinary HTTP/WebSocket between client and environment
 
-So T3 should borrow Zed's launch discipline, not its transport protocol.
+So Workbench should borrow Zed's launch discipline, not its transport protocol.
 
 ## Recommended rollout
 

.docs/runtime-modes.md

@@ -1,6 +1,6 @@
 # Runtime modes
 
-T3 Code has a global runtime mode switch in the chat toolbar:
+Workbench has a global runtime mode switch in the chat toolbar:
 
 - **Full access** (default): starts sessions with `approvalPolicy: never` and `sandboxMode: danger-full-access`.
 - **Supervised**: starts sessions with `approvalPolicy: on-request` and `sandboxMode: workspace-write`, then prompts in-app for command/file approvals.

.docs/scripts.md

@@ -21,7 +21,7 @@
 - Default build is unsigned/not notarized for local sharing.
 - The DMG build uses `assets/macos-icon-1024.png` as the production app icon source.
 - Desktop production windows load the bundled UI from `t3://app/index.html` (not a `127.0.0.1` document URL).
-- Desktop packaging includes `apps/server/dist` (the `t3` backend) and starts it on loopback with an auth token for WebSocket/API traffic.
+- Desktop packaging includes `apps/server/dist` (the `workbench` backend) and starts it on loopback with an auth token for WebSocket/API traffic.
 - Your tester can still open it on macOS 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 allow code-signing/notarization when configured in CI/secrets, add: `--signed`.

.github/workflows/release.yml

@@ -140,7 +140,7 @@ jobs:
             echo "release_channel=stable" >> "$GITHUB_OUTPUT"
             echo "version=$version" >> "$GITHUB_OUTPUT"
             echo "tag=v$version" >> "$GITHUB_OUTPUT"
-            echo "name=T3 Code v$version" >> "$GITHUB_OUTPUT"
+            echo "name=Workbench v$version" >> "$GITHUB_OUTPUT"
             echo "cli_dist_tag=latest" >> "$GITHUB_OUTPUT"
             if [[ "$version" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
               echo "is_prerelease=false" >> "$GITHUB_OUTPUT"
@@ -381,7 +381,7 @@ jobs:
         run: node scripts/update-release-package-versions.ts "${{ needs.preflight.outputs.version }}"
 
       - name: Build CLI package
-        run: bun run build --filter=@t3tools/web --filter=t3
+        run: bun run build --filter=@workbench/web --filter=workbench
 
       - name: Publish CLI package
         run: node apps/server/scripts/cli.ts publish --tag "${{ needs.preflight.outputs.cli_dist_tag }}" --app-version "${{ needs.preflight.outputs.version }}" --verbose

.gitignore

@@ -22,3 +22,9 @@ apps/web/src/components/__screenshots__
 __screenshots__/
 .tanstack
 squashfs-root/
+
+# Atelier runtime state (server persistence / worktrees / nested upstream copy)
+apps/server/userdata/
+apps/server/worktrees/
+apps/server/caches/
+workbench-src/