@sixthshift/design-system 0.8.0 → 0.9.0

package/src/components/Button/button.recipe.css

@@ -1,11 +1,17 @@
 /**
  * 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.
+ * This is the mapping from `(variant, state)` to a colour. 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 the library
+ * never shipped.
+ *
+ * Intent does not appear here at all. Each cell below paints with the intent
+ * slots (`--intent-solid-bg`, `--intent-fg`, …) that src/theming/intents.css
+ * declares per `data-intent`, so every variant works in every intent — including
+ * one a consumer adds — and this file has one cell per variant, not one per
+ * `(variant, intent)` pair.
  *
  * The grammar is `--button-{context}[-{state}]` — the same `context` and
  * `state` words the semantic layer uses (src/theming/vocabulary.ts). Note what is
@@ -37,131 +43,42 @@
     --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 ramp. 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);
+  /* solid — a filled surface, with text read on top of it. The slot pair
+     resolves to a `bg-*` / `fg-on-*` partnership, which is the pairing
+     check-contrast.ts verifies, so this cell inherits that guarantee. For
+     `neutral`, the default, that is the grey `bg-strong` fill. */
+  .btn[data-variant="solid"] {
+    --button-bg: var(--intent-solid-bg);
+    --button-bg-hovered: var(--intent-solid-bg-hovered);
+    --button-bg-pressed: var(--intent-solid-bg-pressed);
+    --button-fg: var(--intent-solid-fg);
   }
 
-  .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);
+  /* outline carries a resting surface; ghost does not. Beyond that they share
+     the family's text colour and its tint wash on hover and press. */
+  .btn[data-variant="outline"],
+  .btn[data-variant="ghost"] {
+    --button-bg-hovered: var(--intent-tint-bg-hovered);
+    --button-bg-pressed: var(--intent-tint-bg-pressed);
+    --button-fg: var(--intent-fg);
   }
 
   /* 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
+     this into the block 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);
+     side-effect of how this file was factored. */
+  .btn[data-variant="outline"] {
+    --button-bg: var(--bg-normal);
+    --button-border: var(--intent-border);
   }
 
-  /* 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);
+  /* inline — not a variant: inline text with no box (Button drops
+     `data-variant` for it, so no cell above can match). Only the text carries
+     colour, so the floor's transparent background and its no-shift-on-hover
+     chain both stand. It is brand-coloured only with `intent="brand"`;
+     `neutral`, the default, is plain text colour. */
+  .btn[data-inline="true"] {
+    --button-fg: var(--intent-fg);
   }
 }

package/src/components/Button/index.ts

@@ -5,6 +5,5 @@ export {
   type ButtonProps,
   type ButtonVariant,
   type ButtonVariantName,
-  buttonRecipe,
   buttonVariants,
 } from "./Button";

package/src/components/Card/Card.tsx

@@ -49,7 +49,7 @@ export const cardVariants = cva(
         sm: "rounded-lg p-3",
         md: "rounded-xl p-4",
         lg: "rounded-xl p-6",
-        xl: "rounded-2xl p-8",
+        xl: "rounded-xl p-8",
       },
       interactive: {
         true: "hover:border-(color:--card-border-hovered) focus-visible:outline-(color:--card-ring) cursor-pointer transition-colors focus-visible:outline-2 focus-visible:outline-offset-2",

package/src/components/CheckboxGroup/CheckboxGroup.tsx

@@ -26,10 +26,11 @@ export type CheckboxGroupProps = Omit<React.HTMLAttributes<HTMLDivElement>, "onC
   onValueChange?: (value: string[]) => void;
   /** Layout orientation */
   orientation?: "vertical" | "horizontal";
-  /** Visual variant */
-  variant?: "default" | "button";
-  /** Button appearance (only applies when variant="button") */
-  appearance?: "segmented" | "separate";
+  /**
+   * How the options render: `control` (the default) is one `Checkbox` per option;
+   * `segmented` and `separate` are a row or column of buttons, joined or apart.
+   */
+  appearance?: "control" | "segmented" | "separate";
   /** Input name for form submission */
   name?: string;
   /** Disable all options */
@@ -43,17 +44,19 @@ export type CheckboxGroupProps = Omit<React.HTMLAttributes<HTMLDivElement>, "onC
  * selection, via the `value`/`defaultValue`/`onValueChange` triad
  * (`useControllableState`).
  *
- * `variant="default"` (the default) renders one `Checkbox` per option, each
+ * `appearance="control"` (the default) renders one `Checkbox` per option, each
  * with its own visible label, laid out in a column or row per
- * `orientation`. `variant="button"` is a separate rendering path — not a
- * re-skinned `Checkbox` — a row/column of plain buttons with
- * `role="checkbox"` and no separate label; contiguous buttons touch and
- * share borders (`appearance="segmented"`, the default) or sit apart with
- * their own rounded corners (`appearance="separate"`).
+ * `orientation`. `appearance="segmented"` or `"separate"` is a separate
+ * rendering path — not a re-skinned `Checkbox` — a row/column of plain
+ * buttons with `role="checkbox"` and no separate label; contiguous buttons
+ * touch and share borders (`segmented`) or sit apart with their own rounded
+ * corners (`separate`). One prop rather than a
+ * `variant` + `appearance` pair, so "appearance without buttons" — which
+ * used to mean nothing — cannot be written.
  *
- * Form submission only happens when `name` is set. In the default variant
+ * Form submission only happens when `name` is set. With `control`
  * that means each underlying `Checkbox` gets `name`, so one hidden native
- * checkbox input is rendered per option; in the button variant the group
+ * checkbox input is rendered per option; with the button appearances the group
  * itself renders one hidden `<input type="checkbox">` per *currently
  * selected* value.
  *
@@ -68,8 +71,7 @@ const CheckboxGroup = React.forwardRef<HTMLDivElement, CheckboxGroupProps>(
       options,
       onValueChange,
       orientation = "vertical",
-      variant = "default",
-      appearance = "segmented",
+      appearance = "control",
       name,
       disabled,
       onBlur,
@@ -111,7 +113,7 @@ const CheckboxGroup = React.forwardRef<HTMLDivElement, CheckboxGroupProps>(
       }
     };
 
-    if (variant === "button") {
+    if (appearance === "segmented" || appearance === "separate") {
       const isVertical = orientation === "vertical";
       const isSegmented = appearance === "segmented";
 

package/src/components/Code/Workspace/Toolbar.tsx

@@ -1,7 +1,7 @@
 "use client";
 
 import type { HTMLAttributes, ReactNode } from "react";
-import { Button } from "../../Button";
+import { Button, type ButtonVariant } from "../../Button";
 
 export type Action = {
   id: string;
@@ -9,7 +9,7 @@ export type Action = {
   icon?: ReactNode;
   onClick: () => void;
   disabled?: boolean;
-  variant?: "solid" | "outline" | "ghost" | "link";
+  variant?: ButtonVariant;
 };
 
 export type ToolbarProps = HTMLAttributes<HTMLDivElement> & {

package/src/components/FormField/FormField.tsx

@@ -1,14 +1,15 @@
 "use client";
 
 import { Label } from "@sixthshift/design-system/label";
-import { Message } from "@sixthshift/design-system/message";
+import { Message, type MessageIntentName } from "@sixthshift/design-system/message";
 import { Muted } from "@sixthshift/design-system/muted";
 import { cn } from "@sixthshift/design-system/utils";
 import * as React from "react";
 
 export type FormFieldFeedback = {
   message: string;
-  intent: "danger" | "success" | "warning";
+  /** Message's intents, less `neutral` — feedback always reports an outcome. */
+  intent: Exclude<MessageIntentName, "neutral">;
 };
 
 export type FormFieldProps = React.HTMLAttributes<HTMLDivElement> & {

package/src/components/Input/Input.tsx

@@ -16,15 +16,15 @@ const iconSlotStyles = `absolute top-1/2 -translate-y-1/2 text-(--input-icon-fg)
  *
  * Renders a plain `<input>` unless `iconLeft` or `iconRight` is supplied, in
  * which case it wraps the input in a relatively positioned container so an
- * icon — or an icon-styled button, as `SearchInput` uses for its clear
- * button — can sit inside the field's padding without affecting layout.
+ * icon — or an icon-styled button — can sit inside the field's padding
+ * without affecting layout.
  *
  * Controlled or uncontrolled exactly like a native input (`value`/`onChange`
  * or `defaultValue`), and `type` is forwarded as-is, so `type="password"`,
  * `type="number"`, etc. all work.
  *
  * Meant to be wrapped by `FormField` for label, description and validation
- * wiring, or by `SearchInput` for a search affordance.
+ * wiring. For search, use `SearchInput`, which draws its own field.
  */
 const Input = React.forwardRef<HTMLInputElement, InputProps>(({ className, type, iconLeft, iconRight, ...props }, ref) => {
   if (iconLeft || iconRight) {

package/src/components/Markdown/Markdown.tsx

@@ -47,7 +47,7 @@ export const Markdown = React.forwardRef<HTMLDivElement, MarkdownProps>(({ child
         ul: ({ children }) => <ul className="mt-2 flex list-disc flex-col gap-1 pl-5">{children}</ul>,
         ol: ({ children }) => <ol className="mt-2 flex list-decimal flex-col gap-1 pl-5">{children}</ol>,
         li: ({ children }) => <li className="text-fg-default text-sm">{children}</li>,
-        code: ({ children }) => <code className="rounded bg-bg-subtle px-1.5 py-0.5 font-mono text-fg-emphasis text-xs">{children}</code>,
+        code: ({ children }) => <code className="rounded-sm bg-bg-subtle px-1.5 py-0.5 font-mono text-fg-emphasis text-xs">{children}</code>,
         pre: ({ children }) => <pre className="mt-2 overflow-x-auto rounded-md bg-bg-subtle p-3 font-mono text-xs">{children}</pre>,
       }}
     >

package/src/components/Message/message.recipe.css

@@ -1,12 +1,11 @@
 /**
  * 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.
+ * Message has one colour-bearing axis, `intent`, and one treatment: the
+ * family's tint, bordered. So the whole recipe is a single cell reading the
+ * intent slots from src/theming/intents.css — an intent a consumer adds there
+ * reaches Message with no change here. `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
@@ -18,30 +17,16 @@
  */
 
 @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-bg: var(--intent-tint-bg);
+    --message-fg: var(--intent-tint-fg);
+    --message-border: var(--intent-border);
   }
 
-  .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);
+  /* A neutral message sits on the resting surface, not the grey tint: it is a
+     plain bordered note, and a grey wash reads as disabled. The one place a
+     recipe overrides a slot for a single intent. */
+  .message[data-intent="neutral"] {
+    --message-bg: var(--bg-normal);
   }
 }

package/src/components/ProgressBar/ProgressBar.tsx

@@ -2,10 +2,18 @@ import { Caption } from "@sixthshift/design-system/caption";
 import { cn } from "@sixthshift/design-system/utils";
 import * as React from "react";
 
+export type ProgressBarIntentName = "neutral" | "brand" | "danger" | "success" | "warning";
+/** Widened, like every intent prop: a consumer adds an intent in CSS, not in a release. */
+export type ProgressBarIntent = ProgressBarIntentName | (string & {});
+
 export type ProgressBarProps = {
   completed: number;
   total: number;
   showFraction?: boolean;
+  /** The fill's colour family. Defaults to `brand`. */
+  intent?: ProgressBarIntent | undefined;
+  /** Name of a brand the theme defines, rendered as `data-brand`. Omitted, the bar follows the nearest `data-brand` ancestor. */
+  brand?: string | undefined;
   /** Accessible name for the progress bar. */
   label?: string;
   className?: string;
@@ -24,9 +32,13 @@ export type ProgressBarProps = {
  * invalid CSS or an impossible reported value — though the fraction text
  * still shows the raw, unclamped numbers. When `total` is not positive the
  * bar renders as indeterminate: no `aria-valuenow`/`aria-valuemax`, 0% fill.
+ *
+ * `intent` colours the fill and defaults to `brand`: progress is not an
+ * outcome, so a bar at 40% is not `success`. Pass `success` when completion
+ * really is the good news, or `danger` for a quota running out.
  */
 export const ProgressBar = React.forwardRef<HTMLDivElement, ProgressBarProps>(
-  ({ completed, total, showFraction = true, label = "Progress", className }, ref) => {
+  ({ completed, total, intent = "brand", brand, showFraction = true, label = "Progress", className }, ref) => {
     // A caller can hand us anything; the bar must not render an out-of-range
     // width (a negative `width` is invalid CSS) or report impossible progress.
     const isMeasurable = total > 0;
@@ -34,7 +46,7 @@ export const ProgressBar = React.forwardRef<HTMLDivElement, ProgressBarProps>(
     const percentage = isMeasurable ? (clamped / total) * 100 : 0;
 
     return (
-      <div ref={ref} className={cn("flex items-center gap-3", className)}>
+      <div ref={ref} data-intent={intent} data-brand={brand} className={cn("progress-bar flex items-center gap-3", className)}>
         <div
           role="progressbar"
           aria-label={label}
@@ -44,9 +56,9 @@ export const ProgressBar = React.forwardRef<HTMLDivElement, ProgressBarProps>(
           // total there is no meaningful progress to report.
           aria-valuenow={isMeasurable ? clamped : undefined}
           aria-valuetext={isMeasurable ? `${clamped} of ${total}` : undefined}
-          className="h-2 flex-1 overflow-hidden rounded-full bg-bg-strong"
+          className="h-2 flex-1 overflow-hidden rounded-full bg-(--progress-bar-track-bg)"
         >
-          <div className="h-full rounded-full bg-fg-success transition-all" style={{ width: `${percentage}%` }} />
+          <div className="h-full rounded-full bg-(--progress-bar-fill-bg) transition-all" style={{ width: `${percentage}%` }} />
         </div>
         {showFraction && (
           <Caption className="shrink-0">

package/src/components/ProgressBar/index.ts

@@ -1 +1 @@
-export { ProgressBar, type ProgressBarProps } from "./ProgressBar";
+export { ProgressBar, type ProgressBarIntent, type ProgressBarIntentName, type ProgressBarProps } from "./ProgressBar";

package/src/components/ProgressBar/progress-bar.recipe.css

@@ -0,0 +1,29 @@
+/**
+ * ProgressBar recipe — the component-token layer for ProgressBar.
+ *
+ * Two parts: the track, which is the same grey in every intent, and the fill,
+ * which paints with the intent slots from src/theming/intents.css. The fill
+ * reads `--intent-fg`, the family's colour on a resting surface, rather than
+ * the solid slot: `--intent-solid-bg` for `neutral` is `bg-strong`, which is
+ * the track itself, so a neutral bar would vanish. `neutral` is the one
+ * override: its `--intent-fg` is `fg-normal`, which barely separates from a
+ * `bg-strong` track in either mode, so it takes the mid-grey `fg-subtle`,
+ * which separates from both the track and the page around it. (`fg-on-strong`
+ * contrasts with the track but matches the page, and reads as a gap.)
+ *
+ * The grammar is `--progress-bar-{part}-{context}`. Both tokens live on the
+ * root, which carries `data-intent`, and the fill reads them by inheritance.
+ *
+ * `@layer components` is load-bearing, not tidiness — see button.recipe.css.
+ */
+
+@layer components {
+  .progress-bar {
+    --progress-bar-track-bg: var(--bg-strong);
+    --progress-bar-fill-bg: var(--intent-fg);
+  }
+
+  .progress-bar[data-intent="neutral"] {
+    --progress-bar-fill-bg: var(--fg-subtle);
+  }
+}

package/src/components/RadioButtonGroup/RadioButtonGroup.tsx

@@ -27,10 +27,11 @@ export type RadioButtonGroupProps = Omit<React.HTMLAttributes<HTMLDivElement>, "
   onValueChange?: (value: string) => void;
   /** Layout orientation */
   orientation?: "vertical" | "horizontal";
-  /** Visual variant */
-  variant?: "default" | "button";
-  /** Button appearance (only applies when variant="button") */
-  appearance?: "segmented" | "separate";
+  /**
+   * How the options render: `control` (the default) is one `RadioButton` per option;
+   * `segmented` and `separate` are a row or column of buttons, joined or apart.
+   */
+  appearance?: "control" | "segmented" | "separate";
   /** Input name for form submission */
   name?: string;
   /** Disable all options */
@@ -44,21 +45,22 @@ export type RadioButtonGroupProps = Omit<React.HTMLAttributes<HTMLDivElement>, "
  * uncontrolled `string` selection, via the `value`/`defaultValue`/
  * `onValueChange` triad (`useControllableState`).
  *
- * `variant="default"` (the default) renders one `RadioButton` per option.
- * `variant="button"` is a separate rendering path — not a re-skinned
- * `RadioButton` — a row/column of plain buttons with `role="radio"`;
- * contiguous buttons touch and share borders (`appearance="segmented"`, the
- * default) or sit apart with their own rounded corners
- * (`appearance="separate"`).
+ * `appearance="control"` (the default) renders one `RadioButton` per option.
+ * `appearance="segmented"` or `"separate"` is a separate rendering path — not
+ * a re-skinned `RadioButton` — a row/column of plain buttons with
+ * `role="radio"`; contiguous buttons touch and share borders (`segmented`) or
+ * sit apart with their own rounded corners (`separate`). One prop rather than
+ * a `variant` + `appearance` pair, so "appearance without buttons" — which
+ * used to mean nothing — cannot be written.
  *
  * Implements the WAI-ARIA radiogroup keyboard pattern: the group is one tab
  * stop, landing on the checked option (or the first enabled option if none
  * is checked), and arrow/Home/End keys move focus *and* selection between
  * enabled options, wrapping at the ends.
  *
- * Form submission only happens when `name` is set. In the default variant
+ * Form submission only happens when `name` is set. With `control`
  * that means each underlying `RadioButton` gets `name`, so one hidden
- * native radio input is rendered per option; in the button variant the
+ * native radio input is rendered per option; with the button appearances the
  * group itself renders a single hidden `<input type="hidden">` carrying the
  * selected value.
  *
@@ -73,8 +75,7 @@ const RadioButtonGroup = React.forwardRef<HTMLDivElement, RadioButtonGroupProps>
       options,
       onValueChange,
       orientation = "vertical",
-      variant = "default",
-      appearance = "segmented",
+      appearance = "control",
       name,
       disabled,
       onBlur,
@@ -111,8 +112,8 @@ const RadioButtonGroup = React.forwardRef<HTMLDivElement, RadioButtonGroupProps>
     const handleOptionSelect = (optionValue: string) => {
       // Re-selecting the current option reports nothing, as a native radio does
       // not. The guard lives here as well as in `RadioButton` because the button
-      // variant is a separate rendering path that never goes through it — and
-      // the two variants must not disagree about this. `ToggleGroup` in
+      // appearances are a separate rendering path that never goes through it —
+      // and the two paths must not disagree about this. `ToggleGroup` in
       // `"single"` mode already works this way.
       if (optionValue === value) return;
       setValue(optionValue);
@@ -139,7 +140,7 @@ const RadioButtonGroup = React.forwardRef<HTMLDivElement, RadioButtonGroupProps>
     const hasCheckedOption = options.some((option) => option.value === value);
     const tabStopValue = hasCheckedOption ? value : firstEnabledValue;
 
-    if (variant === "button") {
+    if (appearance === "segmented" || appearance === "separate") {
       const isVertical = orientation === "vertical";
       const isSegmented = appearance === "segmented";
 

package/src/components/SearchInput/SearchInput.tsx

@@ -1,6 +1,5 @@
 "use client";
 
-import { Input } from "@sixthshift/design-system/input";
 import { cn } from "@sixthshift/design-system/utils";
 import { Search, X } from "lucide-react";
 import * as React from "react";
@@ -14,12 +13,19 @@ export type SearchInputProps = Omit<React.InputHTMLAttributes<HTMLInputElement>,
   clearLabel?: string;
 };
 
+/** The icon slots, duplicated from Input's. */
+const iconSlotStyles = `absolute top-1/2 -translate-y-1/2 text-(--search-input-icon-fg)
+  [&_svg]:h-4 [&_svg]:w-4
+  [&_button]:flex [&_button]:cursor-pointer [&_button]:appearance-none
+  [&_button]:border-0 [&_button]:bg-transparent`;
+
 /**
  * Text input specialised for search: a search icon fixed on the left and,
  * once there is a value, a clear button on the right.
  *
- * Wraps `Input`, using its `iconLeft`/`iconRight` slots, rather than
- * reimplementing the field. Always controlled — `value` is required and
+ * Its own field, not a wrapped `Input`: the markup and classes are duplicated
+ * from Input on purpose, so importing SearchInput pulls in nothing else and
+ * its colours are its own `--search-input-*` tokens. Always controlled — `value` is required and
  * there is no `defaultValue`/uncontrolled mode. `onValueChange` receives the
  * string value directly; the native `onChange` keeps its event signature and
  * fires too if passed. Clearing calls `onClear` if provided, otherwise calls
@@ -36,25 +42,33 @@ const SearchInput = React.forwardRef<HTMLInputElement, SearchInputProps>(
     };
 
     return (
-      <Input
-        ref={ref}
-        type="text"
-        value={value}
-        onChange={(e) => {
-          onValueChange(e.target.value);
-          onChange?.(e);
-        }}
-        iconLeft={<Search />}
-        iconRight={
-          value ? (
-            <button type="button" onClick={handleClear} aria-label={clearLabel} className="rounded hover:bg-(--search-input-clear-bg-hovered)">
+      <div className={cn("search-input relative h-9 w-full text-sm", className)}>
+        <span className={cn(iconSlotStyles, "left-3")}>
+          <Search />
+        </span>
+        <input
+          ref={ref}
+          type="text"
+          value={value}
+          onChange={(e) => {
+            onValueChange(e.target.value);
+            onChange?.(e);
+          }}
+          className={cn(
+            "border-(color:--search-input-border) focus-visible:ring-(color:--search-input-ring) flex h-full w-full rounded-md border bg-(--search-input-bg) py-1 text-[length:inherit] shadow-xs transition-colors placeholder:text-(--search-input-placeholder-fg) focus-visible:outline-hidden focus-visible:ring-2 disabled:cursor-not-allowed disabled:opacity-50",
+            "pl-9",
+            value ? "pr-9" : "pr-3"
+          )}
+          {...props}
+        />
+        {value && (
+          <span className={cn(iconSlotStyles, "right-3")}>
+            <button type="button" onClick={handleClear} aria-label={clearLabel} className="rounded-sm hover:bg-(--search-input-clear-bg-hovered)">
               <X />
             </button>
-          ) : undefined
-        }
-        className={cn("search-input", className)}
-        {...props}
-      />
+          </span>
+        )}
+      </div>
     );
   }
 );