@burojs/ui-shadcn 0.2.0

package/dist/styles.css

@@ -0,0 +1,794 @@
+/* Buro design tokens + Tailwind v4 entry point.
+ *
+ * The consumer imports ONLY this file — it pulls in Tailwind itself,
+ * declares the scan sources, the dark-mode variant, and the token mapping.
+ * `@source` resolves relative to THIS file, so classes from the package's
+ * dist reach the consumer's output without a single line in their config;
+ * `node_modules` is excluded from Tailwind's auto-detection, so without
+ * this line none of the kit's classes make it into the build — silently.
+ */
+@import "tailwindcss";
+
+/* Radix overlay animations. This is a CSS library, NOT a plugin: `@plugin
+ * "tw-animate-css"` fails with `"." is not exported under the conditions
+ * ["node","require"]`. Verified by build. Both @import lines must come
+ * first — CSS requires @import to precede all other rules. */
+@import "tw-animate-css";
+
+/* The handbook's markdown rendering (`prose`, `prose-sm`, `prose-invert`,
+ * `prose-headings`, ...) needs this registered somewhere Tailwind actually
+ * scans, or every `prose*` class compiles to nothing and the docs render
+ * unstyled. Opposite of the two imports above: this is a real Tailwind
+ * plugin, not a CSS library, so it takes `@plugin`, not `@import`. */
+@plugin '@tailwindcss/typography';
+
+/* Resolves relative to THIS file. Published consumers scan compiled JS;
+ * source-aliased development hosts scan TS/TSX. Both are required because
+ * node_modules is excluded from Tailwind's automatic detection. */
+@source './**/*.{js,ts,tsx}';
+
+/* The documentation panel's opening.
+ *
+ * An ANIMATION, not a transition, and that distinction is the whole point: a
+ * transition needs a previous value to interpolate from, so it cannot animate
+ * an element that has just been inserted. React coalesces the mount and the
+ * expand into one commit, `requestAnimationFrame` (even nested) runs before
+ * that commit, a `setTimeout` gets batched with it, and `flushSync` fixes it
+ * only by doing something React explicitly objects to from inside an effect.
+ * A keyframe animation plays from the moment the element exists and needs none
+ * of that. Closing keeps the transition — there the element is already on
+ * screen, so it has a value to leave from.
+ *
+ * The target width is read from a custom property so it is declared once, on
+ * the element, and the keyframe and the resting width cannot drift apart. */
+@keyframes doc-panel-in {
+  from {
+    width: 0;
+  }
+  to {
+    width: var(--doc-panel-w);
+  }
+}
+
+@custom-variant dark (&:is(.dark *));
+
+:root {
+  /* Neutral base, values copied verbatim from shadcn v4's default theme.
+   * Stored as oklch, not hsl, for the same reason the severity scale is:
+   * these exist to reproduce a specific external palette exactly, and only
+   * that palette's own notation guarantees it. The previous default was
+   * shadcn's older slate base (`hsl(222 47% 11%)` and friends) — a visibly
+   * blue grey, which is what this change removes. */
+  --background: oklch(1 0 0);
+  --foreground: oklch(0.145 0 0);
+  --primary: oklch(0.205 0 0);
+  --primary-foreground: oklch(0.985 0 0);
+  --secondary: oklch(0.97 0 0);
+  --secondary-foreground: oklch(0.205 0 0);
+  --muted: oklch(0.97 0 0);
+  /* Re-measured against the new neutral surfaces (final-review-findings.md
+   * M3), value UNCHANGED — this is shadcn v4's own default and every other
+   * consumer of this palette matches it: 6.62:1 (old blue-grey background)
+   * -> 4.73:1 on the new --background, 4.34:1 on a solid --muted surface
+   * (primitives/tabs.tsx inactive tab labels, enum/enum-picker.tsx,
+   * resource/resource-list.tsx, notification/toaster.tsx). The first still
+   * clears WCAG AA's 4.5:1; 4.34 on solid --muted does not — a known tight
+   * spot, recorded here rather than left silent, not a fix for this pass. */
+  --muted-foreground: oklch(0.556 0 0);
+  --accent: oklch(0.97 0 0);
+  --accent-foreground: oklch(0.205 0 0);
+  /* Measured against the NEW neutral --background in all THREE roles this
+   * token is actually used in (see task-2's contrast script, re-run for the
+   * final review — final-review-findings.md I2):
+   *   - red --destructive text on --background:                    5.63:1
+   *   - white --destructive-foreground on a solid --destructive fill: 5.63:1
+   *     (the SAME computation as the row above, not a second measurement —
+   *     --background and --destructive-foreground are both pure white here,
+   *     so "red on background" and "white on red fill" reduce to one
+   *     number. A prior pass of this comment paired 4.76 with 4.76 for
+   *     exactly this reason and read as two data points; it wasn't.)
+   *   - red text on a 10%-red tint over --background
+   *     (`bg-destructive/10 text-destructive` — badges, banners, inline
+   *     errors; see forms/declarative-form.tsx, resource/resource-form.tsx,
+   *     auth/login-form.tsx, resource/list-error-state.tsx,
+   *     resource/tab-body.tsx, document-show-banner.tsx and others):
+   *                                                                  4.74:1
+   *     (`bg-destructive/5` variant: 5.17:1.) THIS is the case that
+   *     actually constrains the value — it is the tightest of the three.
+   *     shadcn v4's own candidate, `oklch(0.577 0.245 27.325)`, passes the
+   *     first two roles at 4.91:1 but only reaches ≈4.0:1 in this one,
+   *     below WCAG AA's 4.5:1 — so it does NOT replace the hand-tuned value
+   *     below, despite passing the two roles that look, at a glance, like
+   *     the only ones that matter.
+   * All four numbers above clear 4.5:1. Restores the pre-migration
+   * hand-tuned `hsl(0 84% 44%)`, tuned against the OLD blue-grey background
+   * this change removes and re-verified here against the new one. shadcn
+   * itself drops --destructive-foreground and hardcodes white; this file
+   * keeps the token, valued the same as every other solid-fill `-foreground`
+   * below (pure white, kept in hsl() for readability — see the
+   * severity-scale comment for why pure black/white stay hsl()). Kept in
+   * hsl(), matching the file's default convention: oklch is reserved for
+   * values reproducing an external palette exactly, and a hand-tuned value
+   * is not that. */
+  --destructive: hsl(0 84% 44%);
+  --destructive-foreground: hsl(0 0% 100%);
+
+  /* Severity scale. Task 3 of the token-contract plan: the tree hardcoded 11
+   * palette colours across status badges, the history timeline, the log
+   * viewer, and a couple of one-off notices (25 amber / 19 emerald / 11 zinc
+   * / 11 violet / 9 red / 9 blue / 7 orange / 6 sky / 2 yellow / 2 purple /
+   * 2 indigo uses — see the task report for the full meaning → colour →
+   * site table). Deriving MEANING from those sites (not guessing from the
+   * plan's hypothesis) produced 7 distinct meanings, not the plan's 6:
+   * success, warning, info, neutral, highlight, active, and caution. `error`
+   * needed no new token — every error/failure site already reduces to the
+   * existing `--destructive` above. `active` (blue: a workflow actually
+   * RUNNING right now) and `caution` (orange: TimedOut, one notch more
+   * severe than warning's Paused/Canceled) are real, separately-rendered
+   * meanings the plan didn't anticipate — folding either into `info`/
+   * `warning` would visibly change what's on screen once tasks 4-5 wire
+   * these up, which is exactly the kind of silent drift this contract
+   * exists to prevent. The one deliberate MERGE going the other way:
+   * `resource-form.tsx`'s yellow-500 draft-banner collapses into `warning`
+   * (amber) — Tailwind's own OKLCH hue distance from amber-500 is 16°
+   * (amber↔yellow) vs 22.5° for both amber↔orange and sky↔blue, and L/C are
+   * nearly identical (76.9%/0.188 vs 79.5%/0.184) — this reads as accidental
+   * drift (whoever wrote that banner grabbed "yellow" for the same "heads
+   * up" register everyone else spells "amber"), not a second meaning.
+   *
+   * FIX ROUND 1 (task 4): `-foreground` briefly carried two incompatible
+   * meanings in this file. Every OTHER `-foreground` pair here
+   * (`--primary-foreground`, `--destructive-foreground`, ...) is shadcn's
+   * own convention: near-white text ON A SOLID FILL of that colour. Task 3's
+   * severity `-foreground`s were something else — a severity's text colour
+   * on a TINTED background (`badge.tsx`'s 15% tint) — because a tinted
+   * badge was the only context that existed when task 3 measured them. Task
+   * 4 initially reused the name `-foreground` for that tinted-text value
+   * too, and it broke at the one real filled-surface site that exists
+   * today: `resource-wizard.tsx`'s completed-step circle
+   * (`bg-success text-success-foreground`) rendered dark-green-on-green at
+   * 2.19:1 — *worse* than the `text-white` it replaced. Split into two
+   * names so the shape (`bg-<x> text-<x>-foreground`) means the same thing
+   * for every token pair in this file, severity or not:
+   *   `--<severity>-foreground` — shadcn's meaning, restored: text on a
+   *     SOLID `bg-<severity>` fill. Near-white, reproducing what the
+   *     wizard's literal `text-white` actually rendered (`rgb(255, 255,
+   *     255)`) — the only filled-surface severity site that exists today.
+   *     Not repeated in `.dark`: the fill itself (`--success` etc.) doesn't
+   *     vary by mode either (see below), so neither does its contrasting
+   *     text. Only `--success-foreground` has a live consumer right now;
+   *     the other six carry the same value for symmetry within the family,
+   *     unverified against a real filled site of their own — see task 4's
+   *     fix-round report.
+   *   `--<severity>-emphasis` — task 3's original measurement, renamed,
+   *     VALUES the same COLOURS (see FIX ROUND 2 below for why the stored
+   *     FORM changed): a severity's text colour on a TINTED background
+   *     (`badge.tsx`'s `bg-<severity>/15`), genuinely different between
+   *     :root and .dark because the source (`text-emerald-700
+   *     dark:text-emerald-400` etc.) really does swap by `dark:` — see
+   *     .dark below.
+   *
+   * FIX ROUND 2 (task 4): every value below — the 7 base tints AND all 14
+   * `-emphasis` values (7 light + 7 dark) — is stored as Tailwind's OWN
+   * `oklch(...)` string, copied verbatim from the installed
+   * `tailwindcss@4.3.3`'s `theme.css`, NOT converted to hsl(). This
+   * contradicts task 1's project-wide convention of writing colours as
+   * `hsl(...)` (chosen there to keep the computed-style gate's diffs
+   * readable — see that task's report) — the severity tokens are the one
+   * deliberate exception, for a reason specific to them and nowhere else in
+   * this file: they exist to reproduce specific Tailwind palette entries
+   * exactly, and only Tailwind's own notation can guarantee that.
+   *
+   * Fix round 1 stored these as `hsl(...)`, converted from Tailwind's oklch
+   * source (oklch → linear sRGB → sRGB → HSL). That conversion is WRONG,
+   * not just imprecise, for any of these values that fall outside the sRGB
+   * gamut — and checking all 21 shades actually in play (7 severities × 3
+   * shades: 500 base, 700 and 400 emphasis) against sRGB, ALL BUT FIVE do:
+   * every emerald/amber/sky/orange shade, plus violet-500/400 and
+   * blue-500/400. Only zinc (all 3 shades) and violet-700/blue-700 land
+   * inside sRGB. `emerald-400` is the clearest example: Tailwind's
+   * `oklch(76.5% 0.177 163.223)` is a soft mint (`#34d399`,
+   * `rgb(52, 211, 153)`) — converting it via the naive per-channel-clip an
+   * hsl() round-trip forces (linear red channel computes to -0.031, which
+   * has no representation in hsl() at all) collapses it to
+   * `rgb(0, 214, 146)`, a visibly more saturated, wrongly-vivid green — the
+   * red channel is off by 52, not a rounding-scale error. This is not a
+   * bug in the conversion arithmetic (verified independently twice, by two
+   * different people, and both derivations agreed) — the mistake was
+   * converting through hsl() AT ALL for a colour hsl() cannot represent.
+   * The fix is to stop converting: the browser computes a literal
+   * `oklch(...)` custom property as `oklch(...)`, so storing Tailwind's own
+   * oklch string makes the computed value byte-identical to Tailwind's
+   * native utility classes, and the gate's diff disappears rather than
+   * approximating it.
+   *
+   * `--overlay` and the two `-foreground` whites below are NOT Tailwind
+   * palette entries (pure black / pure white, invented for this contract,
+   * not looked up), and pure black/white have zero chroma — there is no
+   * gamut to fall outside of, in any notation, so they stay in `hsl()` for
+   * readability; the notation-mismatch concern this fix round exists for
+   * does not apply to them. Confirmed by the pairing analysis in task 4's
+   * fix-round-2 report: the overlay's `hsl(0 0% 0%)` pairing was
+   * byte-identical against the live gate, no conversion issue.
+   *
+   * The base tint itself does NOT vary by mode in the source today (no
+   * `dark:bg-*` on any of these sites), so it is declared once here and NOT
+   * repeated in .dark. */
+  --success: oklch(69.6% 0.17 162.48); /* emerald-500 */
+  --success-foreground: hsl(0 0% 100%); /* text on a SOLID bg-success fill (not a palette colour) */
+  --success-emphasis: oklch(50.8% 0.118 165.612); /* emerald-700, text on a TINTED bg-success/15 */
+  --warning: oklch(76.9% 0.188 70.08); /* amber-500 */
+  --warning-foreground: hsl(0 0% 100%); /* text on a SOLID bg-warning fill (not a palette colour) */
+  --warning-emphasis: oklch(55.5% 0.163 48.998); /* amber-700, text on a TINTED bg-warning/15 */
+  --info: oklch(68.5% 0.169 237.323); /* sky-500 */
+  --info-foreground: hsl(0 0% 100%); /* text on a SOLID bg-info fill (not a palette colour) */
+  --info-emphasis: oklch(50% 0.134 242.749); /* sky-700, text on a TINTED bg-info/15 */
+  --neutral: oklch(55.2% 0.016 285.938); /* zinc-500 */
+  --neutral-foreground: hsl(0 0% 100%); /* text on a SOLID bg-neutral fill (not a palette colour) */
+  --neutral-emphasis: oklch(37% 0.013 285.805); /* zinc-700, text on a TINTED bg-neutral/15 */
+  --highlight: oklch(60.6% 0.25 292.717); /* violet-500 */
+  --highlight-foreground: hsl(0 0% 100%); /* text on a SOLID bg-highlight fill (not a palette colour) */
+  --highlight-emphasis: oklch(49.1% 0.27 292.581); /* violet-700, text on a TINTED bg-highlight/15 */
+  --active: oklch(62.3% 0.214 259.815); /* blue-500 */
+  --active-foreground: hsl(0 0% 100%); /* text on a SOLID bg-active fill (not a palette colour) */
+  --active-emphasis: oklch(48.8% 0.243 264.376); /* blue-700, text on a TINTED bg-active/15 */
+  --caution: oklch(70.5% 0.213 47.604); /* orange-500 */
+  --caution-foreground: hsl(0 0% 100%); /* text on a SOLID bg-caution fill (not a palette colour) */
+  --caution-emphasis: oklch(55.3% 0.195 38.402); /* orange-700, text on a TINTED bg-caution/15 */
+
+  /* Modal/sheet/alert-dialog backdrop veil. Was a literal `bg-black/80` in
+   * three primitives (alert-dialog.tsx, dialog.tsx, sheet.tsx) — black at a
+   * fixed lightness needs no light/dark variant, so this is declared once. */
+  --overlay: hsl(0 0% 0%);
+
+  --border: oklch(0.922 0 0);
+  --input: oklch(0.922 0 0);
+  /* Disabled-field surface. `disabled:opacity-50` (input/textarea/select
+   * trigger/command input) is shadcn's canonical disabled signal, and it
+   * works when the control's own foreground/background pair has enough
+   * luminance separation for a 50%-alpha fade to read as "faded". It stops
+   * working the moment a theme narrows that gap — a disabled field can then
+   * look pixel-identical to an enabled one (reported against a live theme).
+   * A dedicated background makes the signal independent of luminance
+   * contrast: the field visibly changes SURFACE, not just opacity, so the
+   * two cues reinforce each other instead of one silently doing nothing.
+   * Value equals --muted's shipped value on purpose (a muted surface, not a
+   * tint of --background) but is its own token, not `var(--muted)`, so a
+   * theme can tune "this field is inert" independently of `--muted`'s other
+   * jobs (zebra stripes, badges, etc. don't reason about disabled state). */
+  --input-disabled: oklch(0.97 0 0);
+  /* DEPARTURE from shadcn: v4's own default here is oklch(0.708 0 0), and it
+   * fails WCAG 1.4.11's 3:1 focus-indicator minimum in this kit — measured
+   * at 2.59:1 against --background and 2.38:1 against --muted/--accent/
+   * --secondary (the worse case, and the one call sites actually hit with
+   * no ring offset: primitives/button.tsx, input.tsx, select.tsx,
+   * textarea.tsx, badge.tsx and ~15 more). shadcn can afford 0.708 because
+   * its own components draw focus with `border-ring` PLUS `ring-ring/50
+   * ring-[3px]` — two signals; this kit kept the older single-signal
+   * treatment, an opaque `ring-2 ring-ring` with `outline-hidden` killing
+   * the native fallback, so the ring alone has to clear 3:1. Raised to
+   * 0.556 — the same lightness this file already uses for light
+   * --muted-foreground and dark --ring, not a new arbitrary stop — which
+   * clears 3:1 with margin in both places this ring lands:
+   *   - vs --background (oklch(1 0 0)):                           4.73:1
+   *   - vs --muted/--accent/--secondary (oklch(0.97 0 0)):         4.34:1
+   * Dark --ring is untouched: it already passes (4.18:1 on --background,
+   * 3.79:1 on --card/--popover/--sidebar). */
+  --ring: oklch(0.556 0 0);
+  --popover: oklch(1 0 0);
+  --popover-foreground: oklch(0.145 0 0);
+  --card: oklch(1 0 0);
+  --card-foreground: oklch(0.145 0 0);
+  --radius: 0.5rem;
+  --sidebar: oklch(0.985 0 0);
+  --sidebar-foreground: oklch(0.145 0 0);
+  --sidebar-primary: oklch(0.205 0 0);
+  --sidebar-primary-foreground: oklch(0.985 0 0);
+  --sidebar-accent: oklch(0.97 0 0);
+  --sidebar-accent-foreground: oklch(0.205 0 0);
+  --sidebar-border: oklch(0.922 0 0);
+  --sidebar-ring: oklch(0.708 0 0);
+
+  /* Tailwind v4's built-in default `--font-sans` is not the same stack v3
+   * shipped (verified: `tailwindcss@3.4.19`'s
+   * `stubs/config.full.js` → `theme.fontFamily.sans` vs v4's
+   * `tailwindcss/theme.css` → `--font-sans`). Neither the old preset nor
+   * this file ever pinned `font-sans` before, so the v4 default was free to
+   * leak through onto nearly every element on every page — a site-wide,
+   * unaccepted visual change caught by the computed-style gate (task 7).
+   * Pinning the exact v3 value here keeps the migration invisible, per plan
+   * B's contract: nothing visible changes except what's on the accepted
+   * list. This is the BASE value only — declared in this unlayered `:root`
+   * (not inside `@theme inline`) and re-exposed to `@theme inline` below via
+   * `var(--font-sans)`, the same indirection the colour tokens above use.
+   * That is load-bearing, not decorative: a value written as a literal
+   * inside `@theme inline` gets compiled into the generated utility at
+   * build time and emits no custom property at all, so a later theme's
+   * runtime `:root { --font-sans: … }` would compile fine and do nothing.
+   * Declaring it here first means Tailwind's own `@layer theme` declaration
+   * of `--font-sans` loses to this unlayered one regardless of source
+   * order, and a theme injected later at runtime (also unlayered) wins over
+   * this one in turn — so a later plan CAN override `--font-sans` per-theme.
+   * Confirmed by compiling a fixture against the built stylesheet, then
+   * again with an extra unlayered `:root { --font-sans: "Comic Sans MS" }`
+   * appended: `.font-sans` picked up the override (see the plan's fix
+   * report for both compiled outputs).
+   * `--font-mono` needed no such pin: v3's and v4's default mono stacks are
+   * byte-identical (same two files), confirmed by the gate showing zero
+   * font-family drift on any `font-mono` element. */
+  --font-sans: ui-sans-serif, system-ui, sans-serif, "Apple Color Emoji", "Segoe UI Emoji",
+    "Segoe UI Symbol", "Noto Color Emoji";
+
+  /* v4 redefines every named font-size's paired line-height as a UNITLESS
+   * ratio (e.g. `--text-xs--line-height: calc(1 / 0.75)`); v3 used a FIXED
+   * length (`1rem`) instead. CSS inherits a number by recomputing it at each
+   * descendant from THAT descendant's own font-size; it inherits a length
+   * unchanged. So the two are only equivalent when an element's own
+   * font-size matches the ancestor supplying its line-height — anywhere a
+   * smaller/larger override (`text-[10px]`, a nested heading, ...) sits
+   * inside a `text-*` ancestor, v4 silently recomputes a different
+   * line-height than v3 did. Task 7's computed-style gate caught exactly
+   * one instance of this (the command palette's `text-[10px]` kbd chips,
+   * nested in `text-xs`, went 16px -> 13.3333px) but the mechanism is
+   * general, not particular to kbd — `resource-form.tsx`,
+   * `resource-show.tsx`, `file.tsx` and others carry `text-[10px]`/
+   * `text-[11px]` on routes this gate doesn't cover, and would have drifted
+   * silently. Pinning every named size actually used in this kit
+   * (`grep -rE 'text-(xs|sm|base|lg|xl|2xl|3xl)\b' packages/ui-shadcn/src
+   * apps/playground/src`) to v3's fixed value closes the whole class of bug
+   * at the token level, not just the four kbd elements that happened to be
+   * gated — those per-element `leading-[1rem]` pins have been removed as
+   * redundant. Values read verbatim from the installed
+   * `tailwindcss@3.4.19`'s `stubs/config.full.js` `fontSize` block.
+   * `text-4xl` and up are unused except `text-8xl`, which v3 and v4 both
+   * define as the unitless ratio `1` — identical in both, no pin needed.
+   * Declared here (unlayered `:root`), not as a literal inside `@theme
+   * inline`, for the same runtime-override reason as `--font-sans` above. */
+  --text-xs--line-height: 1rem;
+  --text-sm--line-height: 1.25rem;
+  --text-base--line-height: 1.5rem;
+  --text-lg--line-height: 1.75rem;
+  --text-xl--line-height: 1.75rem;
+  --text-2xl--line-height: 2rem;
+  --text-3xl--line-height: 2.25rem;
+
+  /* Chart palette. A theme with no opinion on data-viz colour still needs
+   * five slots to land in — these are shadcn v4's own default chart palette
+   * (its current oklch chart preset, not the older HSL chart-docs example
+   * this file previously carried: https://v3.shadcn.com/docs/components/chart),
+   * stored as oklch, not hsl, for the same reason the severity scale is: a
+   * token whose job is to reproduce a specific external palette entry is
+   * stored in that palette's own notation. Genuinely different between
+   * light and dark, not a lazy copy: the light set is tuned to read against
+   * a white canvas, the dark set trades some of that saturation for
+   * mid-lightness so the same five hues stay legible on a dark surface.
+   * Nothing in this kit renders a chart yet, so there's no existing look
+   * these numbers could contradict — first-run defaults for whenever one
+   * shows up, and immediately overridable by any theme that brings its own
+   * five. */
+  --chart-1: oklch(0.646 0.222 41.116);
+  --chart-2: oklch(0.6 0.118 184.704);
+  --chart-3: oklch(0.398 0.07 227.392);
+  --chart-4: oklch(0.828 0.189 84.429);
+  --chart-5: oklch(0.769 0.188 70.08);
+
+  /* Tailwind v4's own default --font-serif, verbatim from the installed
+   * tailwindcss@4.3.3's theme.css. Unlike --font-sans above, nothing in this
+   * kit sets `font-serif` anywhere today, so there is no prior look to
+   * preserve here — this is just the first-run default a pasted theme can
+   * override. Declared here (unlayered `:root`), re-exposed via `@theme
+   * inline` below through `var(--font-serif)`, for the identical
+   * runtime-override reason spelled out above --font-sans. */
+  --font-serif: ui-serif, Georgia, Cambria, "Times New Roman", Times, serif;
+
+  /* Tailwind v4's own defaults for these two (theme.css: `--spacing:
+   * 0.25rem`, `--tracking-normal: 0em`), pinned here explicitly rather than
+   * left to Tailwind's built-in `@layer theme` default. `--spacing` was
+   * already runtime-overridable even before this line — Tailwind emits its
+   * own default inside a cascade layer, which any unlayered `:root`
+   * override (ours or a theme's) already beats regardless of source order —
+   * but declaring it here makes that contract visible in this file instead
+   * of implicit in Tailwind's internals, matches how every other themeable
+   * token in this file is declared, and pins the value against any future
+   * upstream default change. `--tracking-normal` had no existing Tailwind
+   * default to inherit an override from in this way (see the tracking-*
+   * family below), so for it this declaration is load-bearing, not just
+   * documentation. */
+  --spacing: 0.25rem;
+  --tracking-normal: 0em;
+
+  /* Six raw shadow components, in the shape tweakcn's own default preset
+   * ships them (color/opacity/blur/spread/offset-x/offset-y) — so that a
+   * theme built around varying these six has somewhere for them to land.
+   * Nothing in THIS file reads them: Tailwind's stock shadow scale is not
+   * one shadow linearly scaled by a color/opacity/blur/spread/offset tuple,
+   * it is hand-tuned per step, and several steps (md, lg, xl) stack TWO
+   * box-shadow layers with independently-chosen blur/spread/offset pairs
+   * that no single set of six numbers reproduces via calc(). The eight
+   * computed shadows below are pinned to Tailwind's actual literal values
+   * instead of being assembled from these six — see the comment there and
+   * the task report's before/after compile diff for the proof. */
+  --shadow-color: hsl(0 0% 0%);
+  --shadow-opacity: 0.1;
+  --shadow-blur: 3px;
+  --shadow-spread: 0px;
+  --shadow-offset-x: 0px;
+  --shadow-offset-y: 1px;
+
+  /* Eight computed shadows. Values are copied verbatim from the installed
+   * tailwindcss@4.3.3's theme.css/index.css default shadow scale (`0 1px
+   * rgb(0 0 0 / 0.05)` through `0 25px 50px -12px rgb(0 0 0 / 0.25)`) —
+   * checked by reading that file, not from memory — so every `shadow-*`
+   * utility keeps rendering exactly what it renders today; see the task
+   * report for the compiled-fixture diff proving it. Deliberately NOT
+   * calc()'d from the six raw components above (see that comment). Declared
+   * here in the unlayered `:root`, not as literals inside `@theme inline`,
+   * for the same runtime-override reason as --font-sans: the indirection
+   * through `var(--shadow-x)` is what lets a theme's own unlayered `:root`
+   * override win later. */
+  --shadow-2xs: 0 1px rgb(0 0 0 / 0.05);
+  --shadow-xs: 0 1px 2px 0 rgb(0 0 0 / 0.05);
+  --shadow-sm: 0 1px 3px 0 rgb(0 0 0 / 0.1), 0 1px 2px -1px rgb(0 0 0 / 0.1);
+  --shadow: 0 1px 3px 0 rgb(0 0 0 / 0.1), 0 1px 2px -1px rgb(0 0 0 / 0.1);
+  --shadow-md: 0 4px 6px -1px rgb(0 0 0 / 0.1), 0 2px 4px -2px rgb(0 0 0 / 0.1);
+  --shadow-lg: 0 10px 15px -3px rgb(0 0 0 / 0.1), 0 4px 6px -4px rgb(0 0 0 / 0.1);
+  --shadow-xl: 0 20px 25px -5px rgb(0 0 0 / 0.1), 0 8px 10px -6px rgb(0 0 0 / 0.1);
+  --shadow-2xl: 0 25px 50px -12px rgb(0 0 0 / 0.25);
+
+  /* Overlay timing. Declared here, in the unlayered `:root`, for the same
+   * reason the shadows and fonts are: a theme pasted at runtime (tweakcn
+   * emits `:root` and `.dark` blocks, and `stripThemeCss` keeps exactly
+   * those) can then retime the whole UI along with recolouring it.
+   *
+   * These reach the animations without any new machinery:
+   * `duration-[var(--duration-overlay)]` sets Tailwind's `--tw-duration`
+   * and `ease-[var(--ease-overlay)]` sets `--tw-ease`, and
+   * `tw-animate-css` declares
+   *   --animate-in: enter var(--tw-animation-duration, var(--tw-duration,.15s)) var(--tw-ease, ease) …
+   * — i.e. it already reads both. Verified against the package source.
+   *
+   * `--duration-panel` is separate because a sheet travels the width of
+   * its edge, not 5% of its own size like a zooming dialog; the same
+   * number would read as a snap on one and a crawl on the other. */
+  --duration-overlay: 200ms;
+  --duration-panel: 300ms;
+  --ease-overlay: cubic-bezier(0.16, 1, 0.3, 1);
+}
+
+.dark {
+  --background: oklch(0.145 0 0);
+  --foreground: oklch(0.985 0 0);
+  --primary: oklch(0.922 0 0);
+  --primary-foreground: oklch(0.205 0 0);
+  --secondary: oklch(0.269 0 0);
+  --secondary-foreground: oklch(0.985 0 0);
+  --muted: oklch(0.269 0 0);
+  /* Re-measured against the new neutral dark surfaces (final-review-findings.md
+   * M3), value unchanged: 7.63:1 on --background, 6.91:1 on
+   * --card/--popover/--sidebar — both comfortably clear WCAG AA's 4.5:1. */
+  --muted-foreground: oklch(0.708 0 0);
+  --accent: oklch(0.269 0 0);
+  --accent-foreground: oklch(0.985 0 0);
+  /* ⚠️ Dark needs BOTH values changed together: one token serves red TEXT on
+     a dark surface AND a solid red FILL under a label, which pull in opposite
+     directions. At 0 62% 50% the fill passed (4.87:1) while red menu text
+     measured 3.51:1. A lighter red with a DARK label satisfies both —
+     5.29:1 either way — and is the conventional dark-mode treatment.
+     shadcn v4's own candidate (`oklch(0.704 0.191 22.216)`) was measured
+     against the new dark --background too: red text passes at 6.84:1, but
+     its white --destructive-foreground on that same fill only reaches
+     2.89:1 — below WCAG AA's 4.5:1 — so this half keeps the hand-tuned
+     values above instead of adopting shadcn's.
+     M1 (final-review-findings.md): --destructive-foreground was still the
+     slate hsl(222 47% 11%) named at the :root comment's :56 as exactly what
+     this whole change exists to remove — the last surviving occurrence.
+     Neutralised to oklch(0.145 0 0) (this file's own near-black stop —
+     light --foreground / dark --background). Re-measured against the dark
+     --destructive fill above: 5.31:1 -> 5.87:1, an improvement, not just a
+     wash. */
+  --destructive: hsl(0 72% 64%);
+  --destructive-foreground: oklch(0.145 0 0);
+
+  /* Severity-scale `-emphasis` overrides, dark-mode half — see the long
+   * comment on the :root block above (fix rounds 1 and 2) for where these
+   * come from and why they're `oklch(...)`, not `hsl(...)` (fix round 2:
+   * Tailwind's own oklch values verbatim, not converted — several of these
+   * fall outside sRGB gamut and an hsl() conversion silently mangles them).
+   * Only `-emphasis` (tinted-badge text) varies by `.dark` — the source
+   * genuinely swaps `text-emerald-700 dark:text-emerald-400` etc.
+   * `-foreground` (solid-fill text) is NOT repeated here, for the same
+   * reason the base tints aren't: neither side of that pair varies by mode
+   * in the source today. */
+  --success-emphasis: oklch(76.5% 0.177 163.223); /* emerald-400 */
+  --warning-emphasis: oklch(82.8% 0.189 84.429); /* amber-400 */
+  --info-emphasis: oklch(74.6% 0.16 232.661); /* sky-400 */
+  --neutral-emphasis: oklch(70.5% 0.015 286.067); /* zinc-400 */
+  --highlight-emphasis: oklch(70.2% 0.183 293.541); /* violet-400 */
+  --active-emphasis: oklch(70.7% 0.165 254.624); /* blue-400 */
+  --caution-emphasis: oklch(75% 0.183 55.934); /* orange-400 */
+
+  /* Re-measured against the new neutral dark surfaces (final-review-findings.md
+   * M3): --border/10 reads 1.25:1 against the page --background and 1.32:1
+   * against a --card; the old opaque dark border (hsl(217 33% 22%) on the
+   * old slate hsl(222 47% 11%) background) was 1.42:1 — fainter, but in the
+   * same family. A border is a structural divider, not text, so WCAG's
+   * text-contrast minimums don't gate it; recorded for the next person who
+   * wants to know how much margin is left, not because it's failing. */
+  --border: oklch(1 0 0 / 10%);
+  /* --input/15 reads 1.74:1 against a --card and 1.47:1 over the page
+   * --background — see the --border comment above for why these are
+   * recorded despite not being text. */
+  --input: oklch(1 0 0 / 15%);
+  /* Dark half of --input-disabled above — same relationship to --muted's
+   * dark value that the light half has. */
+  --input-disabled: oklch(0.269 0 0);
+  --ring: oklch(0.556 0 0);
+  --popover: oklch(0.205 0 0);
+  --popover-foreground: oklch(0.985 0 0);
+  --card: oklch(0.205 0 0);
+  --card-foreground: oklch(0.985 0 0);
+  --sidebar: oklch(0.205 0 0);
+  --sidebar-foreground: oklch(0.985 0 0);
+  /* DEPARTURE from shadcn: it ships oklch(0.488 0.243 264.376) here — the
+   * same blue as --chart-1 — and that colour lands under the active nav
+   * item. Keeping the neutral --primary value instead; a blue active row is
+   * exactly the tint this palette change set out to remove. */
+  --sidebar-primary: oklch(0.922 0 0);
+  --sidebar-primary-foreground: oklch(0.205 0 0);
+  --sidebar-accent: oklch(0.269 0 0);
+  --sidebar-accent-foreground: oklch(0.985 0 0);
+  --sidebar-border: oklch(1 0 0 / 10%);
+  --sidebar-ring: oklch(0.556 0 0);
+
+  /* Dark half of the chart palette declared in :root above — see that
+   * comment for the source and why the two sets of five are genuinely
+   * different values, not a copy. */
+  --chart-1: oklch(0.488 0.243 264.376);
+  --chart-2: oklch(0.696 0.17 162.48);
+  --chart-3: oklch(0.769 0.188 70.08);
+  --chart-4: oklch(0.627 0.265 303.9);
+  --chart-5: oklch(0.645 0.246 16.439);
+}
+
+/* Maps tokens to utilities. `inline` is required: without it, values get
+ * copied in at build time and swapping the variable at runtime stops
+ * working — i.e. plan D's runtime themes won't work. */
+@theme inline {
+  --color-background: var(--background);
+  --color-foreground: var(--foreground);
+  --color-primary: var(--primary);
+  --color-primary-foreground: var(--primary-foreground);
+  --color-secondary: var(--secondary);
+  --color-secondary-foreground: var(--secondary-foreground);
+  --color-muted: var(--muted);
+  --color-muted-foreground: var(--muted-foreground);
+  --color-accent: var(--accent);
+  --color-accent-foreground: var(--accent-foreground);
+  --color-destructive: var(--destructive);
+  --color-destructive-foreground: var(--destructive-foreground);
+
+  /* Severity scale — see the :root block above for the meaning → colour
+   * derivation and fix round 1's `-foreground`/`-emphasis` split. `inline`
+   * here is exactly as load-bearing as it is for every other token above:
+   * without it, `bg-success/15` etc. cannot resolve to a runtime
+   * `color-mix()` against a swappable custom property. */
+  --color-success: var(--success);
+  --color-success-foreground: var(--success-foreground);
+  --color-success-emphasis: var(--success-emphasis);
+  --color-warning: var(--warning);
+  --color-warning-foreground: var(--warning-foreground);
+  --color-warning-emphasis: var(--warning-emphasis);
+  --color-info: var(--info);
+  --color-info-foreground: var(--info-foreground);
+  --color-info-emphasis: var(--info-emphasis);
+  --color-neutral: var(--neutral);
+  --color-neutral-foreground: var(--neutral-foreground);
+  --color-neutral-emphasis: var(--neutral-emphasis);
+  --color-highlight: var(--highlight);
+  --color-highlight-foreground: var(--highlight-foreground);
+  --color-highlight-emphasis: var(--highlight-emphasis);
+  --color-active: var(--active);
+  --color-active-foreground: var(--active-foreground);
+  --color-active-emphasis: var(--active-emphasis);
+  --color-caution: var(--caution);
+  --color-caution-foreground: var(--caution-foreground);
+  --color-caution-emphasis: var(--caution-emphasis);
+  --color-overlay: var(--overlay);
+
+  --color-popover: var(--popover);
+  --color-popover-foreground: var(--popover-foreground);
+  --color-card: var(--card);
+  --color-card-foreground: var(--card-foreground);
+  --color-border: var(--border);
+  --color-input: var(--input);
+  --color-input-disabled: var(--input-disabled);
+  --color-ring: var(--ring);
+  --color-sidebar: var(--sidebar);
+  --color-sidebar-foreground: var(--sidebar-foreground);
+  --color-sidebar-primary: var(--sidebar-primary);
+  --color-sidebar-primary-foreground: var(--sidebar-primary-foreground);
+  --color-sidebar-accent: var(--sidebar-accent);
+  --color-sidebar-accent-foreground: var(--sidebar-accent-foreground);
+  --color-sidebar-border: var(--sidebar-border);
+  --color-sidebar-ring: var(--sidebar-ring);
+
+  --color-chart-1: var(--chart-1);
+  --color-chart-2: var(--chart-2);
+  --color-chart-3: var(--chart-3);
+  --color-chart-4: var(--chart-4);
+  --color-chart-5: var(--chart-5);
+
+  --radius-lg: var(--radius);
+  --radius-md: calc(var(--radius) - 2px);
+  --radius-sm: calc(var(--radius) - 4px);
+  /* shadcn's canonical v4 block also derives -xl from the base; without this
+   * line -xl stayed pinned at Tailwind's literal 0.75rem, so a themed
+   * `--radius` rescaled every corner except `rounded-xl` sites (e.g. the
+   * sidebar's inset-variant shell in primitives/sidebar.tsx). */
+  --radius-xl: calc(var(--radius) + 4px);
+
+  /* All declared in the unlayered `:root` above, not as literals here —
+   * see the comment there for why the indirection is load-bearing
+   * (runtime overridability), not decorative. */
+  --font-sans: var(--font-sans);
+  --font-serif: var(--font-serif);
+  --text-xs--line-height: var(--text-xs--line-height);
+  --text-sm--line-height: var(--text-sm--line-height);
+  --text-base--line-height: var(--text-base--line-height);
+  --text-lg--line-height: var(--text-lg--line-height);
+  --text-xl--line-height: var(--text-xl--line-height);
+  --text-2xl--line-height: var(--text-2xl--line-height);
+  --text-3xl--line-height: var(--text-3xl--line-height);
+
+  --spacing: var(--spacing);
+
+  /* Only --tracking-normal is a real declared token in :root (the base a
+   * theme sets); the other five are computed from it here so overriding the
+   * base ripples through the whole scale — the same shape tweakcn's own
+   * generated output uses. At the default --tracking-normal: 0em these
+   * resolve to exactly Tailwind's own built-in absolute values
+   * (-0.05em/-0.025em/0.025em/0.05em/0.1em), so nothing currently rendered
+   * moves. */
+  --tracking-tighter: calc(var(--tracking-normal) - 0.05em);
+  --tracking-tight: calc(var(--tracking-normal) - 0.025em);
+  --tracking-normal: var(--tracking-normal);
+  --tracking-wide: calc(var(--tracking-normal) + 0.025em);
+  --tracking-wider: calc(var(--tracking-normal) + 0.05em);
+  --tracking-widest: calc(var(--tracking-normal) + 0.1em);
+
+  --shadow-2xs: var(--shadow-2xs);
+  --shadow-xs: var(--shadow-xs);
+  --shadow-sm: var(--shadow-sm);
+  --shadow: var(--shadow);
+  --shadow-md: var(--shadow-md);
+  --shadow-lg: var(--shadow-lg);
+  --shadow-xl: var(--shadow-xl);
+  --shadow-2xl: var(--shadow-2xl);
+}
+
+/* This can now ship from the package — in v3 it couldn't, because plain CSS
+ * doesn't pass through @apply, and every adopter had to copy this rule
+ * themselves. Its absence is invisible in light mode and gives 27 glowing
+ * borders out of 99 in dark. */
+@layer base {
+  * {
+    @apply border-border;
+  }
+  body {
+    @apply bg-background text-foreground;
+  }
+
+  /* v4 preflight makes buttons `cursor: default`; v3 gave them `pointer`.
+   * Restoring it here keeps the migration invisible to users. */
+  button:not(:disabled),
+  [role="button"]:not(:disabled) {
+    cursor: pointer;
+  }
+
+  /* The other half of v3's preflight pair. v3 shipped BOTH
+   * `button, [role="button"] { cursor: pointer }` AND
+   * `:disabled { cursor: default }`; v4 dropped both, and the rule above
+   * only restores the first half via a `:not(:disabled)` guard, which stops
+   * a disabled control from claiming `pointer` but does not force it back
+   * to `default`. `cursor` inherits, so without this a disabled control
+   * inherits whatever cursor its ancestor set instead of being pinned —
+   * real nestings exist (clickable rows in `resource-list.tsx`,
+   * `relation-picker-dialog.tsx`, `<summary className="cursor-pointer">`
+   * in `resource-form.tsx` and `list-error-state.tsx`), and any disabled
+   * input without an explicit `disabled:cursor-not-allowed` loses v3's
+   * behaviour too. */
+  :disabled {
+    cursor: default;
+  }
+
+  /* v4 preflight's `*, ::before, ::after, ::backdrop, ::file-selector-button
+   * { padding: 0 }` is a genuinely universal reset. v3's never was: it only
+   * zeroed padding on `button/input/optgroup/select/textarea`
+   * (`tailwindcss@3.4.19` .../lib/css/preflight.css) and never touched
+   * `th`/`td`, so the browser's own UA default (`th, td { padding: 1px }`)
+   * was left standing under v3. `TableHead`/`TableCell`
+   * (`packages/ui-shadcn/src/primitives/table.tsx`) never set their own
+   * vertical padding — only `px-2` horizontal, with `h-10` + `align-middle`
+   * for row height — so v4's broader reset silently shaved 1px off every
+   * table row's top/bottom padding (caught by task 7's computed-style gate
+   * on the `list` route). Restoring the pre-v4 default here, same as the
+   * cursor rule above, keeps row heights identical to v3. `px-2` still wins
+   * on left/right: Tailwind's `@layer utilities` always beats `@layer base`
+   * regardless of specificity, and this shorthand only reaches top/bottom in
+   * practice. */
+  th,
+  td {
+    padding: 1px;
+  }
+}
+
+/* Standard root. `text-base` therefore computes to 16px on mobile; editable
+ * controls that need compact desktop typography opt into `md:text-sm` locally
+ * instead of globally rescaling rem-based dimensions.
+ */
+html {
+  font-size: 16px;
+}
+
+/* Scrollbars follow the palette.
+ *
+ * Unstyled, they keep the operating system's own colours, so under any theme
+ * they are the one chrome that never repaints — which is exactly how they
+ * looked wrong once themes arrived. There are 42 scroll containers across the
+ * kit and the app, so this belongs here as one rule rather than at each site.
+ *
+ * `--border` for the thumb and a transparent track: the thumb reads as a
+ * boundary rather than as content, it inherits every theme automatically, and
+ * no new token enters the contract. On hover it steps up to
+ * `--muted-foreground` so the target is findable without being loud at rest.
+ *
+ * ⚠️ What CSS does NOT decide here is whether the bar overlays the content or
+ * takes layout width. There is no standard property for it — CSS Scrollbars
+ * Level 1 defines only `scrollbar-width` and `scrollbar-color`, `overflow:
+ * overlay` was removed, and `scrollbar-gutter` reserves space rather than
+ * lifting the bar out of flow. Overlay versus classic is the operating
+ * system's and browser's call: macOS set to show bars automatically overlays
+ * them, Windows and Linux with classic settings do not. If content visibly
+ * jumps as a container crosses the fits/does-not-fit boundary, the fix is
+ * `scrollbar-gutter: stable` on that container — it always reserves, so the
+ * width stops changing. It is deliberately NOT applied globally, because on a
+ * platform that already overlays it would carve out a gutter nobody asked for.
+ *
+ * The two strips that hide their scrollbar on purpose — the tab rail in
+ * `tabs-layout.tsx` and the mobile rail in `secondary-sidebar-layout.tsx` —
+ * set `scrollbar-width: none` themselves and are unaffected: `none` wins over
+ * the `thin` set here by ordinary cascade.
+ */
+@layer base {
+  * {
+    scrollbar-width: thin;
+    scrollbar-color: var(--border) transparent;
+  }
+
+  /* Safari does not implement the standard properties above; these reproduce
+   * the same look through the WebKit pseudo-elements. Chromium honours both
+   * and the standard ones win, so this costs nothing there. */
+  *::-webkit-scrollbar {
+    width: 10px;
+    height: 10px;
+  }
+
+  *::-webkit-scrollbar-track {
+    background: transparent;
+  }
+
+  *::-webkit-scrollbar-thumb {
+    background-color: var(--border);
+    border: 3px solid transparent;
+    border-radius: 9999px;
+    background-clip: content-box;
+  }
+
+  *::-webkit-scrollbar-thumb:hover {
+    background-color: var(--muted-foreground);
+  }
+
+  *::-webkit-scrollbar-corner {
+    background: transparent;
+  }
+}