merge: upstream through f4c394323 — Sidebar v2, glass redesign, Auto runtime mode

.agents/skills/redeploy/SKILL.md

@@ -20,7 +20,7 @@ Redeploys the self-hosted T3 Code server to the current `origin/main`. The logic
 
 ## CRITICAL — this session will drop
 
-This chat runs *inside* `t3code.service`. When the service restarts, **this chat's own
+This chat runs _inside_ `t3code.service`. When the service restarts, **this chat's own
 session disconnects.** That is expected and unavoidable — the deploy still finishes in the
 background. Reconnect and read the status log.
 

.agents/skills/test-t3-app/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: test-t3-app
-description: Launch and test the T3 Code web app in isolated development environments, including first-try browser authentication with one-time pairing URLs, pairing-token recovery, worktree-safe state directories, dev server lifecycle, and direct SQLite inspection or fixture seeding. Use when an agent needs to run T3 locally, test UI behavior in a browser, recover from an expired or consumed pairing token, isolate dev state, or prepare test data in state.sqlite.
+description: Launch, retain, and test the T3 Code web app in isolated development environments, including first-try browser authentication with one-time pairing URLs, pairing-token recovery, worktree-safe state directories, cross-turn dev server lifecycle, and direct SQLite inspection or fixture seeding. Use when an agent needs to run T3 locally, iteratively test UI behavior with a human, recover from an expired or consumed pairing token, isolate dev state, or prepare test data in state.sqlite.
 ---
 
 # Test T3 App
@@ -13,13 +13,35 @@ Use this skill for the web client. For iOS Simulator, Android Emulator, or physi
 2. Choose a base directory that belongs only to the current worktree or test:
    - Use the repository's ignored `.t3` directory for reusable worktree-local state.
    - Use `mktemp -d /tmp/t3code-test.XXXXXX` for disposable state and retain the printed absolute path.
-3. Start the full web stack with `vp run dev --home-dir <base-dir>`.
+3. Start the full web stack with `vp run dev`. Add `--share` when the user needs to open it from another tailnet device. In a linked worktree it defaults to that worktree's gitignored `.t3`; pass `--home-dir <base-dir>` only when the test needs a different isolated directory.
 4. Keep the terminal session alive and read the selected server port, web port, base directory, and pairing URL from its output.
 
 Treat a base directory as disposable only when it was created or deliberately selected for the current test. Never delete or directly seed the shared `~/.t3` directory. Prefer starting with a new temporary base directory over clearing state of uncertain ownership.
 
+The worktree-local default deliberately outranks an ambient `T3CODE_HOME`; do not pass the shared home through to a worktree dev server.
+
+Ports are derived from the worktree path but can shift when occupied. Always read the actual values from the `[dev-runner]` line.
+
+Shared browser dev is single-origin: Vite proxies the backend paths, so never set `VITE_HTTP_URL` or `VITE_WS_URL` for `dev`/`dev:web`.
+
 The dev runner disables browser auto-open by default. Do not pass `--browser` during automated testing: an automatically opened page can consume the one-time bootstrap token before the controlled browser uses it.
 
+### Verify a shared environment before human handoff
+
+When another person will use the printed pairing URL, first open the shared origin without the pairing path or fragment in the controlled browser and confirm the T3 Code app loads. This browser navigation is required even when curl succeeds because browsers block some otherwise reachable ports before making a network request.
+
+Do not open the other person's complete pairing URL during this reachability check; doing so consumes its one-time token. If the agent also needs an authenticated browser, create and consume a separate pairing token, then leave a fresh token for the other person.
+
+## Preserve the environment while iterating
+
+Treat the overall testing or implementation loop—not an assistant turn or one verification pass—as the environment lifecycle boundary.
+
+- Keep the dev process, base directory, selected ports, authenticated browser tab, registered projects, and seeded fixtures alive while the user may inspect the result or request follow-up changes.
+- Do not stop the server merely because one verification pass completed or because you are yielding a response to the user.
+- Before starting another environment, check whether the existing process and browser tab still serve the task. Reuse them when healthy instead of discarding useful state.
+- On a later turn, verify that the existing process is alive and reuse its printed ports and base directory. If it exited, restart with the same base directory; create a new pairing token only when the browser session is no longer valid.
+- Tell the user when a test environment remains available, including its non-secret web URL when useful. Never include a pairing token.
+
 ## Authenticate the browser on the first navigation
 
 1. Wait for the server log that says authentication is required and includes a URL ending in `/pair#token=...`.
@@ -45,7 +67,7 @@ T3CODE_PORT=<server-port> node apps/server/src/bin.ts auth pairing create \
 
 Use the `Pair URL` from this command once. Derive `<server-port>` and `<web-url>` from the current dev-runner output, including any automatically selected port offset. Setting `T3CODE_PORT` keeps the administrative CLI from probing for an unrelated free port.
 
-Always pass `--dev-url` for a dev-runner environment so the generated pairing URL uses the current web origin. An explicit base directory stores runtime state in `<base-dir>/userdata`; the `<base-dir>/dev` fallback is only used by an implicit dev home. Use `auth pairing list` to inspect active token metadata; it intentionally cannot reveal token secrets.
+Always pass `--dev-url` for a dev-runner environment so the generated pairing URL uses the current web origin. An explicit base directory stores runtime state in `<base-dir>/userdata`; the `<base-dir>/dev` fallback is only used by an implicit dev home. A worktree-local `.t3` counts as explicit, so its state lives in `<worktree>/.t3/userdata`. Use `auth pairing list` to inspect active token metadata; it intentionally cannot reveal token secrets.
 
 ## Inspect or seed SQLite state
 
@@ -58,9 +80,17 @@ Read [references/sqlite-fixtures.md](references/sqlite-fixtures.md) before chang
 
 The helper refuses to write to the shared `~/.t3` directory by default and creates a database backup before each mutation.
 
-## Finish the test
+## Tear down only when the testing loop is finished
+
+Tear down when the user explicitly asks, confirms the iteration is finished, or the overall task is genuinely complete with no pending human review. Do not infer completion from the end of an assistant turn.
+
+When teardown is appropriate:
+
+1. Stop the dev process with its terminal interrupt.
+2. Preserve the isolated base directory when it contains useful reproduction evidence or state for a likely follow-up.
+3. Otherwise remove only a path created for this test after resolving and verifying the exact target.
 
-Stop the dev process with its terminal interrupt. Preserve the isolated base directory when it contains useful reproduction evidence; otherwise remove only a path that was created for this test after resolving and verifying the exact target. A fresh isolated base directory is the safest reset when authentication, migrations, or fixture state becomes ambiguous.
+If completion is uncertain, keep the environment alive and mention that it is retained for further iteration. A fresh isolated base directory remains the safest reset when authentication, migrations, or fixture state becomes ambiguous.
 
 ## Troubleshoot predictably
 

.agents/skills/test-t3-app/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "T3 App Testing"
-  short_description: "Launch and seed isolated T3 test environments"
-  default_prompt: "Use $test-t3-app to launch an isolated T3 development environment and test it in the browser."
+  short_description: "Launch and retain isolated T3 test environments"
+  default_prompt: "Use $test-t3-app to launch an isolated T3 environment and iteratively test it in the browser while preserving state."

AGENTS.md

@@ -64,6 +64,14 @@ If a tradeoff is required, choose correctness and robustness over short-term con
 
 Long term maintainability is a core priority. If you add new functionality, first check if there is shared logic that can be extracted to a separate module. Duplicate logic across multiple files is a code smell and should be avoided. Don't be afraid to change existing code. Don't take shortcuts by just adding local logic to solve a problem.
 
+## Dev Servers
+
+- In a linked git worktree, dev state defaults to that worktree's gitignored `.t3`. This deliberately outranks an ambient `T3CODE_HOME`, which could otherwise select the installed app's live `~/.t3/userdata` database. An explicit `--home-dir` still wins.
+- Start the web stack with `vp run dev`. Add `--share` when someone needs to open it from another device on the tailnet.
+- Browser dev is single-origin: Vite proxies `/api`, `/ws`, `/oauth`, and `/.well-known` to the backend. Do not set `VITE_HTTP_URL` or `VITE_WS_URL` for `dev`/`dev:web`.
+- Worktree paths supply stable preferred port offsets. Read the actual server and web ports from the `[dev-runner]` line because occupied ports can still shift them.
+- Before handing off a `--share` URL, open its origin in a controlled browser and confirm the app loads. A successful curl is insufficient because browsers reject some otherwise reachable ports.
+
 ## Package Roles
 
 - `apps/server`: Node.js WebSocket server. Wraps Codex app-server (JSON-RPC over stdio), serves the React web app, and manages provider sessions.
@@ -86,6 +94,31 @@ sessions T3 itself spawned are skipped (`skipped-owned` — session id found in
 worktrees dir; `skipped-copy` — a forkSession copy whose message uuids largely already live on
 another thread), and deleted imported threads stay deleted via the event-log tombstone.
 
+## Upstream sync PRs: NEVER squash-merge
+
+Sync PRs (`merge: upstream through <sha>`) must land as a **merge commit** or a
+fast-forward push (`git push origin HEAD:refs/heads/main`). Never squash-merge,
+never rebase-merge, never `git revert -m 1`.
+
+Squash-merging discards the second parent, so git stops believing upstream is an
+ancestor. PR #42 was squash-merged and the next sync's conflict set went from
+18 files / 40 hunks to **76 files / 238 hunks** — a 4x tax paid for one wrong
+click, plus an inflated 208-commit delta when only 79 commits were actually new.
+Rebase-merge cannot replay merge commits at all. `git revert -m 1` is the same
+class of trap: ancestry keeps claiming upstream is merged while the content is
+gone, so a later `git merge upstream/main` never restores the reverted files.
+
+If it happens anyway, it is repairable while the PR branch still exists on
+GitHub (the repo has `delete_branch_on_merge:false`): re-merge that branch with
+`git merge --no-ff origin/t3code/<branch>`. The tree is unchanged and the
+upstream parent is restored.
+
+After landing a sync, assert the repair held:
+
+```
+git merge-base origin/main upstream/main   # must be the SHA you merged, not an older one
+```
+
 ## Finishing a feature: MANDATORY test-deploy + PR flow
 
 When a feature or bugfix is complete in a `t3code/*` worktree, do NOT merge to `main`. Follow **[docs/test-deployments.md](docs/test-deployments.md)**: open a PR, deploy the branch to a test port from the pool (`node scripts/test-deploy.ts --pr <url> --note "<desc>" --comment`), and comment the test URL on the PR so the user can jump straight into the running instance. Prod (external `7443` / loopback `3773` / unit `t3code.service`) is only redeployed from `main` after the user approves the PR — and `t3code.service` is never restarted without explicit user approval in the conversation. The scripts refuse all prod targets; never work around the guard.

README.md

@@ -117,6 +117,8 @@ There's no public docs site yet, checkout the miscellaneous markdown files in [d
 ## Documentation
 
 - [Getting started](./docs/getting-started/quick-start.md)
+- [Remote access](./docs/user/remote-access.md)
+- [Keeping T3 Code in sync](./docs/user/server-updates.md)
 - [Architecture overview](./docs/architecture/overview.md)
 - [Provider guides](./docs/providers/codex.md)
 - [Operations](./docs/operations/ci.md)