fix(apollo-vertex): repair two registry values that generate dead CSS

[kittyyueli]

Summary

Two independent defects in apps/apollo-vertex/registry.json, both of which make generated CSS silently resolve to nothing.

1. Three theme var keys carry a stray -- prefix

"--info-fg":        "oklch(0.49 0.12 210)",
"--success-fg":     "oklch(0.46 0.10 152)",
"--destructive-fg": "oklch(0.50 0.14 18)",

They are the only 3 of 120 keys in cssVars.light that do. The other 117 are bare, and all 105 in dark are bare. This breaks both consumers of the file.

Our own generator. scripts/generate-theme-css.ts prepends -- unconditionally in renderBlock, and runs it over cssVars.light to build :root. So the prefixed keys emit a four-hyphen declaration — the custom properties do not exist under their intended names even inside apollo-vertex:

BEFORE (main), :root            AFTER (this PR), :root
  ----info-fg: …                  --info-fg: …
  ----success-fg: …               --success-fg: …
  ----destructive-fg: …           --destructive-fg: …

A shadcn consumer. The CLI's update-theme plugin (ti in shadcn@4.4.0) synthesizes the @theme inline aliases from the union of all three blocks. prop strips a leading --, the value does not:

const prop = isColor(value) ? `--color-${key.replace(/^--/, "")}` : `--${key.replace(/^--/, "")}`;
const val  = `var(--${key})`;   // no strip

which produces, in a downstream consumer's index.css today:

--color-destructive-fg: var(----destructive-fg);
--color-success-fg:     var(----success-fg);
--color-info-fg:        var(----info-fg);

Four hyphens, pointing at a property that does not exist. Any text-destructive-fg, bg-success-fg or border-info-fg resolves to nothing. After this PR both halves agree.

2. The Inter font item names a family the dependency does not register

"font": { "family": "Inter", "dependency": "@fontsource-variable/inter" }

@fontsource-variable/inter@5.3.0 registers the face as 'Inter Variable'. That is the only family name in the package: every one of index.css, standard.css, wght.css, opsz.css and their italic variants declares font-family: 'Inter Variable'.

On a non-Next project the shadcn CLI writes font.family verbatim as the @theme value for variable (et() in shadcn@4.4.0):

if (isNext) cssVars.theme[font.variable] = `var(${font.variable})`;
else {
  const dep = font.dependency ?? `@fontsource-variable/${short}`;
  dependencies.push(dep);
  css[`@import "${dep}"`] = {};
  cssVars.theme[font.variable] = font.family;   // verbatim
}

So a Vite consumer gets @theme { --font-sans: Inter } next to an @import of a package that only provides Inter Variable. The face never matches, font-sans falls through to the system sans stack, and the woff2 files ship unused.

This PR leads the stack with the registered name and keeps Inter plus the generic fallbacks behind it:

"family": "'Inter Variable', Inter, ui-sans-serif, sans-serif, system-ui"

A consumer that never installs the font item resolves exactly as it does today — past the missing Inter Variable, on to whatever it was already using. A consumer that does install it now gets the face it already downloaded. The :root / .dark cssVars.font-sans entries are aligned with it, since the CLI's @theme value overrides them and the two disagreeing is what made this hard to spot.

provider and import are untouched: both are read only on the Next path, which writes var(--font-sans) and never looks at family. This change cannot affect a Next consumer.

How it surfaced

A downstream consumer refreshed its vendored components, and both landed in its index.css in the same diff. Neither broke anything visibly. It has no usages of the three *-fg utilities yet, and it was already falling back to system sans before the font item existed. That is exactly why they are worth fixing now rather than when someone writes text-destructive-fg and finds it does nothing.

Out of scope, worth a follow-up

cssVars.dark carries no *-fg values at all, so under .dark those three inherit the light foreground. Real gap, but choosing dark-mode oklch values for three semantic foregrounds is a design call rather than a mechanical one, so it is not in this PR.

Testing

Check	Result
registry.json parses	yes
biome check apps/apollo-vertex/registry.json	clean
Keys with a -- prefix in cssVars.light after the change	0 (was 3)
Keys with a -- prefix in cssVars.dark	0, unchanged
generate-theme-css.ts renderBlock output, both revisions	compared, shown above
Family name verified against the published tarball	@fontsource-variable/inter@5.3.0, every .css file
CLI behaviour verified against	shadcn@4.4.0 dist/index.js, functions et and ti
Colour values touched	none, only the key names
Files outside registry.json	none

I could not run pnpm build / registry:build in this session, so the regenerated CSS is for CI to confirm. Apollo Vertex Registry Check installs the theme into a fresh app, which is the path both fixes affect.

Note on CI

enable-auto-merge is red for a repo-wide reason unrelated to this diff. See the comment below.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SnmiT3edq81s2qTDqoE8zP

[github-actions]

Apollo Coded App preview deployments are ready.

Project	Status	Preview	Updated (PT)
apollo-design	Ready	Preview · Logs	Sep 14, 2026, 01:24:19 PM
apollo-docs	Ready	Preview · Logs	Sep 14, 2026, 01:24:19 PM
apollo-landing	Ready	Preview · Logs	Sep 14, 2026, 01:24:19 PM
apollo-vertex	Ready	Preview · Logs	Sep 14, 2026, 01:24:19 PM

[github-actions]

Dependency License Review

• ✅ 1937 package(s) scanned
• ✅ No license issues found
• ⚠️ 2 package(s) excluded (see details below)

License distribution

License	Packages
MIT	1708
ISC	88
Apache-2.0	55
BSD-3-Clause	27
BSD-2-Clause	23
BlueOak-1.0.0	8
MPL-2.0	4
MIT-0	3
CC0-1.0	3
MIT OR Apache-2.0	2
(MIT OR Apache-2.0)	2
Unlicense	2
LGPL-3.0-or-later	1
Python-2.0	1
CC-BY-4.0	1
(MPL-2.0 OR Apache-2.0)	1
Unknown	1
Artistic-2.0	1
(WTFPL OR MIT)	1
(BSD-2-Clause OR MIT OR Apache-2.0)	1
CC-BY-3.0	1
0BSD	1
(MIT OR CC0-1.0)	1
MIT AND ISC	1

Excluded packages

Package	Version	License	Reason
@img/sharp-libvips-linux-x64	1.3.2	LGPL-3.0-or-later	LGPL pre-built binary, not linked
khroma	2.1.0	Unknown	MIT per GitHub repo, missing license field in package.json

[Copilot]

🔵 Needs a closer look

The claimed *-fg utilities remain unavailable until the theme mappings or claims are updated.

Pull request overview

Fixes three malformed light-theme CSS variable keys in apps/apollo-vertex/registry.json.

Changes:

• Removes stray -- prefixes from info-fg, success-fg, and destructive-fg.
• Preserves values and limits changes to registry.json.

File summaries

File	Summary	Finding
apps/apollo-vertex/registry.json	Corrects three light-theme variable keys.	Moderate: cssVars.theme does not register the claimed *-fg utilities; add mappings or update the claims.

Review details

Suppressed comments (1)

apps/apollo-vertex/registry.json:191

• This only fixes the generated custom-property declarations; it does not make the claimed text-*-fg/bg-*-fg/border-*-fg utilities available. generate-theme-css.ts emits @theme inline from cssVars.theme, and that map currently registers color-*-foreground, not any color-*-fg entries, so Tailwind has no *-fg utilities to resolve. Add matching color-info-fg, color-success-fg, and color-destructive-fg mappings (and dark-mode values if these tokens are intended to work in dark mode), or update the PR's claimed utility names.

          "info-fg": "oklch(0.49 0.12 210)",
          "success-fg": "oklch(0.46 0.10 152)",
          "destructive-fg": "oklch(0.50 0.14 18)",

• Files reviewed: 1/1 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[kittyyueli]

enable-auto-merge is red, but not because of this diff.

Apollo Vertex Auto Merge fails at gh pr merge --auto --rebase with GraphQL: Resource not accessible by integration (enablePullRequestAutoMerge) — the Releaser App token lacks the permission, or auto-merge isn't enabled on the repo. Repo-wide: the same job failed twice on #1145, which merged fine regardless.

Nothing to port — the fix is an app/repo setting, not a code change. Not re-running, since a permission error reproduces deterministically.

---

Generated by Claude Code

[github-actions]

📊 Coverage + size by package

Per-package bundle size on this PR (no JS/TS source changes detected under packages/* or web-packages/*).

Package	Coverage	New-line coverage	Packed (gzip)	Unpacked	vs main
@uipath/apollo-core	—	—	42.01 MB	50.12 MB	±0
@uipath/apollo-react	43.7%	—	7.56 MB	29.14 MB	±0
@uipath/apollo-ui-icons	—	—	2.85 MB	6.91 MB	±0
@uipath/apollo-wind	66.8%	—	459.9 KB	2.91 MB	−7 B
@uipath/ap-chat	85.8%	—	43.92 MB	56.68 MB	±0

_{"Coverage" is each package's own coverage.include scope (e.g. apollo-core instruments only scripts/). "Packed"/"Unpacked" come from npm pack --dry-run and only cover built packages — "—" means not measured this run (package not affected / not built). "vs main" is the packed (gzipped) delta against the last successful main build (the package-sizes artifact from the Release workflow); "—" there means no main baseline was available this run. The baseline is main's latest build, not this PR's exact merge-base, so it includes any drift since the branch diverged. Packages with no vitest config are omitted.}

[github-actions]

Storybook visual diff

✅ No stories are affected by this PR's changes; nothing to compare. Logs

Updated (PT): Sep 14, 2026, 01:25:14 PM

[Copilot]

🟡 Changes recommended

Revert or justify unrelated font changes and address the missing utility mappings or narrow the PR scope.

Get a fresh assessment by requesting another Copilot review.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 2
• Review effort level: Lite