@bsuite/theme 0.13.0 → 1.0.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bsuite/theme",
-  "version": "0.13.0",
+  "version": "1.0.0",
   "type": "module",
   "license": "UNLICENSED",
   "publishConfig": {

package/src/css/utilities.css

@@ -142,3 +142,48 @@
 @media (forced-colors: active) {
   .text-gradient-accent { background-image: none; color: CanvasText; }
 }
+
+/* ── NAV / SWITCHER GRADIENT UNDERLINE ───────────────────────────────────
+   TH-6. Promoted from crm7/src/index.css, 2026-08-17.
+
+   The operator asked for the nav gradient underline in every app. It was
+   unimplementable anywhere but crm7, because the treatment existed only in
+   crm7's own stylesheet — 3 files in one app (the two declarations here plus
+   two call sites), and ZERO occurrences in this package or in the other five
+   apps. A request that needs a copy-paste to satisfy is a packaging defect,
+   not a feature request, and copying it would have produced six declarations
+   drifting apart the way `--bg-shell-elevated` did.
+
+   It paints from --gradient-accent, which this package already owns, so
+   nothing app-specific came with it.
+
+   TWO FORMS, ONE PAINT SOURCE — that pairing is the point. Keeping them
+   adjacent is what makes "the switcher and the active nav item match" a fact
+   about this file rather than two declarations someone has to remember to
+   keep in step:
+
+     `-span`   the caller already renders its own absolutely-positioned
+               element for the rule (crm7's tenant switcher does).
+     `::after` the caller does not, so the rule is generated for it (the
+               navigation items). REQUIRES `position: relative` on the host —
+               without it the rule anchors to the nearest positioned ancestor
+               and lands somewhere else on the page.
+
+   The `-span` form carries no geometry on purpose: the caller owns its own
+   inset/height/opacity, and crm7's switcher sets `opacity-70` with a
+   `group-hover:opacity-100` transition. Only the paint is shared. */
+.bsuite-gradient-underline-span {
+  background: var(--gradient-accent);
+}
+
+.bsuite-gradient-underline::after {
+  content: '';
+  position: absolute;
+  inset-inline: 0.5rem;
+  bottom: 0.125rem;
+  height: 0.125rem;
+  border-radius: 9999px;
+  background: var(--gradient-accent);
+  opacity: 0.7;
+  pointer-events: none;
+}

package/src/css/vars.css

@@ -33,7 +33,8 @@
  *   --light-bg-accent ship as oklch(1 0 0.5) — theme-audit-ok: naming the
  *   value that was REMOVED — and render every shadcn card
  *   and popover pure white. "White" here means oklch(0.982 0.002 248)
- *   (#f8f9fa); the lightest surface is bg-panel at L=0.994.
+ *   theme-audit-ok: naming the equivalent hex for a reader's reference, not
+ *   consuming it — (#f8f9fa); the lightest surface is bg-panel at L=0.994.
  *
  * OKLCH format is MANDATORY for all new tokens. No hex/rgb/hsl.
  * Syntax: oklch(L C H) — L=lightness 0–1, C=chroma 0–0.4, H=hue 0–360.
@@ -68,8 +69,9 @@
   --neon-electric-deep:  oklch(0.380 0.140 270);   /* secondary action */
 
   /* The two words the estate uses loosely, pinned to values. Operator ruling
-     2026-08-02 ("white is primary: #f8f9fa") in terms: "define --white and
-     --black once in the token source and reference them everywhere; never
+     2026-08-02 ("white is primary: #f8f9fa" — theme-audit-ok: naming the
+     ruling's literal, not consuming it; the tokens below are oklch) in terms:
+     "define --white and --black once in the token source and reference them everywhere; never
      write either literal inline." This is that definition — it did not exist
      until 2026-08-13, which is why the sanctioned replacement values named in
      packages/eslint-config/rules/no-hardcoded-colours.js had no token to point
@@ -294,6 +296,43 @@
   --role-border:       var(--light-border);
   --role-border-strong: oklch(0.880 0.008 250);
 
+  /* --role-border-interactive — TH-5 / bsuite#1958, the operator's
+     "unstyled button".
+     ------------------------------------------------------------------
+     WCAG 1.4.11 (non-text contrast) requires 3:1 for the visual boundary
+     that IDENTIFIES a user-interface component — the outline of a text
+     input, a select, an `outline`-variant button. It does NOT require 3:1
+     of a decorative hairline separating two filled surfaces, which is what
+     `--role-border` is for. Those are two different jobs and they had one
+     token, so the stricter job inherited the looser value.
+
+     MEASURED, light mode, OKLCH -> linear-sRGB -> WCAG relative luminance
+     (the same pipeline the text scale above is measured with, positive-
+     controlled by reproducing this file's own recorded dark figures of
+     3.36:1 and 3.61:1 for --role-border-strong to two decimals):
+
+       --role-border        vs --role-bg-panel   1.12:1   <- the filed defect
+       --role-border        vs --role-bg-surface 1.13:1
+       --role-border        vs --role-bg-sunken  1.01:1   <- worst live case
+       --role-border-strong vs --role-bg-panel   1.35:1
+
+     So re-pointing at the strongest EXISTING light token does not fix it —
+     1.35:1 is still less than half the floor. This role needs a value that
+     does not exist in the light scale yet, and here it is.
+
+     oklch(0.56 0.015 260) is from the D2C source-of-truth document (the
+     palette whitelist accepts it) and clears 3:1 on every light surface
+     role with margin, so no call site has to know which surface it landed on:
+
+       vs --role-bg-surface 4.42:1     vs --role-bg-panel  4.39:1
+       vs --role-bg-input   4.18:1     vs --role-bg-body   4.15:1
+       vs --role-bg-sunken  3.88:1  <- worst case, still +29% over the floor
+
+     Bound to shadcn's `--input` below, which is what `border-input` on every
+     Input/Select/Textarea and the Button `outline` variant resolves through.
+     That binding is the whole point: a token nothing invokes is TH-8. */
+  --role-border-interactive: oklch(0.56 0.015 260);
+
   /* Scrim — the veil behind a modal, and the reason `bg-black/N` survived   theme-audit-ok: prose
      everywhere else. It was the single most duplicated pure endpoint in the
      tree (9 sites across nav-core, page-builder and schema-builder) for one
@@ -357,7 +396,14 @@
   --destructive:        var(--role-destructive);
   --destructive-foreground: var(--text-on-error);
   --border:             var(--role-border);
-  --input:              var(--role-border);
+  /* `--input` is shadcn's INTERACTIVE boundary — `border-input` is on every
+     Input, Select, Textarea and the Button `outline` variant. It pointed at
+     --role-border, the decorative hairline, which measures 1.12:1 against the
+     panel: WCAG 1.4.11 wants 3:1 and the operator simply called it "an
+     unstyled button" (bsuite#1958). Now bound to the role built for the job.
+     `--border` deliberately stays on --role-border: separating two filled
+     surfaces is not a component boundary and does not carry the 3:1 duty. */
+  --input:              var(--role-border-interactive);
   --ring:               var(--role-primary);
 
   /* ============================================================
@@ -583,13 +629,45 @@
      light, 0.320/0.420 dark). Only the D2C theme was half-defined, which is
      why nobody reading the corporate theme would spot it.
 
-     Value is oklch(0.52 0.02 248) from the D2C source-of-truth document, so
-     the palette whitelist accepts it. It sits +0.09 L above `--dark-border`
-     (0.428), mirroring the light pair's step, and measures 3.36:1 against
-     `--role-bg-panel` and 3.61:1 against `--role-bg-sunken` — clearing the
-     WCAG 1.4.11 non-text-contrast floor of 3:1 on both dark surfaces.
-     `--role-border` itself is 2.26:1, which is why "strong" has to exist. */
-  --role-border-strong: oklch(0.52 0.02 248);
+     Value WAS oklch(0.52 0.02 248) from the D2C source-of-truth document,
+     recorded here as 3.36:1 against `--role-bg-panel` and 3.61:1 against
+     `--role-bg-sunken`. Both figures re-measured exactly on 2026-08-17 —
+     which is how the instrument for TH-5 was positive-controlled.
+
+     WHAT THAT PAIR OF FIGURES MISSED (TH-5, 2026-08-17): only two of the five
+     dark surface roles were ever checked. Against the third —
+     `--role-bg-input` oklch(0.240 0.020 260), the LIGHTEST dark surface and
+     the one an interactive boundary actually sits on — 0.52 measures 2.99:1.
+     Under the 3:1 floor, by a rounding margin, on precisely the surface the
+     rule exists for. Nothing was wrong with the arithmetic; the surface list
+     was short, so the worst case was never in it.
+
+     Raised to oklch(0.55 0.015 250) — also from the source-of-truth document,
+     +0.03 L, visually indistinguishable, and decisive:
+
+       vs --role-bg-body   3.98:1     vs --role-bg-surface 3.65:1
+       vs --role-bg-panel  3.81:1     vs --role-bg-sunken  4.09:1
+       vs --role-bg-input  3.40:1  <- the case that used to be 2.99:1
+
+     `--role-border` itself is 2.26:1, which is why "strong" has to exist.
+     The contract test now measures all five surfaces in both modes, so a
+     short surface list cannot hide a sub-3:1 pair again. */
+  --role-border-strong: oklch(0.55 0.015 250);
+
+  /* Dark half of --role-border-interactive (see the light block for the full
+     rationale). oklch(0.66 0.018 250), source-of-truth palette, measured
+     against every dark surface role:
+
+       vs --role-bg-sunken  6.38:1     vs --role-bg-body   6.20:1
+       vs --role-bg-panel   5.95:1     vs --role-bg-surface 5.69:1
+       vs --role-bg-input   5.30:1  <- worst case
+
+     Deliberately a wider margin than the light half's 3.88:1: a hairline on
+     navy is the case this estate has already got wrong twice (the near-white
+     `border-strong` above, and the 0.09-alpha `--border-shell`), and the cost
+     of a boundary that is slightly too visible is nothing next to one that
+     disappears. */
+  --role-border-interactive: oklch(0.66 0.018 250);
 
   /* Role text variants rebind for the dark surface — all AAA on navy. */
   --role-primary-text: oklch(0.721 0.215 262.9);  /*  7.01:1 ✓ AAA */