Merge upstream: Auto runtime mode, t3.json config, glass-surface redesign - #8
Conversation
Co-authored-by: codex <codex@users.noreply.github.com>
…tgg#4276) Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
…laude (pingdotgg#4272) Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
- Restore light-mode glass, dialog, dropdown, and composer colors - Refine provider wizard, changed-file cards, sidebar controls, and buttons - Update wizard step tests for the new list structure
Co-authored-by: codex <codex@users.noreply.github.com>
Uh oh!
There was an error while loading. Please reload this page.
Records upstream/main (4d83436) as merged. Its content already landed in main via the squash-merge of #8; this commit only restores git ancestry so the fork stays 'fully merged' and future upstream merges don't re-present these commits. No file changes (tree identical to origin/main). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
| updateSettings({ glassOpacity }); | ||
| } | ||
| }} | ||
| step={5} |
There was a problem hiding this comment.
🟡 Mediumsettings/SettingsPanels.tsx:613
The glass opacity slider uses step={5}, but the settings contract accepts every integer from MIN_GLASS_OPACITY through MAX_GLASS_OPACITY. For a valid persisted value like 72, the range input has a step-mismatched value — the browser may render the thumb at the nearest valid step (e.g. 70), while the adjacent output and custom fill are calculated from 72. The next interaction can then overwrite the valid 72 with the rounded value. Consider using step={1} so the slider can represent every valid value, or restrict the schema to multiples of five.
| step={5} | |
| step={1} |
🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @apps/web/src/components/settings/SettingsPanels.tsx around line 613:
The glass opacity slider uses `step={5}`, but the settings contract accepts every integer from `MIN_GLASS_OPACITY` through `MAX_GLASS_OPACITY`. For a valid persisted value like `72`, the range input has a step-mismatched value — the browser may render the thumb at the nearest valid step (e.g. `70`), while the adjacent output and custom fill are calculated from `72`. The next interaction can then overwrite the valid `72` with the rounded value. Consider using `step={1}` so the slider can represent every valid value, or restrict the schema to multiples of five.
| "scripts": [ | ||
| { | ||
| "name": "Setup Worktree", | ||
| "command": "vp i && ln -sf $T3CODE_PROJECT_ROOT/.env .env && ln -sf $T3CODE_PROJECT_ROOT/infra/relay/.env infra/relay/.env", |
There was a problem hiding this comment.
🟡 Mediumt3.json:7
The Setup Worktree command expands $T3CODE_PROJECT_ROOT without quotes in both ln source paths. If the project root contains spaces, shell word splitting passes multiple operands to ln, so the first link fails and, due to &&, neither .env link is created. Quote each expanded source path, e.g. "$T3CODE_PROJECT_ROOT/.env".
| "command": "vp i && ln -sf $T3CODE_PROJECT_ROOT/.env .env && ln -sf $T3CODE_PROJECT_ROOT/infra/relay/.env infra/relay/.env", | |
| vp i && ln -sf "$T3CODE_PROJECT_ROOT/.env" .env && ln -sf "$T3CODE_PROJECT_ROOT/infra/relay/.env" infra/relay/.env |
🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @t3.json around line 7:
The `Setup Worktree` command expands `$T3CODE_PROJECT_ROOT` without quotes in both `ln` source paths. If the project root contains spaces, shell word splitting passes multiple operands to `ln`, so the first link fails and, due to `&&`, neither `.env` link is created. Quote each expanded source path, e.g. `"$T3CODE_PROJECT_ROOT/.env"`.
| return currentIndex < threadIds.length - 1 ? (threadIds[currentIndex + 1] ?? null) : null; | ||
| } | ||
| export function shouldNavigateAfterProjectRemoval(input: { |
There was a problem hiding this comment.
🟡 Mediumcomponents/Sidebar.logic.ts:381
shouldNavigateAfterProjectRemoval returns false for a server route whose thread was added to the project after the projectThreads snapshot was captured — for example, a thread synced while the delete confirmation is pending. After the project is actually removed, the UI stays on that route instead of navigating away, because the thread's environmentId/id match the current route but were not present in the stale snapshot. Consider computing project ownership from current thread state at call time (after the await), or retaining the removed project id and comparing it against the route's project rather than relying on the pre-removal thread list.
🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @apps/web/src/components/Sidebar.logic.ts around line 381:
`shouldNavigateAfterProjectRemoval` returns `false` for a server route whose thread was added to the project after the `projectThreads` snapshot was captured — for example, a thread synced while the delete confirmation is pending. After the project is actually removed, the UI stays on that route instead of navigating away, because the thread's `environmentId`/`id` match the current route but were not present in the stale snapshot. Consider computing project ownership from current thread state at call time (after the await), or retaining the removed project id and comparing it against the route's project rather than relying on the pre-removal thread list.
| const api = readLocalApi(); | ||
| if (!api) return; | ||
| const projectThreads = threads.filter( |
There was a problem hiding this comment.
🟠 Highcomponents/SidebarV2.tsx:854
handleRemoveProject filters threads (live shells only) to compute projectThreads, then shows the user a confirmation dialog saying exactly projectThreads.length thread histories will be deleted. But the deleteProject call passes force: true, which makes the server delete all threads in the project including archived ones. Archived threads are not in the live shell list, so the dialog undercounts: it says "delete its 1 thread" while the server actually deletes every archived history too. Consider counting archived threads for the project (or wording the confirmation to account for archived histories) so the dialog reflects what force: true actually removes.
🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @apps/web/src/components/SidebarV2.tsx around line 854:
`handleRemoveProject` filters `threads` (live shells only) to compute `projectThreads`, then shows the user a confirmation dialog saying exactly `projectThreads.length` thread histories will be deleted. But the `deleteProject` call passes `force: true`, which makes the server delete *all* threads in the project including archived ones. Archived threads are not in the live shell list, so the dialog undercounts: it says "delete its 1 thread" while the server actually deletes every archived history too. Consider counting archived threads for the project (or wording the confirmation to account for archived histories) so the dialog reflects what `force: true` actually removes.
Brings in 20 new commits from
pingdotgg/t3codemain (origin/main..upstream/main, up to4d8343641), evaluated per the fork's upstream-merge workflow. Full merge (no cherry-pick) to keep the RPC contract in sync.Highlights
fbd77420f(pingdotgg#4272)1c9a6de26(pingdotgg#4317)t3.jsonproject configuration support16491a84b(pingdotgg#4276)b44ed835c/9c9916aefConflicts
None. Auto-merge succeeded on all 6 overlap files (
server.ts,server.test.ts,ChatComposer.tsx,ModelPickerContent.tsx,SettingsSidebarNav.tsx,contracts/index.ts); provider-usage wiring preserved in each. No fork-identity files touched. pingdotgg#4272's provider changes don't collide with the fork's usage layers or driverbaseEnvthreading.Verification
@t3tools/contracts,t3(server),@t3tools/webAfter squash-merge
Squashing breaks upstream ancestry; will follow with a
git merge -s ours upstream/mainreconciliation so the next merge stays clean.🤖 Generated with Claude Code
Note
Add auto runtime mode, t3.json config support, and glass-surface UI redesign
autoruntime mode across contracts, Claude adapter, Codex runtime, and all composer/composer-menu UIs; inautomode,permissionModeis set to'auto'and approvals are routed toauto_review.t3.jsonproject file support: a new schema (t3ProjectFile.ts), server-side loader (T3ProjectFileLoader.ts), and a marketing endpoint serving the JSON Schema for LSP/editor consumption.ProjectFaviconResolvernow readsiconPathfromt3.jsonbefore falling back to well-known icon locations.t3.jsoncan be imported directly into the project actions UI viaProjectScriptsControl; on failure, the add-action dialog pre-fills for correction.backdrop-filter,color-mix) for composer, alerts, dropdowns, and dialogs; sidebar color tokens are unified to a zinc-based hierarchy for both v1 and v2.glassOpacitysetting (range 40–100, default 80) persisted to client settings and applied via--glass-opacityCSS variable in real time.SidebarStageBackdropcomponents are now generated withuseIdto prevent collisions when rendered multiple times.defaultThreadEnvMode,newWorktreesStartFromOrigin) are now sourced from the primary server's settings rather than the target environment's server configs.📊 Macroscope summarized c6b76cd. 63 files reviewed, 0 issues evaluated, 0 issues filtered, 0 comments posted
🗂️ Filtered Issues
No issues evaluated.