@flyos/design-system 2.2.0 → 2.3.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@flyos/design-system",
-  "version": "2.2.0",
+  "version": "2.3.0",
   "description": "FlyOS design system — shared components, directives, pipes, services, and models for Business App developers.",
   "keywords": [
     "flyos",

package/scss/_nova-glass.scss

@@ -299,6 +299,31 @@
   @include _degrade;
 }
 
+// ── Content blur ─────────────────────────────────────────────────────────────
+// The one sanctioned way for a surface INSIDE a window to blur the app's OWN
+// content: scroll-edge toolbars, side panes, drawers over the app's canvas, and
+// floating tool plates that keep the app's documented fill (chats'
+// `--glass-bg-elevated` floaters are the reference consumers). It emits ONLY the
+// thin blur tier plus the degradation ladder — no fill, border or shadow — so an
+// app's measured, RULE-A-tracked plate/ink pairing survives the migration off
+// raw `backdrop-filter` untouched.
+
+// What this is NOT:
+//   · not a menu/listbox recipe — a true menu takes `popover($surface: menu)`,
+//     the material `fly-context-menu`/`fly-select` already ship;
+//   · not a way to reach the wallpaper. A window is a backdrop root (hazard 3 in
+//     the header), so inside one this blur samples the window's interior paint —
+//     the app content behind the surface. That IS the contract here, which is
+//     why this recipe is safe where a translucent quartet fill would read muddy.
+
+// Include it AFTER the caller's own paint declarations: the ladder's
+// reduced-transparency flat must be able to override the caller's translucent
+// fill, and within one specificity tier that is decided by source order.
+@mixin content-blur {
+  @include _backdrop(thin);
+  @include _degrade;
+}
+
 // ── Light "vibrancy" material — RETIRED IN PLACE, no production callers ──────
 // DO NOT ADOPT THIS. S6.-1 reversed the ruling that motivated it: the light
 // theme is conventional dark-ink-on-pale-plate, and the white-ink-on-smoke

package/scss/_nova-tokens.scss

@@ -95,6 +95,41 @@ html.light-theme {
   --sys-green: #1B7355;
   --sys-purple: #6A3FC0;
 
+  // ── System TINTS ───────────────────────────────────────────────────────────
+  // The status-wash step the hue family was missing. Before these existed, 75
+  // feature-app call sites minted their own Tailwind-palette literal at a fixed
+  // alpha (`rgb(16 185 129 / 8%)` …) — one value for both themes, tuned against
+  // whichever plate the author happened to be looking at. A missing step makes
+  // every consumer mint their own (the `--font-family` trap), so the step is a
+  // NAMED TOKEN, not a documented idiom: two strengths, no percentage drift.
+  // ---
+  // · Derived via `color-mix` off the hue token so a tint always tracks its
+  //   `--sys-*` parent — the same derivation the D7 danger ruling already
+  //   spells for action-menu hovers (`color-mix(in oklab, var(--sys-red) 18%,
+  //   transparent)`). Mixing toward `transparent` is colour-space-neutral: the
+  //   result is the hue at that alpha.
+  // · Strengths are PER THEME (like `--tint-hover`/`--tint-sel` above): the
+  //   light hues are deep, so 8% over the pale plate reads like the old
+  //   Tailwind-500 at 10%; the dark hues are bright pastels over a near-black
+  //   plate and need more ink to read as the same wash.
+  // · Pick by ROLE: `-tint` = resting wash (status rows, soft chips, added
+  //   states); `-tint-strong` = emphasis (selected/hover status, danger
+  //   surfaces, filled badges). Never mint a bespoke percentage for a
+  //   BACKGROUND. Border rings and glows are not this step — spell those
+  //   `color-mix(in srgb, var(--sys-*) N%, transparent)` at the use site.
+  --sys-red-tint: color-mix(in srgb, var(--sys-red) 8%, transparent);
+  --sys-red-tint-strong: color-mix(in srgb, var(--sys-red) 14%, transparent);
+  --sys-orange-tint: color-mix(in srgb, var(--sys-orange) 8%, transparent);
+  --sys-orange-tint-strong: color-mix(in srgb, var(--sys-orange) 14%, transparent);
+  --sys-blue-tint: color-mix(in srgb, var(--sys-blue) 8%, transparent);
+  --sys-blue-tint-strong: color-mix(in srgb, var(--sys-blue) 14%, transparent);
+  --sys-teal-tint: color-mix(in srgb, var(--sys-teal) 8%, transparent);
+  --sys-teal-tint-strong: color-mix(in srgb, var(--sys-teal) 14%, transparent);
+  --sys-green-tint: color-mix(in srgb, var(--sys-green) 8%, transparent);
+  --sys-green-tint-strong: color-mix(in srgb, var(--sys-green) 14%, transparent);
+  --sys-purple-tint: color-mix(in srgb, var(--sys-purple) 8%, transparent);
+  --sys-purple-tint-strong: color-mix(in srgb, var(--sys-purple) 14%, transparent);
+
   // Brushed-steel wash. Light-only in the design; the dark block declares it
   // `none` so a consumer never needs `var(--steel-sheen, …)` — a hex fallback
   // is banned outright (skill §9 rule 3).
@@ -255,6 +290,25 @@ html.dark-theme {
   --sys-green: #4dd6a8;
   --sys-purple: #a48ce0;
 
+  // ── System TINTS ───────────────────────────────────────────────────────────
+  // Same two-step law as the light block (see its comment for the full
+  // rationale). Dark strengths are HIGHER on purpose: these hues are bright
+  // pastels and the plate is near-black, so parity with the light wash needs
+  // more ink — the same asymmetry `--tint-hover` carries (10% light / 26%
+  // dark). Tune strength HERE, never at a call site.
+  --sys-red-tint: color-mix(in srgb, var(--sys-red) 12%, transparent);
+  --sys-red-tint-strong: color-mix(in srgb, var(--sys-red) 18%, transparent);
+  --sys-orange-tint: color-mix(in srgb, var(--sys-orange) 12%, transparent);
+  --sys-orange-tint-strong: color-mix(in srgb, var(--sys-orange) 18%, transparent);
+  --sys-blue-tint: color-mix(in srgb, var(--sys-blue) 12%, transparent);
+  --sys-blue-tint-strong: color-mix(in srgb, var(--sys-blue) 18%, transparent);
+  --sys-teal-tint: color-mix(in srgb, var(--sys-teal) 12%, transparent);
+  --sys-teal-tint-strong: color-mix(in srgb, var(--sys-teal) 18%, transparent);
+  --sys-green-tint: color-mix(in srgb, var(--sys-green) 12%, transparent);
+  --sys-green-tint-strong: color-mix(in srgb, var(--sys-green) 18%, transparent);
+  --sys-purple-tint: color-mix(in srgb, var(--sys-purple) 12%, transparent);
+  --sys-purple-tint-strong: color-mix(in srgb, var(--sys-purple) 18%, transparent);
+
   // Light-only in the design — declared as a no-op here so consumers can read
   // it unconditionally in either theme.
   --steel-sheen: none;
@@ -320,20 +374,21 @@ html.dark-theme {
   --mat-menu-b-alpha: 1;
   --mat-menu-b: rgb(26 25 30 / calc(var(--mat-menu-b-alpha) * 100%));
 
-  // Re-valued by S6W (agent-panel sweep). The carried-over literal was
-  // rgb(56 54 60) at 0.52→0.65 — warm-hued AND translucent, so over a warm
-  // wallpaper the aside composited into muddy brown while the account-menu
-  // popover beside it stayed crisp on the alpha-1 `--mat-menu-*` pair. These
-  // are now that same menu pair's stops at alpha 1: crisp, wallpaper-immune,
-  // and cool-neutral like every other dark floating surface.
-  // Alternatives weighed (final call is perceptual, at fan-in):
-  //   · alpha→1 on the old hue rgb(56 54 60) — crisp but noticeably lighter
-  //     and warmer than the menu material next to it;
-  //   · ~0.85 alpha on either hue — still lets a warm wallpaper tint the
-  //     plate, i.e. a smaller dose of the same defect.
-  --mat-agent-a-alpha: 1;
+  // Translucent again (2026-08-16), on S6W's COOL hues — half of that ruling reversed, half
+  // kept, and the split is deliberate. S6W found the aside compositing muddy brown over warm
+  // wallpapers and went alpha-1 on the menu pair's stops. Two facts have changed since:
+  //   · the warm rgb(56 54 60) hue was half the mud, and it stays gone — these stops remain
+  //     the cool menu-pair hues, which tint cool-neutral rather than brown;
+  //   · the model now knows about the shell's 35% black wallpaper scrim (`shellBackdrop`),
+  //     which darkens and mutes whatever shows through — the "wallpaper tints the plate"
+  //     dose S6W measured was computed against a backdrop the browser does not paint.
+  // At 0.6/0.68 every aside row clears AA through the scrim over the WORST shipped backdrop
+  // (primary 7.36/9.15, secondary 4.99/5.99 — theme-contrast gate), and the aside once again
+  // matches the design's translucent panel (the mock's aside was 0.52→0.65) and its light-theme
+  // sibling right above (0.6/0.65) instead of being the one opaque slab in the shell.
+  --mat-agent-a-alpha: 0.6;
   --mat-agent-a: rgb(32 31 37 / calc(var(--mat-agent-a-alpha) * 100%));
-  --mat-agent-b-alpha: 1;
+  --mat-agent-b-alpha: 0.68;
   --mat-agent-b: rgb(26 25 30 / calc(var(--mat-agent-b-alpha) * 100%));
   --mat-tip-a-alpha: 0.82;
   --mat-tip-a: rgb(46 44 52 / calc(var(--mat-tip-a-alpha) * 100%));

package/scss/_theme-dark.scss

@@ -108,7 +108,13 @@ html.dark-theme {
   --fly-shadow-md: 0 4px 16px rgb(0 0 0 / 42%);
 
   // ── Glass system ────────────────────────────────────────────────────────────
-  --glass-bg: rgb(22 22 26 / 72%);
+  // 0.55, down from 0.72 (2026-08-16). The 72% was solved against the raw wallpaper, but no
+  // dark surface ever neighbours the wallpaper — the shell paints a 35% black scrim first
+  // (`shellBackdrop` in theme-contrast.ts), and through it the whole ink ladder clears its
+  // floors at 0.55: secondary 4.99:1 over the brightest shipped backdrop, tertiary 3.30 ≥ 3.
+  // Alpha parity with `--mat-panel` (Home) so windows, inner glass panels, and the content
+  // panel read as ONE material. The theme-contrast gate measures every row through the scrim.
+  --glass-bg: rgb(22 22 26 / 55%);
   --glass-bg-elevated: rgb(30 30 36 / 82%);
 
   // Tooltip surface — OPAQUE, and not a glass token. See the light theme for the full reasoning
@@ -144,10 +150,15 @@ html.dark-theme {
   --launcher-card-desc: rgb(255 255 255 / 58%);
 
   // ── Window chrome ───────────────────────────────────────────────────────────
-  // 42% was too thin to be a dependable substrate: over the brightest shipped wallpapers
-  // (`alpine-lake`, `cherry-blossom`) the plate stayed light enough that white body text fell
-  // to ~2.9:1. Raised to match `--glass-bg`, which is the same surface one layer out.
-  --window-bg: rgb(20 20 24 / 70%);
+  // 0.55, down from 0.70 (2026-08-16), and the history matters: 42% was genuinely too thin
+  // (white body text ~2.9:1 over `alpine-lake`), but the 70% that fixed it was solved against
+  // the RAW wallpaper — a backdrop the browser never paints. Every dark surface sits on the
+  // shell's 35% black scrim (`.desktop-wallpaper.dark-theme::after`), and through it the full
+  // window ink ladder passes at 0.55: primary 7.35:1, secondary 4.99:1, tertiary 3.30:1 over
+  // the brightest shipped backdrop (theme-contrast gate, measured per row). 0.55 is alpha
+  // parity with `--mat-panel`, so a window and Home read as the same glass — the fork where a
+  // maximized window sat visibly thicker than the launcher beside it is what this closes.
+  --window-bg: rgb(20 20 24 / 55%);
   --window-radius: 24px;
   --window-blur: 30px;
   --window-backdrop-saturate: 160%;

package/scss/_theme-light.scss

@@ -118,12 +118,13 @@ html.light-theme {
   // Tooltip surface. OPAQUE and deliberately NOT a glass token.
 
   // A tooltip is body-parented and floats over whatever happens to be underneath — a light app
-  // surface, a dark board canvas, the wallpaper. The glass family is TRANSLUCENT and, at runtime,
-  // wallpaper-adaptive: the shell recomputes `--glass-bg-elevated` from the wallpaper and writes it
-  // at `:root`, so under a dark wallpaper it becomes a 54 %-alpha DARK plate even while the shell
-  // is in `light-theme`. Composited over a light page that resolves to roughly rgb(143,141,140),
-  // and the matching white ink lands at about 2.8:1 — the "tooltips are white on white" report.
-  // An overlay that can appear anywhere cannot inherit a surface tuned for one backdrop.
+  // surface, a dark board canvas, the wallpaper. The glass family is TRANSLUCENT, and at the time
+  // of the "tooltips are white on white" report it was also runtime-adaptive: the shell then
+  // recomputed `--glass-bg-elevated` from the wallpaper and wrote it at `:root`, so under a dark
+  // wallpaper it became a 54%-alpha DARK plate even in `light-theme`, compositing white ink to
+  // ~2.8:1 over a light page. That recompute NO LONGER EXISTS (`--glass-bg-elevated` is static
+  // now — verify with a grep before citing it), but the argument survives its mechanism: an
+  // overlay that can appear over ANY backdrop cannot inherit a surface tuned for one.
 
   // Dark plate + white ink in BOTH themes is the classic tooltip treatment (macOS, Material,
   // Bootstrap) and is exactly what this directive's own comment always claimed it fell back to —