fix(settings): keep theme previews independent of active theme

[Iflaqbhat]

Summary

• Replaces unsupported bg-zinc-950 utilities with configured bg-black utilities in the Appearance theme picker.
• Keeps the Light, Dark, and System preview swatches visually stable, regardless of the active app theme.
• Uses fixed pure white and black preview examples by design; the swatches show the available modes rather than tracking a custom active-theme surface.
• Adds regression coverage for both the intended preview colors and their configured Tailwind palette entries.

Why

The app overrides Tailwind colors and does not define the Zinc palette. The old bg-zinc-950 class therefore produced no background rule, letting the preview inherit its parent theme.

Issue

• Closes [Bug]: Theme picker previews inherit the active theme #2328

Scope

• apps/app/src/react-app/domains/settings/appearance/theme-section.tsx
• apps/app/tests/theme-preview.test.ts

Out of scope

• Changing the selected theme behavior or application theme tokens.

Testing

Ran

• pnpm --filter @openwork/app test
• pnpm --filter @openwork/app typecheck
• pnpm --filter @openwork/app build
• git diff --check

Result

• pass: 73 tests, typecheck, production build, and whitespace check.
• build emitted existing use memo and chunk-size warnings only.

CI status

• pass: local verification above.
• code-related failures: none.
• external/env/auth blockers: none.

Manual verification

1. Open Settings > Appearance.
2. Select Light, Dark, and System in turn.
3. Confirm the previews remain: Light = white, Dark = black, System = white/black split.

Evidence

• Original reproduction recording and report

Risk

• Low. This changes only fixed preview swatch classes.

Rollback

• Revert commits fac8b55b and b6d5995.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openwork-landing	Ready	Preview, Comment, Open in v0	Jun 23, 2026 6:49am

[vercel]

@Iflaqbhat is attempting to deploy a commit to the Different AI Team on Vercel.

A member of the Team first needs to authorize it.

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[evanklem]

Pulled this branch and verified the fix. Reads correct to me.

What I checked:

• Root cause matches the description.

  • The dark previews used bg-zinc-950.
  • apps/app/tailwind.config.ts overrides theme.colors with the Radix palette, which has no zinc.
  • Because of that, bg-zinc-950 compiled to no CSS rule and the dark swatch rendered transparent, so the card showed through.
  • Switching to bg-black / bg-white, which are in the palette, fixes it.

• Built the app CSS with the real config to confirm emission:

  cd apps/app
  
  npx @tailwindcss/cli@4.1.18 \
    -i src/app/index.css \
    -o /tmp/out.css \
    --content "./src/**/*.{ts,tsx}"

  Results:

  • bg-zinc-950 produces no rule.
  • .bg-black is emitted.
  • .bg-white is emitted.

• Both affected spots are covered:

  • The Dark swatch.
  • The dark half of the System split.

Both were previously using bg-zinc-950.

The Light swatch was already using bg-white, so there is no visual change there.

Screenshot

One small note

Not a blocker: the added test pins the constant strings, bg-white / bg-black.

That guards the literal values, but it does not assert the thing that actually broke here: whether the class resolves to a real palette color.

A class like bg-zinc-950 could pass a same-shaped test while still rendering nothing. It might be worth adding a check that ties the class to the configured palette rather than only checking the literal string.

Also FYI, the same root cause, a color class that is not in the Radix palette, shows up in a handful of other components. I put the full list in #2341 so it does not widen this PR.

[Iflaqbhat]

@evanklem Thanks for the thorough verification and for documenting the broader issue in #2341.

I pushed b6d5995 to strengthen the regression test: it now checks that the preview color utilities resolve through the configured Tailwind palette, in addition to asserting the intended black/white values.

pnpm --filter @openwork/app test and typecheck pass.

[Pablosinyores]

Reasonable fix — extracting THEME_PREVIEW_CLASSES and adding the regression test are good.

One thing to verify: the rationale is that the app Tailwind override drops bg-zinc-950. If that override replaces the palette rather than just removing zinc, it is worth confirming bg-black/bg-white are actually in the configured palette too — otherwise the dark swatch can hit the same "unsupported utility" problem the PR is fixing. The test asserts the class names but not that they resolve to a real color; a check against the Tailwind config (or a computed-style assertion) would lock that down.

Also worth a line in the PR description: the swatches are now fixed pure black/white rather than the live theme background. That matches the "independent of active theme" goal, but means they will not track a custom dark palette — fine if intentional.

[Iflaqbhat]

@Pablosinyores Thanks, good call. I pushed b6d5995 to strengthen the regression test: it now imports the configured Tailwind palette and verifies the preview utilities resolve to real colors. bg-black and bg-white pass; the prior bg-zinc-950 does not.

The previews intentionally use fixed pure black/white examples rather than live theme-surface tokens, so they remain stable while selecting Light, Dark, or System. I added that design intent to the PR description as well.