Uh oh!
There was an error while loading. Please reload this page.
refactor(mobile): compile semantic themes for Uniwind - #138
Conversation
Mobile theming read colours through a useThemeColor hook at every call site. This compiles the semantic palettes into Uniwind theme CSS and moves components onto class-based colours, deleting useThemeColor and its 67 call sites. Adopted from T3 Code 018d7f2775daabd2ef07898af29586915a0b7f67 (pingdotgg/t3code#7327). Taken now rather than deferred because it is a foundation change, not a cosmetic one. Upstream is entirely on the far side of it, so every later mobile commit Pylon adopts would otherwise need hand-translating back into useThemeColor - a tax paid repeatedly with the benefit never arriving. Adaptation, six conflicts: T3Wordmark stays deleted. Pylon removed it when the fork was established and renders PylonMark instead; adopting upstream's converted version would have restored a T3 brand component. PylonMark gains the same withUniwind colorClassName treatment upstream applied to its own wordmark, so Pylon's mark follows the new idiom without inheriting T3 artwork. Its mask geometry keeps literal fills, since only the visible silhouette is themed. CompactBrandTitle and HomeHeader keep PylonMark and move from useThemeColor("--color-icon") to colorClassName="accent-icon", which resolves the same variable. ThreadComposer's two import conflicts were resolved by what the merged file actually references rather than by picking a side, dropping StyleSheet and themeColorWithAlpha as genuinely unused and keeping Pylon's Alert, KeyboardAvoidingView and Modal. GitActionProgressOverlay takes upstream's version wholesale. It already carries upstream #8399's glass restyle, and Pylon's only divergence there was the error-phase palette, which upstream expresses identically in the new adaptive classes. The default merge left a hybrid whose shadowColor was computed and never used. The generated default-theme JSON replaces Pylon's mobileDefaultTheme.ts. All 65 tokens were compared first and are value-identical, so no Pylon palette customisation is lost.
The Uniwind adoption ships a new lint rule, no-mobile-uniwind-theme-escape-hatches, which rejects dark:/light: utilities because they do not follow registered custom themes. Upstream converted its own files; three Pylon files it has never seen still violated it, at error severity, so the adoption could not land green: - SessionPresentationSurface.tsx and PendingSessionInteractionCard.tsx exist only in Pylon; - the one violation in ThreadFeed.tsx is on a Pylon-added line, confirmed by upstream's copy of that file containing no dark:/light: utilities at all. Merges 28 light/dark utility pairs into adaptive tokens across those three files. Twelve of the tokens needed already existed; seven did not and are registered in the generator's ADAPTIVE_COLORS map: amber-100-500-a18, amber-900-200, neutral-100-a95-900-a95, neutral-800-200, rose-800-200, sky-100-500-a18, and sky-800-200. The conversion is colour-preserving, not merely lint-silencing. Each new token is defined from the same Tailwind family, shade, and opacity as the pair it replaces, and the emitted values were checked against tailwindcss/colors: for example adaptive-rose-800-200 resolves to oklch(45.5% 0.188 13.697) in light and oklch(89.2% 0.058 10.001) in dark, which are rose-800 and rose-200 exactly. Pairs are merged only where both halves appear on the same line, so a light-only utility is never rewritten into an appearance-sensitive token.
Thread transfer impact✅ Thread transfer remains within every enforced ceiling.
Baseline: Scenario and decoded snapshot size10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.
Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed. |
…alette checks Review follow-ups on the Uniwind adoption. All three are upstream regressions the refactor introduced, not Pylon adaptations. The thread composer lost its shadow colour. Upstream replaced an explicit shadowColor plus 0.12/0.35 opacity with shadowOpacity: 1 and a bare shadow-adaptive-black-a15-a35 class. Compiling that class with the repo's own tailwindcss 4.3 shows it emits only --tw-shadow-color and no box-shadow, and Uniwind's native store only maps a style when result.boxShadow is defined, so the class reached React Native as nothing at all. With no shadowColor and full opacity, iOS falls back to opaque black. The colour is set explicitly again, the way GitActionProgressOverlay does it in this same refactor. Of the two shadow-adaptive usages, the other one is paired with shadow-lg and is fine. PendingUserInputCard drifted a shade pair: text-neutral-700 dark:text-neutral-200 became adaptive-neutral-600-300, lighter in light mode and darker in dark mode, so contrast dropped in both. Every other conversion in that file is 1:1. Registers adaptive-neutral-700-200 and uses it. The readability test stopped covering the default palette when its loop narrowed to BUILT_IN_THEME_IDS. Restoring MOBILE_THEME_IDS does not fix it: t3-code is absent from BUILT_IN_THEMES, so getMobileThemeVariables falls back to BUILT_IN_THEMES[0] and would check t3-chat twice, and it does not typecheck. The default palette is asserted through readDefaultMobileThemeVariables, which reads global.css. Verified by making the default placeholder unreadable: the check now fails at a 1.02 contrast ratio, where before it passed.
rynfar
commented
Aug 28, 2026
Independent review pass found seven issues, all upstream regressions rather than Fixed — the thread composer rendered an opaque black shadow. Upstream replaced an explicit Uniwind's native store only maps a style when Fixed — a shade pair drifted. Fixed — the default palette lost readability coverage. Note that the obvious Still open — flagged, not fixed, because they want the device pass this PR
|
rynfar
commented
Aug 29, 2026
Mobile pass — partialRan this branch's bundle on a booted iPhone 17 Pro (iOS 26.3) against a What the refactor gets right, confirmed on device. The compiled Uniwind
The environment connected rather than rendering an empty disconnected state — What I could not verify, and why. The three things most worth a device pass Worth noting on its own: thread and project rows having no accessible role is a So the four visual findings from the review — disabled-button shadow, Android |
…tatus bar scrim Two more review follow-ups on the Uniwind adoption. Disabled toolbar buttons kept their shadow. The refactor moved the shadow to a shadow-lg class, which Uniwind maps to React Native's boxShadow, and boxShadow wins over the legacy shadowOpacity the style still set to 0 when disabled. The class is now dropped for disabled buttons and the dead shadowOpacity line is gone. The Android status bar lost its scrim. backgroundColor was removed while translucent stayed true, so content draws under the bar with nothing behind it, and --color-status-bar was left with no consumer at all. Restores the same variable origin/pylon read, now through useUniwindTheme. App.tsx joins the lint rule's interop allowlist because StatusBar's Android backgroundColor is a native prop that cannot take a className. Two findings from the same review are deliberately not fixed. The toolbar fade ramps to transparent black rather than the surface at alpha 0; the obvious class-level fix compiles to color-mix(..., 0%, transparent), which is not clearly the surface hue either, and I cannot tell the two apart without a device. The GitHub glyph lost its #24292F default, which is latent because the only caller passes colorClassName, and hardcoding a brand hex back would fight the direction of the refactor. Both are recorded on the pull request.
Pylon's 92ec009 landed after this branch and pursues the same goal by another route: it replaces the status indicators' dark:/light: pairs with semantic warning tokens and deletes the raw iconColor/iconBackground fields entirely. That is the later Pylon decision, so threadPresentation and both thread-list files take Pylon's version wholesale rather than this branch's adaptive-token conversion of the same lines. Integrating them needed four things. Pylon's files still imported useThemeColor, which this branch deletes, so 25 call sites across the two thread-list files move to useUniwindTheme. Pylon's nine remaining dark:/light: pairs are converted to adaptive tokens the generator already defines, because the new lint rule rejects them at error severity. The generated theme files are regenerated to pick up Pylon's five new variables, and the theme test's hardcoded variable count moves from 65 to 70 to match. mobileTheme.test.ts keeps this branch's structure rather than Pylon's: Pylon's version calls getMobileThemeVariables with DEFAULT_MOBILE_THEME_ID, which does not typecheck here and silently resolves to BUILT_IN_THEMES[0] anyway.
#131 landed on pylon with the mobile warning colour split this branch had already converted to adaptive tokens. Keeps both: the destructive/warning split stays, expressed as adaptive-rose-600-400 and adaptive-amber-600-400 so the new lint rule accepts it. Registers adaptive-amber-600-400, which did not exist yet.
Uh oh!
There was an error while loading. Please reload this page.
Mobile theming read colours through a
useThemeColorhook at every call site.This compiles the semantic palettes into Uniwind theme CSS and moves components
onto class-based colours, deleting
useThemeColorand all 67 of its callsites.
Adopted from T3 Code
018d7f2775daabd2ef07898af29586915a0b7f67(pingdotgg/t3code#7327). 110 files.
Why now rather than deferred
This is a foundation change, not a cosmetic one, and deferring it was the
strictly worst option. Upstream is entirely on the far side of it — 67 call
sites before, 0 after — so every later mobile commit Pylon adopts would need
hand-translating back into
useThemeColor, a tax paid repeatedly with thebenefit never arriving. It was already happening inside this same batch: #7327
rewrites
GitActionProgressOverlay.tsx, the exact file upstream #8399 touches.Adaptation — six conflicts
T3Wordmarkstays deleted. Pylon removed it in2929153bd feat: establish Pylon forkand rendersPylonMarkinstead. Adopting upstream's convertedversion would have restored a T3 brand component, which AGENTS.md forbids.
PylonMarkinstead gains the samewithUniwind/colorClassNametreatmentupstream applied to its own wordmark, so Pylon's mark follows the new idiom
without inheriting T3 artwork. Its mask paths keep literal fills, since only the
visible silhouette is themed. Verified
T3Wordmarkhas no remaining referencesanywhere in
apps/mobile/src.CompactBrandTitle/HomeHeaderkeepPylonMarkand move fromuseThemeColor("--color-icon")tocolorClassName="accent-icon". Confirmedthose resolve the same variable — the
accent-prefix is Uniwind's convention,not an accent colour, so
accent-icon→--color-icon.ThreadComposerhad two import conflicts, resolved by what the merged fileactually references rather than by picking a side: dropped
StyleSheetandthemeColorWithAlphaas genuinely unused, kept Pylon'sAlert,KeyboardAvoidingView, andModal.GitActionProgressOverlaytakes upstream's version wholesale, which iscorrect here: it already carries #8399's glass restyle, and Pylon's only
divergence was the error-phase palette, which upstream expresses identically in
the new adaptive classes. The default merge had produced a hybrid whose
shadowColorwas computed and never used — caught by lint, not by tests.The generated default-theme JSON replaces Pylon's
mobileDefaultTheme.ts.All 65 tokens were compared before resolving: value-identical, so no Pylon
palette customisation is lost.
Second commit: the part upstream could not do
The adoption ships a new lint rule,
no-mobile-uniwind-theme-escape-hatches,at error severity. Upstream converted its own files; three Pylon files it has
never seen still violated it 24 times, so this could not land green.
SessionPresentationSurface.tsxandPendingSessionInteractionCard.tsxarePylon-only, and the single
ThreadFeed.tsxviolation sits on a Pylon-added line(upstream's copy of that file has no
dark:/light:utilities at all).28 light/dark pairs merged into adaptive tokens; 7 new tokens registered in the
generator. This is colour-preserving rather than lint-silencing — each token is
built from the same Tailwind family, shade, and opacity as the pair it replaced,
and the emitted values were checked numerically against
tailwindcss/colors(e.g.
adaptive-rose-800-200→oklch(45.5% 0.188 13.697)light,oklch(89.2% 0.058 10.001)dark, exactly rose-800 and rose-200). Pairs mergeonly where both halves are on one line, so a light-only utility is never
rewritten into an appearance-sensitive token.
Verification
vp test run apps/mobile— 841 passedvp run -F @t3tools/mobile typecheck— cleanvp lint apps/mobile/src— clean, including the new rule (24 → 0)vp test run oxlint-plugin-t3code/rules/no-mobile-uniwind-theme-escape-hatches.test.ts— 25 passedvp run icons:check— "Pylon brand assets are current (40 files)", so no brandasset regression from the mark change
generated-uniwind-themes.css,-theme-names.json, and-default-theme-variables.jsonacross a regenerationgives an identical digest
Not verified
This has had no run on a simulator or device. It is a ~100-file theming change,
so it wants a
test-pylon-mobilepass before merge — tests and lint cannot seea colour that resolves to the wrong thing at runtime.
Claude Opus 5 via Claude Code.
Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.