CSS transform drops enum-valued state variants when a state maps a prop without a value

[nathanacurtis]

Problem

When config.processing.states maps a state concept to a prop without specifying a value (e.g. selected: { prop: selected }), the css transformer only recognizes the boolean form of that prop. If the prop is actually an enum (e.g. selected: unselected | selected | indeterminate), variants configured with enum values — like Checkbox's Selected=Selected — never match a state concept and are silently skipped. Their styling (the checkbox's selected fill, border, and icon visibility) never reaches the generated styles.css, even though it exists in the component spec.

Solution

Variants whose state-classified prop carries an enum value should still produce CSS. Either the state lookup understands enum-valued props (each non-rest value resolves to an appropriate selector), or configuration validation warns that a valueless state mapping doesn't cover the prop's enum values — silence is the bug.

Acceptance criteria

• specs transform css emits selected-state styling for EGDS Checkbox (Selected=Selected variants appear in generated styles.css)
• Any enum-valued prop mapped in processing.states without a value produces CSS for all its non-rest values, or a clear warning explaining the config gap
• No regression for boolean state props (disabled, focused, …)

Notes

Found during Storybook scaffold work (project 010): the authored Checkbox had to re-express selected-state styling by hand even though the data exists in variants.yaml.

---

Implementation details are tracked internally.