Generated theme.json preset references do not match WordPress CSS variables

[chubes4]

Problem

ThemeJsonProjection generates deterministic preset slugs from truncated hexadecimal hashes and writes those raw slugs into var:preset references. WordPress applies _wp_to_kebab_case() when emitting preset CSS variable names, which inserts separators at digit/letter boundaries. The reference and declaration therefore diverge.

Cara Jane currently emits a font-family preset named font-family-8041fd6f89. WordPress declares --wp--preset--font-family--font-family-8041-fd-6-f-89, while Global Styles references --wp--preset--font-family--font-family-8041fd6f89. The unresolved declaration makes the body fall back from Poppins to Times. Font-size presets and color presets have the same contract risk.

Evidence

Fresh WordPress browser inspection at desktop and mobile reports:

• computed body and paragraph font: Times
• expected body font: Poppins, sans-serif
• root value for the raw generated font preset variable: empty
• WordPress-emitted kebab-cased preset variable: present
• mobile home heading overflow: true
• all eight retained typography diagnostics report dropped heading font-family parity

Acceptance

• generated preset definitions and var:preset references use the same WordPress-compatible canonical slug
• color, font-family, font-size, and spacing groups follow one generic slug contract
• deterministic package-level coverage proves the projected theme shape
• WordPress integration coverage proves every generated reference resolves to an emitted preset CSS variable
• fresh Cara Jane browser evidence reports Poppins body typography on desktop and mobile

AI assistance

OpenAI gpt-5.6-sol was used through OpenCode to inspect current screenshots, query browser-computed typography, compare generated theme.json with WordPress global CSS, and isolate the slug-normalization mismatch. Chris Huber reviewed and is responsible for the issue.