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

[DanielGGordon]

Merges 79 new upstream commits since the 6f34ad3e8 cut point. Three commits: an ancestry graft, the resolved merge, and docs.

⚠️ Merge this with "Create a merge commit" — not squash

Squash-merging PR #42 is what caused most of the work in this PR. It discards the second parent, so git stopped believing upstream was an ancestor and merge-base fell back to 2026-07-07. Measured cost: 76 conflicted files / 238 hunks instead of 18 / 40, plus an inflated 208-commit delta when only 79 were new.

Commit 7c1b9f62a repairs it by re-merging PR #42's original merge commit (still on GitHub as origin/t3code/upstream-sidebar-change). Its diff is empty — it only restores provenance. Squashing this PR throws that away again. A rule is now in AGENTS.md.

After merging, please verify: git merge-base origin/main upstream/main should print f4c394323, not dad088976.

Blocker resolved: migration ledger

Upstream shipped 033_ProjectionThreadsSettled + 034_ProjectionThreadsSnoozed. This fork already owns id 33, recorded in production's ledger since 2026-07-09. Effect's Migrator skips any id <= the recorded max with no name comparison, so renumbering ours upward would mean upstream's 33 never runs, the settled columns are never created, and the auto-merged ProjectionThreads.ts queries fail on every thread read — a full outage that CI and every fresh-DB test-deploy pass green.

Resolution: we keep 33; upstream's two are renumbered to 034/035. Zero DB surgery. Every future sync re-applies the offset until the ensureForkSchema follow-up lands.

Owner decisions applied

Decision	Applied
Migrations	Fork keeps 33, upstream offset to 034/035
Auto runtime mode	Merged but gated behind Settings → Features (default off)
Merge method	Documented rule; land this via merge commit or ff-push
Color schemes	Culled to Solarized only
Sidebar	All fork sidebar work dropped except the CPU/memory readout

Sidebar

Only the host-stats readout survives, and it moved into the shared sidebar/SidebarChrome.tsx — so it now renders in both v1 and the v2 beta, where it was previously v1-only. Upstream's extraction had no host-stats slot, so taking their side would have silently deleted the mount.

Dropped: sidebarChatListView, boxed project cards, the restart-request sidebar pill. The restart-request feature itself is untouched — only its sidebar affordance is gone. Sidebar v2 ships default OFF.

Things git would not have flagged

• ClaudeAdapter.ts auto-merged with no conflict, so our case "claude-opus-5": return 1_000_000 hack survived and would have silently overridden upstream's new 200k/1M contextWindow descriptor. Deleted explicitly. PR feat(claude): add Claude Opus 5 to built-in models #44 is retired for upstream's 41a430a88, which is a strict superset — ours reused Fable 5's 2.1.169 gate instead of Opus 5's 2.1.219, and advertised 1M while sending 200k.
• index.css: both sides of the one conflict are +1 brace depth sharing a } past the marker. Naive union does not build. Second time this trap has appeared.
• Upstream's [data-sidebar-version] block hard-codes ten generic color tokens and applies even with the beta off. Element-scoped properties beat :root[data-scheme], so it would have killed Solarized inside the whole sidebar. Stripped to the --sidebar-* family.
• ProviderCommandReactor: taking upstream's side broke 7 deferred-recycle tests. Upstream added an eager threadModelSelections write at turn start; the fork's deferred model-change recycle compares against that map, so the eager write makes every pending recycle look already applied. Upstream's pendingTurnStart flag kept, the write dropped.

Merged but gated / must-not-run

• t3 service install/uninstall must never run on the deploy host — it hard-codes t3code.service and would overwrite the hand-written production unit. A reference copy is now committed at deploy/t3code.service.
• Server self-update audited as inert here (capability is null under systemd, and prod runs a source checkout).
• State-directory resolution is unchanged for production t3 serve — verified against deriveServerPaths/resolveBaseDir. No DB-orphaning risk.

Verification

• tsgo --noEmit clean: contracts, client-runtime, server, web, desktop
• @t3tools/web build passes (the check that catches the CSS trap)
• 5724 tests pass. Remaining failures reproduce on origin/main and are not from this merge: 17 desktop suites (Electron binary absent on this headless host) and server.test.ts > preserves structured workspace rpc failures.

Follow-ups (not in this PR)

1. ensureForkSchema seam — closes the migration-offset hole permanently, including a stock-created DB recording 33 as upstream's migration. Must account for t3-claude-import.timer running a second migrating process against the same DB.
2. scripts/test-deploy-lib.ts pins PRUNE_SCHEMA_VERSION = 32 while prod is at 33 — the default curated seed has been silently falling back since 2026-07-09.
3. Cull useComposerProjectSkills (upstream now probes skills server-side); give ProjectionThread.requestingRestart a decoding default.

Rollback procedure: docs/operations/rollback-2026-07-27-sync.md. The one-way door is Auto runtime mode — hence the gate.

🤖 Generated with Claude Code

[DanielGGordon]

Test deployment

Slot: external 7446 ⇄ loopback 3776. Branch t3code/upstream-sync-2026-07-27, seeded with the curated template.

External URL verified reachable (HTTP 200). Pairing links are one-time and expire in ~1h — mint a fresh one with:

node scripts/test-status.ts --pair 7446 --base-url https://<SERVER_IP>:7446

Migration rehearsal — the point of this deploy

The curated seed template was stale (built 2026-07-09, ledger max 32) because PRUNE_SCHEMA_VERSION was pinned at 32 while prod reached 33. That is fixed in this PR, and the template was republished from prod at schema 33 — so this slot reproduces production's actual migration high-water mark rather than a fresh database.

Result after boot:

35 | ProjectionThreadsSnoozed
34 | ProjectionThreadsSettled
33 | ProjectionThreadRestartRequest

All six columns present: requesting_restart, restart_request_reason, settled_override, settled_at, snoozed_until, snoozed_at.

This is the exact scenario that would have failed silently had the fork's migration been renumbered upward instead of upstream's. It is also covered permanently by 034_035_ForkMigrationOffset.test.ts, which was negative-tested: it fails when the numbering is inverted and passes on this arrangement.

Seed safety

Verified before boot — the template's projection_projects.workspace_root is uniformly the curated sandbox, and 0 threads carry a worktree_path. No agent can spawn in a real repo from this slot.

Note on the deploy script output

test-deploy.ts printed the degraded/tunnel-mode banner, but that is a false negative: it probes https://127.0.0.1:<port>, where TLS SNI does not match Caddy's cert. Both the pool slot and prod's 7443 return 200 on the public interface. Worth fixing in the test-deploy follow-up.

What to look at

• Sidebar renders in v1 (upstream default) with your CPU/memory readout in the footer — it now lives in the shared chrome, so it should also appear if you flip Settings → Beta → Sidebar v2.
• Settings → Features → Auto runtime mode is off; the composer's access picker should show only Supervised / Auto-accept edits / Full access until you enable it.
• Settings → Appearance: Color scheme now offers Default and Solarized only. Check the sidebar is themed in Solarized rather than falling back to upstream's zinc.