@sixthshift/design-system 0.3.0 → 0.4.0

package/src/theme/recipes/button.css

@@ -0,0 +1,167 @@
+/**
+ * Button recipe — the component-token layer for Button.
+ *
+ * This is the mapping from `(variant, intent, state)` to a semantic token. It
+ * used to live in `compoundVariants` inside Button.tsx, where it was compiled
+ * into class-name literals and no consumer could reach it. Here it is data, so
+ * a consumer can re-point a cell, scope a change to a subtree, or add a variant
+ * or intent the library never shipped.
+ *
+ * The grammar is `--button-{context}[-{state}]` — the same `context` and
+ * `state` words the semantic layer uses (src/theme/schema.ts). Note what is
+ * deliberately *absent*: intent and weight never appear in a token name. They
+ * select, via the `data-` attributes below. Putting them in the name
+ * (`--button-bg-danger`) would restore the combinatorial explosion this layer
+ * exists to remove, and would leave a consumer unable to add an intent, because
+ * the variable for it would not exist.
+ *
+ * `@layer components` is load-bearing, not tidiness. The cascade compares
+ * layers before specificity, and unlayered author CSS outranks any layered
+ * author CSS — so a consumer's `.btn { ... }` (0,1,0) beats the cell rules
+ * below (0,3,0) without an `!important`. The corollary is a trap worth knowing:
+ * an override written *inside* a layer is compared on specificity again, and
+ * silently loses. Consumer overrides go unlayered.
+ */
+
+@layer components {
+  /* The floor. Applies when no cell below matches — an intent a consumer has
+     added but not yet styled renders as a plain, legible button rather than
+     something broken. `transparent` is what Tailwind's preflight already gives
+     a <button>, so this is the resting default, not a new opinion. */
+  .btn {
+    --button-bg: transparent;
+    --button-bg-hovered: var(--button-bg); /* no shift on hover */
+    --button-bg-pressed: var(--button-bg-hovered);
+    --button-fg: var(--fg-normal);
+    --button-border: var(--border-normal);
+    --button-ring: var(--focus-ring);
+  }
+
+  /* solid — a filled surface, with text read on top of it. The `fg-on-*`
+     partner is the pairing check-contrast.ts verifies, so these four cells
+     inherit that guarantee rather than restating it. */
+  .btn[data-variant="solid"][data-intent="brand"] {
+    --button-bg: var(--bg-brand);
+    --button-bg-hovered: var(--bg-brand-hovered);
+    --button-bg-pressed: var(--bg-brand-pressed);
+    --button-fg: var(--fg-on-brand);
+  }
+
+  /* `neutral` means *no colour family* — the grey tiers. It used to resolve to
+     the brand fill, which made `intent="neutral"` mean one thing on Button and
+     another on Badge and Message, where it was already grey. Button
+     was the outlier; this is the cell that ends that. A brand-coloured button
+     is now `intent="brand"`, which is also Button's default, so a bare
+     `<Button>` is unchanged. */
+  .btn[data-variant="solid"][data-intent="neutral"] {
+    --button-bg: var(--bg-strong);
+    --button-bg-hovered: var(--bg-strong-hovered);
+    --button-bg-pressed: var(--bg-strong-pressed);
+    --button-fg: var(--fg-on-strong);
+  }
+
+  .btn[data-variant="solid"][data-intent="danger"] {
+    --button-bg: var(--bg-danger);
+    --button-bg-hovered: var(--bg-danger-hovered);
+    --button-bg-pressed: var(--bg-danger-pressed);
+    --button-fg: var(--fg-on-danger);
+  }
+
+  .btn[data-variant="solid"][data-intent="success"] {
+    --button-bg: var(--bg-success);
+    --button-bg-hovered: var(--bg-success-hovered);
+    --button-bg-pressed: var(--bg-success-pressed);
+    --button-fg: var(--fg-on-success);
+  }
+
+  .btn[data-variant="solid"][data-intent="warning"] {
+    --button-bg: var(--bg-warning);
+    --button-bg-hovered: var(--bg-warning-hovered);
+    --button-bg-pressed: var(--bg-warning-pressed);
+    --button-fg: var(--fg-on-warning);
+  }
+
+  /* outline carries a resting surface; ghost does not. Beyond that their
+     colour recipes are identical, so the text colour and the hover/pressed wash
+     are shared per intent and only the two lines below differ. */
+  .btn[data-variant="outline"] {
+    --button-bg: var(--bg-normal);
+  }
+
+  /* `neutral` here needed no change: outline and ghost were already grey — it
+     was only the solid and link cells that read as brand. */
+  .btn[data-variant="outline"][data-intent="neutral"],
+  .btn[data-variant="ghost"][data-intent="neutral"] {
+    --button-bg-hovered: var(--bg-subtle-hovered);
+    --button-bg-pressed: var(--bg-subtle-pressed);
+    --button-fg: var(--fg-normal);
+  }
+
+  .btn[data-variant="outline"][data-intent="brand"],
+  .btn[data-variant="ghost"][data-intent="brand"] {
+    --button-bg-hovered: var(--bg-brand-subtle-hovered);
+    --button-bg-pressed: var(--bg-brand-subtle-pressed);
+    --button-fg: var(--fg-brand);
+  }
+
+  .btn[data-variant="outline"][data-intent="danger"],
+  .btn[data-variant="ghost"][data-intent="danger"] {
+    --button-bg-hovered: var(--bg-danger-subtle-hovered);
+    --button-bg-pressed: var(--bg-danger-subtle-pressed);
+    --button-fg: var(--fg-danger);
+  }
+
+  .btn[data-variant="outline"][data-intent="success"],
+  .btn[data-variant="ghost"][data-intent="success"] {
+    --button-bg-hovered: var(--bg-success-subtle-hovered);
+    --button-bg-pressed: var(--bg-success-subtle-pressed);
+    --button-fg: var(--fg-success);
+  }
+
+  .btn[data-variant="outline"][data-intent="warning"],
+  .btn[data-variant="ghost"][data-intent="warning"] {
+    --button-bg-hovered: var(--bg-warning-subtle-hovered);
+    --button-bg-pressed: var(--bg-warning-subtle-pressed);
+    --button-fg: var(--fg-warning);
+  }
+
+  /* The border belongs to outline alone. Ghost has no border width, so folding
+     these into the blocks above would be invisible today — and a silent
+     semantic change the moment anyone gave ghost a border. A consumer who wants
+     that can still say so in one line; it should be their decision, not a
+     side-effect of how this file was factored. `neutral` needs no rule: the
+     floor's `border-normal` is already right. */
+  .btn[data-variant="outline"][data-intent="brand"] {
+    --button-border: var(--border-brand);
+  }
+  .btn[data-variant="outline"][data-intent="danger"] {
+    --button-border: var(--border-danger);
+  }
+  .btn[data-variant="outline"][data-intent="success"] {
+    --button-border: var(--border-success);
+  }
+  .btn[data-variant="outline"][data-intent="warning"] {
+    --button-border: var(--border-warning);
+  }
+
+  /* link — no surface in any state; only the text carries colour, so the
+     floor's transparent background and its no-shift-on-hover chain both stand.
+     A link button reads as brand-coloured by default because `brand` is
+     Button's default intent — not because `neutral` was quietly redefined to
+     mean brand, which is what this cell used to do. */
+  .btn[data-variant="link"][data-intent="brand"] {
+    --button-fg: var(--fg-brand);
+  }
+  .btn[data-variant="link"][data-intent="neutral"] {
+    --button-fg: var(--fg-normal);
+  }
+  .btn[data-variant="link"][data-intent="danger"] {
+    --button-fg: var(--fg-danger);
+  }
+  .btn[data-variant="link"][data-intent="success"] {
+    --button-fg: var(--fg-success);
+  }
+  .btn[data-variant="link"][data-intent="warning"] {
+    --button-fg: var(--fg-warning);
+  }
+}

package/src/theme/recipes/card.css

@@ -0,0 +1,26 @@
+/**
+ * Card recipe — the component-token layer for Card.
+ *
+ * Card has no variant/intent axis — every instance uses the same fixed
+ * semantic tokens the old plain class string named directly. This file just
+ * gives those tokens a name, so a consumer can re-point a cell or scope a
+ * change to a subtree without a release.
+ *
+ * The grammar is `--card-{context}[-{state}]`, context in {bg, fg, border,
+ * ring} — the same words the semantic layer uses. `--card-ring` backs the
+ * `outline-*` utilities on the interactive (clickable) variant: it plays the
+ * same role `--button-ring` plays for `ring-*`, just via a different Tailwind
+ * utility, so it keeps the `ring` context name rather than inventing one.
+ *
+ * `@layer components` is load-bearing, not tidiness — see button.css.
+ */
+
+@layer components {
+  .card {
+    --card-bg: var(--bg-normal);
+    --card-border: var(--border-normal);
+    --card-border-hovered: var(--border-strong);
+    --card-fg: var(--fg-normal);
+    --card-ring: var(--border-strong);
+  }
+}

package/src/theme/recipes/checkbox.css

@@ -0,0 +1,44 @@
+/**
+ * Checkbox recipe — the component-token layer for Checkbox.
+ *
+ * Checkbox has no variant/intent axis for colour, unlike Button — every
+ * colour is a fixed semantic token today. The only axis is `data-state`,
+ * already rendered by Checkbox.tsx as "unchecked" | "checked" |
+ * "indeterminate", so this file maps that state to the four `--checkbox-*`
+ * tokens the class string reads via `bg-(--checkbox-bg)`,
+ * `border-(color:--checkbox-border)`, `text-(--checkbox-fg)` and
+ * `focus-visible:ring-(color:--checkbox-ring)`.
+ *
+ * disabled is deliberately absent: Checkbox dims via `disabled:opacity-50`
+ * rather than swapping a colour, so it needs no state cell here.
+ *
+ * `@layer components` is load-bearing, not tidiness — see button.css.
+ */
+
+@layer components {
+  /* The floor — resting, unchecked. Border and ring are constant across every
+     state (the old class applied `border-border-brand` unconditionally), so
+     they live here rather than in a cell. `--checkbox-fg` is deliberately
+     *not* set here: the old class applied no text-colour utility while
+     unchecked, so the box inherited its color from an ancestor (`body`'s
+     `text-fg-normal`, in practice). Leaving the token undefined reproduces
+     that — an unset custom property in `color: var(--checkbox-fg)` is
+     invalid at computed-value time, which for an inherited property like
+     `color` resolves to the inherited value, not a fixed one. Setting a
+     value here would pin unchecked to `fg-normal` even where an ancestor had
+     overridden the inherited color, which is not what the old markup did. */
+  .checkbox {
+    --checkbox-bg: transparent;
+    --checkbox-border: var(--border-brand);
+    --checkbox-ring: var(--focus-ring);
+  }
+
+  /* checked and indeterminate both fill the box and read the tick/dash on
+     top of it — the same pairing the old class applied via
+     `(isChecked || isIndeterminate) && "bg-bg-brand text-fg-on-brand"`. */
+  .checkbox[data-state="checked"],
+  .checkbox[data-state="indeterminate"] {
+    --checkbox-bg: var(--bg-brand);
+    --checkbox-fg: var(--fg-on-brand);
+  }
+}

package/src/theme/recipes/field.css

@@ -0,0 +1,14 @@
+/**
+ * Field recipe — the component-token layer for Field.
+ *
+ * Field's label and value both read the same semantic token (`fg-subtle`)
+ * today, in every layout and mono/proportional combination, so one token
+ * covers the whole component. See button.css's header for why
+ * `@layer components` is load-bearing.
+ */
+
+@layer components {
+  .field {
+    --field-fg: var(--fg-subtle);
+  }
+}

package/src/theme/recipes/index.css

@@ -0,0 +1,28 @@
+/**
+ * Tier 3 — the component recipes.
+ *
+ * One file per component, aggregated here so `tokens.css` has a single import
+ * and adding a component does not touch a file anyone else is editing. Each
+ * recipe maps `(variant, intent, state)` to a semantic token; see button.css
+ * for the pattern and the reasoning behind `@layer components`.
+ */
+@import "./button.css";
+@import "./badge.css";
+@import "./message.css";
+@import "./spinner.css";
+@import "./tabs.css";
+@import "./toggle.css";
+
+/* Form controls and surfaces — the components consumers most often restyle. */
+@import "./input.css";
+@import "./textarea.css";
+@import "./search-input.css";
+@import "./field.css";
+@import "./checkbox.css";
+@import "./radio-button.css";
+@import "./switch.css";
+@import "./card.css";
+@import "./modal.css";
+@import "./sheet.css";
+@import "./select.css";
+@import "./tag-chip.css";

package/src/theme/recipes/input.css

@@ -0,0 +1,29 @@
+/**
+ * Input recipe — the component-token layer for Input.
+ *
+ * Input has no variant/intent axis for colour, unlike Button — every colour is
+ * a fixed semantic token today. This file exists anyway so a consumer can
+ * re-point a cell (or scope an override to a subtree) without a release, the
+ * same reason button.css and message.css exist. One floor block, no cells: see
+ * button.css's header for what `@layer components` buys and why it is
+ * load-bearing, not tidiness.
+ *
+ * The grammar is `--input-{part}-{context}`, context in {bg, fg, border, ring}.
+ * `file` and `icon` are parts (the file-picker button, the icon/adornment
+ * slot) that happen to share their resting value with the input's own
+ * bg/border today — each still gets its own token, because a consumer wanting
+ * a different file-button background or icon colour needs a variable that
+ * exists, not a shared one they'd have to fork.
+ */
+
+@layer components {
+  .input {
+    --input-bg: var(--bg-normal);
+    --input-border: var(--border-normal);
+    --input-ring: var(--focus-ring);
+    --input-placeholder-fg: var(--fg-subtle);
+    --input-file-bg: var(--input-bg);
+    --input-file-fg: var(--fg-normal);
+    --input-icon-fg: var(--fg-subtle);
+  }
+}

package/src/theme/recipes/message.css

@@ -0,0 +1,47 @@
+/**
+ * Message recipe — the component-token layer for Message.
+ *
+ * Message has one colour-bearing variant, `intent`, with four values. Each
+ * cell sets border + bg + fg together, exactly as the old `cva` `variants.intent`
+ * map did — this file is that map, moved to CSS so a consumer can re-point a
+ * cell or add an intent the library never shipped. `size` is pure geometry
+ * (padding, gap, font-size) and stays in Message.tsx's `cva` call; nothing
+ * here concerns it.
+ *
+ * The grammar is `--message-{context}`, context in {bg, fg, border}. Intent
+ * never appears in a token name — see button.css's header for why: it would
+ * restore the combinatorial explosion this layer exists to remove, and would
+ * leave a consumer unable to add an intent, because the variable for it would
+ * not exist. Intent selects entirely via `data-intent`.
+ *
+ * `@layer components` is load-bearing, not tidiness — see button.css.
+ */
+
+@layer components {
+  /* The floor. Applies when no cell below matches — an intent a consumer has
+     added but not yet styled still renders as a plain, legible message rather
+     than something broken. */
+  .message {
+    --message-bg: var(--bg-normal);
+    --message-fg: var(--fg-normal);
+    --message-border: var(--border-normal);
+  }
+
+  .message[data-intent="success"] {
+    --message-bg: var(--bg-success-subtle);
+    --message-fg: var(--fg-on-success-subtle);
+    --message-border: var(--border-success);
+  }
+
+  .message[data-intent="warning"] {
+    --message-bg: var(--bg-warning-subtle);
+    --message-fg: var(--fg-on-warning-subtle);
+    --message-border: var(--border-warning);
+  }
+
+  .message[data-intent="danger"] {
+    --message-bg: var(--bg-danger-subtle);
+    --message-fg: var(--fg-on-danger-subtle);
+    --message-border: var(--border-danger);
+  }
+}

package/src/theme/recipes/modal.css

@@ -0,0 +1,31 @@
+/**
+ * Modal recipe — the component-token layer for Modal.
+ *
+ * Modal has no variant/intent axis, but it is multi-part: an overlay
+ * (backdrop), a panel, and a close button that lives inside `Modal.Header`.
+ * Each part gets its own class hook so the grammar's `part` segment has
+ * something to select on: `--modal-{part}-{context}[-{state}]`.
+ *
+ * `.modal-close` is scoped separately from `.modal-header` (which carries no
+ * colour of its own — the old header had no border) because the close button
+ * is the only colour-bearing thing inside it.
+ *
+ * `@layer components` is load-bearing, not tidiness — see button.css.
+ */
+
+@layer components {
+  .modal {
+    --modal-bg: var(--bg-normal);
+    --modal-border: var(--border-normal);
+  }
+
+  .modal-overlay {
+    --modal-overlay-bg: var(--bg-overlay);
+  }
+
+  .modal-close {
+    --modal-close-fg: var(--fg-subtle);
+    --modal-close-fg-hovered: var(--fg-normal);
+    --modal-close-bg-hovered: var(--bg-subtle);
+  }
+}

package/src/theme/recipes/radio-button.css

@@ -0,0 +1,42 @@
+/**
+ * RadioButton recipe — the component-token layer for RadioButton.
+ *
+ * RadioButton has no variant/intent axis for colour, unlike Button — every
+ * colour is a fixed semantic token today. The only axis is `data-state`,
+ * already rendered by RadioButton.tsx as "unchecked" | "checked", so this
+ * file maps that state to the four `--radio-button-*` tokens the class
+ * string reads via `bg-(--radio-button-bg)`,
+ * `border-(color:--radio-button-border)`, `text-(--radio-button-fg)` and
+ * `focus-visible:ring-(color:--radio-button-ring)`.
+ *
+ * disabled is deliberately absent: RadioButton dims via
+ * `disabled:opacity-50` rather than swapping a colour, so it needs no state
+ * cell here.
+ *
+ * `@layer components` is load-bearing, not tidiness — see button.css.
+ */
+
+@layer components {
+  /* The floor — resting, unchecked. Border and ring are constant across every
+     state (the old class applied `border-border-brand` unconditionally), so
+     they live here rather than in a cell. `--radio-button-fg` is deliberately
+     *not* set here: the old class applied no text-colour utility while
+     unchecked, so the circle inherited its color from an ancestor (`body`'s
+     `text-fg-normal`, in practice). Leaving the token undefined reproduces
+     that — an unset custom property in `color: var(--radio-button-fg)` is
+     invalid at computed-value time, which for an inherited property like
+     `color` resolves to the inherited value, not a fixed one. */
+  .radio-button {
+    --radio-button-bg: transparent;
+    --radio-button-border: var(--border-brand);
+    --radio-button-ring: var(--focus-ring);
+  }
+
+  /* checked fills the circle and reads the dot on top of it — the same
+     pairing the old class applied via `checked && "bg-bg-brand
+     text-fg-on-brand"`. */
+  .radio-button[data-state="checked"] {
+    --radio-button-bg: var(--bg-brand);
+    --radio-button-fg: var(--fg-on-brand);
+  }
+}

package/src/theme/recipes/search-input.css

@@ -0,0 +1,16 @@
+/**
+ * SearchInput recipe — the component-token layer for SearchInput.
+ *
+ * SearchInput renders `Input` for its field, so every input-surface colour
+ * (background, border, ring, placeholder, icon) already comes from
+ * `.input`'s tokens in input.css — duplicating them here would just be a
+ * second name for the same cell. The only colour SearchInput contributes
+ * itself is the clear button's hover wash, which is why this file is a single
+ * token rather than empty.
+ */
+
+@layer components {
+  .search-input {
+    --search-input-clear-bg-hovered: var(--bg-subtle);
+  }
+}

package/src/theme/recipes/select.css

@@ -0,0 +1,105 @@
+/**
+ * Select recipe — the component-token layer for Select.
+ *
+ * Select has no variant/intent axis of its own — every colour was a fixed
+ * semantic class before this conversion (`bg-bg-normal`, `border-border-normal`,
+ * …), so there is no cell matrix here the way there is in button.css. This file
+ * exists so a consumer can re-point one of those fixed colours, or scope a
+ * change to a subtree, without a release.
+ *
+ * Select is multi-part, so the grammar carries a `part` segment:
+ * `--select-{part}-{context}[-{state}]`, context in {bg, fg, border, ring}.
+ *
+ * Two states select via an attribute rather than a name suffix, following
+ * tabs.css's `data-selected` precedent:
+ *
+ *   - `aria-selected="true"` on `.select-option` — already rendered by
+ *     SelectDropdown.tsx for the `role="option"` contract, so this reuses it
+ *     rather than inventing a second attribute for the same fact.
+ *   - `data-highlighted="true"` on `.select-option` — nothing in the
+ *     pre-refactor DOM carried the keyboard/mouse "current" option as an
+ *     attribute (it was computed straight into a class string from
+ *     `highlightedIndex` in SelectDropdown.tsx), so SelectDropdown.tsx now
+ *     renders it. `highlightedIndex` itself is driven by Select.tsx's
+ *     `onHighlight`/`setHighlightedIndex`, which useSelectKeyboard.ts's
+ *     ArrowUp/ArrowDown/Home/End/typeahead handling calls into — i.e. the
+ *     same state that already existed, now surfaced as an attribute instead
+ *     of being compiled directly into a class name.
+ *
+ * The multi-select checkbox indicator reads its own `data-selected="true"`
+ * (mirroring tabs.css) rather than the ARIA one — it is a decorative `<span>`
+ * with no ARIA role, so `aria-selected` on it would be an invalid-attribute
+ * a11y violation.
+ *
+ * `@layer components` is load-bearing, not tidiness — see button.css for the
+ * cascade reasoning.
+ */
+
+@layer components {
+  /* ---------------------------------------------------------------------
+     trigger — shared by both the button trigger (SelectTriggerButton) and
+     the searchable input trigger (SelectTriggerSearch): same look, same
+     tokens, one class hook on both root elements. */
+  .select-trigger {
+    --select-trigger-bg: var(--bg-normal);
+    --select-trigger-bg-hovered: var(--bg-subtle);
+    --select-trigger-fg: var(--fg-normal);
+    --select-trigger-border: var(--border-normal);
+    --select-trigger-ring: var(--focus-ring);
+    /* Chevron in both triggers, and the clear button's resting colour. */
+    --select-trigger-icon-fg: var(--fg-subtle);
+  }
+
+  /* clear ("x") button inside the button trigger. */
+  .select-trigger-clear {
+    --select-trigger-clear-fg: var(--fg-subtle);
+    --select-trigger-clear-fg-hovered: var(--fg-normal);
+    --select-trigger-clear-bg-hovered: var(--bg-subtle);
+  }
+
+  /* ---------------------------------------------------------------------
+     dropdown — the listbox surface. */
+  .select-dropdown {
+    --select-dropdown-bg: var(--bg-normal);
+    --select-dropdown-border: var(--border-normal);
+    /* Inherited by the "no options" message, a plain child div. */
+    --select-dropdown-empty-fg: var(--fg-subtle);
+  }
+
+  /* ---------------------------------------------------------------------
+     option — one row in the dropdown. The floor is the unselected,
+     unhighlighted look: no surface, quiet text. */
+  .select-option {
+    --select-option-bg: transparent;
+    --select-option-fg: var(--fg-subtle);
+  }
+
+  .select-option[aria-selected="true"] {
+    --select-option-fg: var(--fg-normal);
+  }
+
+  .select-option[data-highlighted="true"] {
+    --select-option-bg: var(--bg-subtle);
+  }
+
+  /* ---------------------------------------------------------------------
+     option indicator — the multi-select checkbox square. Unselected shows
+     only a border; selected fills with the brand pairing that
+     check-contrast.ts verifies. `--select-option-indicator-fg` is
+     deliberately unset at rest (not `transparent`): the pre-refactor markup
+     set no text colour class on the unselected indicator at all, so it read
+     `.select-option`'s own colour by ordinary inheritance. An unset custom
+     property referenced by `color` — an inherited property — falls back to
+     that inherited value per spec, reproducing the same result; setting it
+     explicitly here would pin a colour the original never had. */
+  .select-option-indicator {
+    --select-option-indicator-bg: transparent;
+    --select-option-indicator-border: var(--border-normal);
+  }
+
+  .select-option-indicator[data-selected="true"] {
+    --select-option-indicator-bg: var(--bg-brand);
+    --select-option-indicator-fg: var(--fg-on-brand);
+    --select-option-indicator-border: var(--border-brand);
+  }
+}

package/src/theme/recipes/sheet.css

@@ -0,0 +1,34 @@
+/**
+ * Sheet recipe — the component-token layer for Sheet.
+ *
+ * Sheet has no variant/intent axis, but it is multi-part: a panel, a header
+ * with a bottom border and a close button, and a footer with a top border.
+ * Each part gets its own class hook so the grammar's `part` segment has
+ * something to select on: `--sheet-{part}-{context}[-{state}]`.
+ *
+ * Unlike Modal, Sheet renders no backdrop — it is a persistent workspace, not
+ * a transient overlay — so there is no `.sheet-overlay` cell here.
+ *
+ * `@layer components` is load-bearing, not tidiness — see button.css.
+ */
+
+@layer components {
+  .sheet {
+    --sheet-bg: var(--bg-normal);
+    --sheet-border: var(--border-normal);
+  }
+
+  .sheet-header {
+    --sheet-header-border: var(--border-normal);
+  }
+
+  .sheet-footer {
+    --sheet-footer-border: var(--border-normal);
+  }
+
+  .sheet-close {
+    --sheet-close-fg: var(--fg-subtle);
+    --sheet-close-fg-hovered: var(--fg-normal);
+    --sheet-close-bg-hovered: var(--bg-subtle);
+  }
+}

package/src/theme/recipes/spinner.css

@@ -0,0 +1,17 @@
+/**
+ * Spinner recipe — the component-token layer for Spinner.
+ *
+ * Spinner has exactly one colour, and no intent — nothing here selects on a
+ * `data-*` attribute, because there is nothing to select between. The point is
+ * narrower than Button or Message's: a consumer previously had no token to
+ * hook to recolour a spinner, only `className` fighting the base string's
+ * `text-fg-subtle`. `--spinner-fg` gives them a seam.
+ *
+ * `@layer components` is load-bearing, not tidiness — see button.css.
+ */
+
+@layer components {
+  .spinner {
+    --spinner-fg: var(--fg-subtle);
+  }
+}

package/src/theme/recipes/switch.css

@@ -0,0 +1,39 @@
+/**
+ * Switch recipe — the component-token layer for Switch.
+ *
+ * Switch has no variant/intent axis for colour, unlike Button — every colour
+ * is a fixed semantic token today. The only axis is `data-state`, already
+ * rendered by Switch.tsx as "unchecked" | "checked", so this file maps that
+ * state to the track token (`--switch-bg`, read via `bg-(--switch-bg)`) plus
+ * the two tokens for the moving thumb, treated as a `part`
+ * (`--switch-thumb-bg`, `--switch-thumb-fg`) since it is a sub-element of
+ * the track, not a separate component. The thumb never changes colour
+ * between states — only its position does, which stays a plain
+ * `translate-x-*` class in Switch.tsx — so it needs no state cell, just a
+ * floor. Custom properties inherit from the track button down into the
+ * thumb `<span>`, so no separate class is needed to carry the value there;
+ * `switch-thumb` exists purely as a stable hook for a consumer who wants to
+ * scope an override to the thumb specifically.
+ *
+ * disabled is deliberately absent: Switch dims via `disabled:opacity-50`
+ * rather than swapping a colour, so it needs no state cell here.
+ *
+ * `@layer components` is load-bearing, not tidiness — see button.css.
+ */
+
+@layer components {
+  /* The floor — resting, unchecked. Ring is constant across every state, so
+     it lives here rather than in a cell. */
+  .switch {
+    --switch-bg: var(--bg-subtle);
+    --switch-ring: var(--focus-ring);
+    --switch-thumb-bg: var(--bg-normal);
+    --switch-thumb-fg: var(--fg-subtle);
+  }
+
+  /* checked fills the track — the same swap the old class applied via
+     `checked ? "bg-bg-brand" : "bg-bg-subtle"`. */
+  .switch[data-state="checked"] {
+    --switch-bg: var(--bg-brand);
+  }
+}