trykeyline 0.1.1 → 0.1.2

package/plugins/keyline/skills/keyline/glass/depth/assets/GlassPanel.tsx

@@ -1,85 +1,20 @@
 /**
- * The glass surface, as a component — every depth cue in one place.
- *
- * The point of this file is the wrapper/surface split and the depth cues in
- * one place. (The elevation stack itself is better as the `.dock-shadow`
- * class in glass/depth/assets/glass.css — see the note on the SHADOW constant below.)
- * Glass is four properties plus three depth cues, and the cues are the part
- * people skip: a blurred tinted rectangle with no hairline and no shadow is a
- * patch, not a floating panel.
- *
- * Pairs with glass/depth/assets/glass.css (the materials) and
+ * The glass surface, as a component: the wrapper/surface split and the three
+ * depth cues — material, hairline, shadow — in one place. Pairs with
+ * glass/depth/assets/glass.css (the materials) and
  * glass/color/assets/color-tokens.css (the tints and the ramps).
  */
 
 import type { ReactNode } from "react";
 
-/* ── Elevation ────────────────────────────────────────────────────────────
-   Four layers modelling one light source above the element:
-
-     inset 1px white   the specular catch where a raised surface faces the
-                       light. Contributes more to the floating impression
-                       than any of the shadows, and is the one most often
-                       omitted — remove it and the surface looks printed on.
-     1px/1px @ 2%      contact shadow: resting on something, not pasted over.
-     8/16 @ 4%         near ambient.
-     24/32 @ 6%        far ambient. Two layers rather than one because a
-                       single large shadow reads as fog; two fall off like
-                       real penumbra.
-
-   Negative spread (-4px, -8px) contracts the shadow before blurring, keeping
-   it tucked under the element instead of haloing past its edges. This is the
-   detail most hand-written shadows miss, and why stock box-shadow presets
-   often look like a glow.
-
-   Opacities are 2-6%. Elevation should be felt, not seen.
-
-   Dark mode is a DIFFERENT shadow, not the same one re-tinted:
-     · shadows go up ~10x   — 4% black on #0b0b0b is mathematically
-                              invisible; dark needs 30-60% to register at all
-     · highlight drops ~6x  — 0.6 white on a dark surface reads as a glowing
-                              edge rather than a catch light
-
-   Because the STRUCTURE changes and not just the values, elevation cannot be
-   a single token — it needs a per-theme pair, and this is the one place raw
-   rgba() outside the token file is acceptable.
-
-   PREFER THE CLASS. `.dock-shadow` in glass/depth/assets/glass.css is the same four
-   layers in a form you can actually read and diff against its dark twin.
-   The reference implementation started with the constant below and moved
-   to the class, for three reasons:
-
-     · it's ~400 characters either way, and four CSS lines beat one string
-     · a constant still gets imported and interpolated at every call site,
-       so a grep for the shadow finds five hits rather than one definition
-     · the arbitrary-value escaping is a live hazard — underscores for
-       spaces, no spaces inside the parens, and a typo produces a class the
-       build silently drops: no shadow, no error
-
-   The constant is kept here for codebases that can't add a stylesheet. */
+/* The elevation stack as a utility string, for codebases that can't add a
+   stylesheet. Prefer the `.dock-shadow` class in glass.css; the layers and
+   why the class won are in glass/depth/depth-cues.md §2. */
 export const SHADOW =
   "shadow-[inset_0_1px_0_rgba(255,255,255,0.6),0_1px_1px_rgba(0,0,0,0.02),0_8px_16px_-4px_rgba(0,0,0,0.04),0_24px_32px_-8px_rgba(0,0,0,0.06)] " +
   "dark:shadow-[inset_0_1px_0_rgba(255,255,255,0.10),0_1px_1px_rgba(0,0,0,0.3),0_8px_16px_-4px_rgba(0,0,0,0.5),0_24px_32px_-8px_rgba(0,0,0,0.6)]";
 
-/** Hover cards and other briefly-floating panels. One ambient layer, no
-    contact shadow — it's hovering, not resting. */
-export const SHADOW_PANEL =
-  "shadow-[0_8px_24px_-8px_rgba(0,0,0,0.12)] dark:shadow-[0_8px_24px_-8px_rgba(0,0,0,0.6)]";
-
-/** Tooltips. 30% black in BOTH themes — it sits on bg-gray-1000, which is
-    near-black in light and near-white in dark, so the SURFACE sets the
-    requirement rather than the page. Elevation is relative to what's
-    immediately behind, not to the theme. */
-export const SHADOW_TIP = "shadow-[0_4px_10px_-4px_rgba(0,0,0,0.3)]";
-
-/* ── The hairline ─────────────────────────────────────────────────────────
-   From the TRANSLUCENT ramp, not a solid grey. A solid border doesn't
-   participate in what's behind it, so over a photograph it reads as a
-   pasted-on frame. And because the alpha ramp inverts to white-based in dark
-   mode, this is automatically lighter than its surface there and darker here.
-
-   0.5px renders as a true sub-pixel hairline on retina and rounds UP to 1px
-   elsewhere — it degrades to the next weight rather than disappearing. */
+/* The translucent-ramp hairline (glass/depth/depth-cues.md §1). */
 const HAIRLINE = "border-[0.5px] border-gray-alpha-400";
 
 export type GlassTier = "nav" | "panel";
@@ -87,18 +22,9 @@ export type GlassTier = "nav" | "panel";
 /**
  * A glass surface with all three depth cues attached.
  *
- * `tier` picks the material — and the choice is about how little you know
- * about the backdrop, not about size or importance:
- *
- *   nav    20px blur, 72% tint. Fixed chrome that arbitrary content scrolls
- *          under.
- *   panel  24px blur, 97% tint. A floating menu that must stay legible over
- *          anything — including over other glass.
- *
- * `isolate` is on by default because these surfaces usually contain a sliding
- * highlight at -z-10 (`glass/motion/guide.md`). Without it, -z-10
- * would drop the highlight behind the container's own tint instead of just
- * behind the icons.
+ * `tier` picks the material (nav 20px / 72%, panel 24px / 97%:
+ * glass/depth/guide.md §1). `isolate` is on by default so a sliding highlight
+ * at -z-10 stays in front of the tint (glass/depth/depth-cues.md §4).
  */
 export function GlassSurface({
   tier = "panel",
@@ -126,46 +52,13 @@ export function GlassSurface({
   );
 }
 
-/* ─────────────────────────────────────────────────────────────────────────
-   THE WRAPPER / SURFACE SPLIT — the one structural rule to internalise.
-
-   A transform on an ancestor weakens or breaks backdrop-filter in its
-   subtree: the blur samples the wrong region, or nothing. So an animating
-   menu must be TWO elements — the wrapper animates, the surface blurs, and
-   they are never the same node:
+/* The wrapper / surface split: the wrapper animates, the surface blurs, and
+   they are never the same node (glass/depth/guide.md §3); closed menus
+   unmount (glass/depth/performance-and-fallbacks.md).
 
      <DropMenu open={open}>              // animates scale + y. No filter.
        <GlassSurface tier="panel">       // filters. Never transformed.
          …
        </GlassSurface>
      </DropMenu>
-
-   Where you can't split them (a surface that must animate itself), fall back
-   to glass-panel's 97% tint and treat the blur as decoration.
-
-   This is also a performance win, not just a correctness one: the wrapper
-   animates on the compositor (transform and opacity only), and the glass
-   child's filter isn't being recomputed against a moving containing block
-   every frame.
-
-   Same root cause, second symptom: a transform also makes an element the
-   containing block for position: fixed descendants. In the reference
-   implementation the fixed nav strip deliberately carries NO transform, so
-   the mobile sheet's w-screen full-bleed overlay can span the viewport
-   instead of being trapped inside the strip's bounds.
-
-   When something filtered or positioned behaves inexplicably, check every
-   ancestor for: transform, filter, perspective, contain, will-change.
-
-   ── And close menus by UNMOUNTING them ─────────────────────────────────
-   A backdrop-filter element still pays its full filter pass when it's
-   transparent — visibility is decided at composite time, after the filter has
-   already run. opacity: 0 and visibility: hidden do NOT save you; unmounting
-   (or display: none) is the only thing that does.
-
-     <AnimatePresence>
-       {open && <m.div …>{children}</m.div>}
-     </AnimatePresence>
-
-   Which also keeps a closed menu out of the tab order.
-   ───────────────────────────────────────────────────────────────────────── */
+*/

package/plugins/keyline/skills/keyline/glass/depth/assets/glass.css

@@ -1,31 +1,14 @@
 /* ─────────────────────────────────────────────────────────────────────────
-   Glass materials — three tiers, with every fallback.
+   Glass materials — three tiers, with every fallback (glass/depth/guide.md).
 
-   PAIRS WITH glass/color/assets/color-tokens.css, which declares the
-   --glass-*-bg tints and their dark-theme values. This file holds the
-   material classes; that file holds the tints. Both are needed.
-
-   Why the tints live there and not here: they change per theme AND get
-   replaced wholesale by the reduced-transparency fallback, so they have to be
-   runtime :root custom properties rather than build-time tokens. (One of them
-   is also a gradient, which no colour-token system accepts.)
-
-   Three tiers, not four. The reference implementation also defines a
-   `glass-menu` (16px / 1.8 / 72%) for "a menu over a known surface" — and
-   nothing uses it. Every menu turned out to need glass-panel's defensive
-   tint, either because its wrapper animates or because it opens over other
-   glass. Dead CSS in a design system is worse than absent CSS: the next
-   person assumes it's load-bearing.
+   Pairs with glass/color/assets/color-tokens.css, which declares the
+   --glass-*-bg tints, their dark values and the reduced-transparency tint
+   swap. Both files are needed.
    ───────────────────────────────────────────────────────────────────────── */
 
 @layer components {
-  /* ── Opaque baselines ──────────────────────────────────────────────────
-     What a browser without backdrop-filter gets. Progressive enhancement in
-     the correct direction: the opaque version is the DEFAULT and the glass is
-     layered on top. Invert it and the non-supporting path never gets tested.
-
-     Support is good (Firefox unflagged since 103), so this is insurance
-     rather than a live concern — but it's cheap insurance. */
+  /* ── Opaque baselines: what a browser without backdrop-filter gets. The
+     glass is layered on top (depth law 15). */
   .glass-nav {
     background: var(--color-gray-100);
   }
@@ -36,85 +19,33 @@
     background: var(--color-background-100);
   }
 
-  /* ── The materials ─────────────────────────────────────────────────────
-     Test BOTH conditions — Safari shipped only the prefixed version for
-     years, and Safari is where glass matters most.
-
-     Only the standard `backdrop-filter` is written below, on purpose. Let the
-     build add `-webkit-backdrop-filter` (Lightning CSS in Tailwind v4, or
-     Autoprefixer). Lightning CSS keeps only the LAST of a hand-written pair,
-     so writing both, standard first, ships the prefixed one alone — and
-     Firefox, which only reads the standard property, loses every blur. With
-     no build step, write the prefixed line first and the standard one last. */
+  /* ── The materials. Only the standard `backdrop-filter` is written: let the
+     build add the -webkit- line (glass/depth/performance-and-fallbacks.md). */
   @supports (backdrop-filter: blur(1px)) or (-webkit-backdrop-filter: blur(1px)) {
-    /* Fixed chrome that arbitrary page content scrolls under — a paragraph, a
-       photograph, a full-bleed image wall. 20px because the less you know
-       about the backdrop, the more of it has to be suppressed so the
-       surface's own icons can be read.
-
-       saturate() is NOT decoration. Blur is a convolution, averaging colours
-       moves them toward grey, so a blurred backdrop is ALWAYS desaturated —
-       more so at larger radii. Without the boost you get the cloudy
-       "glassmorphism" wash. This one line is the difference between
-       translucent and dirty, and it costs nothing: same filter pass. */
+    /* Fixed chrome over arbitrary content; saturate() restores what the blur
+       greys out (depth law 8). */
     .glass-nav {
       background: var(--glass-nav-bg);
       backdrop-filter: blur(20px) saturate(1.8);
     }
 
-    /* Near-opaque (97%) on purpose, and for three reasons at once:
-
-       1. Its wrapper ANIMATES. A transform on an ancestor weakens
-          backdrop-filter in its subtree — the blur samples the wrong region,
-          or nothing, for the duration. So the TINT carries the legibility and
-          the blur is a bonus once it settles. General rule: when you can't
-          rely on the blur, thicken the tint.
-
-       2. It opens over OTHER GLASS (the nav dock). Two surfaces at the same
-          tint read as one object — the panel would look like the dock had
-          grown taller. The heavy tint buys tier separation.
-
-       3. At 97% you can actually COMPUTE text contrast against the tint. At
-          72% the effective background is whatever happens to be behind it,
-          and the ratio is not computable.
-
-       Where you have the choice, fix it structurally instead: animate the
-       wrapper, put the glass on a static child. */
+    /* 97%: its wrapper animates and it opens over other glass (§3–4 of the
+       guide). Animate the wrapper, put the glass on a static child. */
     .glass-panel {
       background: var(--glass-panel-bg);
       backdrop-filter: blur(24px) saturate(1.8);
     }
 
-    /* A frosted pocket with cards peeking out behind it. 8px because here you
-       WANT the backdrop recognised — blur is softening, not obscuring. And
-       1.4 rather than 1.8 because those cards are the subject; pushing their
-       saturation would make the pocket louder than its own contents.
-
-       Its tint is a gradient (brighter at the top, where the light hits)
-       rather than a flat fill — the same idea as a 1px inset catch light, at
-       a scale where a 1px line would be lost. */
+    /* A frosted pocket: 8px softens rather than obscures, 1.4 keeps it
+       quieter than the cards behind it. The tint is a gradient. */
     .folder-glass {
       background: var(--folder-glass-bg);
       backdrop-filter: blur(8px) saturate(1.4);
     }
   }
 
-  /* ── prefers-reduced-transparency ──────────────────────────────────────
-     Two reasons users set this: blur is expensive on low-powered devices,
-     and translucent surfaces are harder to read. One response serves both —
-     replace the material with an opaque one.
-
-     BOTH halves are mandatory and each is useless alone:
-       · filter only → a 72% tint over live content with no blur to suppress
-                       it. WORSE than the glass was; text overlaps text.
-       · tint only   → you still pay the whole cost of the blur, which was
-                       half the reason for the preference.
-
-     The tint half lives in color-tokens.css (it re-declares the :root
-     variables and must come after both theme blocks). This is the other half.
-
-     Useful side effect: with a solid tint, text contrast becomes real and
-     computable — for exactly the users most likely to need it. */
+  /* ── prefers-reduced-transparency: the filter half. The tint half is in
+     color-tokens.css; each is useless alone (depth law 15). */
   @media (prefers-reduced-transparency: reduce) {
     .glass-nav,
     .glass-panel,
@@ -123,15 +54,7 @@
     }
   }
 
-  /* ── prefers-contrast: more ────────────────────────────────────────────
-     A translucent surface leans on its hairline to define its edge, and an
-     8%-alpha hairline is the first thing to disappear under a contrast
-     preference. Promote it to primary text colour.
-
-     Note what is NOT changed: the surface itself. High contrast is about
-     edges and text, not about removing the material. Composes correctly with
-     reduced-transparency if the user has both — solid surface, strong
-     border. */
+  /* ── prefers-contrast: more — the edge goes to primary; the surface stays. */
   @media (prefers-contrast: more) {
     .glass-nav,
     .glass-panel,
@@ -142,70 +65,13 @@
 }
 
 /* ─────────────────────────────────────────────────────────────────────────
-   REFERENCE — glass is only half of it. A blurred, tinted rectangle is a
-   PATCH. Three non-transparency cues turn it into an object, and every glass
-   surface needs all three. See glass/depth/depth-cues.md.
-
-   1 · A HAIRLINE, from the TRANSLUCENT ramp:
-
-         border-[0.5px] border-gray-alpha-400
-
-       Not solid grey — a solid border doesn't participate in what's behind
-       it, so over a photograph it reads as a pasted-on frame. And because
-       the alpha ramp inverts to white-based in dark mode, the border is
-       automatically lighter than its surface there and darker here.
-
-       0.5px renders as a true sub-pixel hairline on retina and rounds UP to
-       1px elsewhere — it degrades rather than disappears.
-
-   2 · A LAYERED SHADOW. Four layers, one light source above:
-
-         inset 0 1px 0 rgba(255,255,255,0.6)   top-edge catch light
-         0 1px 1px rgba(0,0,0,0.02)            contact
-         0 8px 16px -4px rgba(0,0,0,0.04)      near ambient
-         0 24px 32px -8px rgba(0,0,0,0.06)     far ambient
-
-       The inset highlight contributes more than any of the shadows and is
-       the one most often omitted — remove it and the surface looks printed
-       on rather than raised. Negative spread contracts before blurring, so
-       the shadow stays tucked under instead of haloing out. Opacities are
-       2–6%: if you can identify the shadow as a shadow, it's too strong.
-
-       Dark mode is a DIFFERENT shadow, not a re-tint — shadows ~10x stronger
-       (4% black on #0b0b0b is mathematically invisible), inset highlight ~6x
-       weaker (0.6 white on dark reads as a glowing edge). Because the
-       structure changes, this can't be one token — it's a per-theme pair,
-       and it belongs in the .dock-shadow class at the foot of this file
-       rather than repeated inline at every use.
-
-   3 · CONTINUOUS CORNERS:
-
-         *, *::before, *::after { corner-shape: superellipse(1.5); }
-
-       And nest radii by: INNER = OUTER − the padding between them.
-         Dock rounded-2xl (16) p-1 (4) → button rounded-[12px] → avatar 10px
-
-   ── Performance, briefly ──────────────────────────────────────────────
-   Cost scales with AREA and re-runs whenever anything behind it changes —
-   including every frame of every scroll. Keep surfaces small, keep them few,
-   UNMOUNT closed menus (a hidden backdrop-filter element still pays its
-   filter pass; opacity: 0 does not save you), never animate blur(), and
-   never put glass over video or a flat background.
-   ───────────────────────────────────────────────────────────────────────── */
-
-/* ─────────────────────────────────────────────────────────────────────────
-   The elevation stack, as a class.
-
-   Every floating surface takes this alongside its material class:
+   The elevation stack, as a class, beside each material class:
 
-     <div class="glass-nav dock-shadow rounded-2xl border-[0.5px] …">
+     <div class="glass-nav dock-shadow rounded-2xl border-[0.5px] border-gray-alpha-400 …">
 
-   It is NOT a design token, because it isn't a colour — no token system
-   takes a four-layer box-shadow (see §6 of the Glass colour guide (`glass/color/guide.md`)).
-   And it can't be one value, because dark mode changes the structure and
-   not just the numbers. A class is the only place it can live, and putting
-   it in one is what stops a ~400-character string being copied into five
-   components with a dark twin each.
+   A class, not a token: dark mode changes its structure, not just its
+   numbers. The hairline, corners, tiers and why each layer is there:
+   glass/depth/depth-cues.md.
    ───────────────────────────────────────────────────────────────────────── */
 
 @layer components {
@@ -228,27 +94,10 @@
 }
 
 /* ─────────────────────────────────────────────────────────────────────────
-   A gradient 1px stroke — no wrapper element, no mask.
-
-   Two background layers on one box: the fill clipped to the padding edge,
-   the gradient clipped to the border edge, with a transparent border to
-   show it through.
-
-   background-origin: border-box IS THE LOAD-BEARING LINE. Without it the
-   gradient is SIZED to the padding box while being clipped to the border
-   box, so the stroke gets the wrong end of the ramp on all four sides — a
-   one-word omission that produces a result which looks almost right.
-
-   AND THE STOPS ARE IN PIXELS, NOT PERCENTAGES. Percentages are relative to
-   the box, so the ramp rescales whenever the box resizes: a 46px closed bar
-   ran the entire sweep inside its own height, came out louder than the
-   250px panel it opened into, and shimmered through the open animation as
-   the ramp re-fitted frame by frame. Anchored in pixels the top of the
-   stroke holds still and the colour simply grows downward.
-
-   Colours come from the Glass colour guide's --sv-* family, which is
-   that system's one chromatic exception. Delete this block if you don't
-   have such an element.
+   A gradient 1px stroke — no wrapper element, no mask (§6 of the guide).
+   background-origin: border-box is load-bearing, and the stops are in
+   pixels so the ramp holds still as the panel grows. Colours are the --sv-*
+   family in color-tokens.css. Delete this block if you have no such element.
    ───────────────────────────────────────────────────────────────────────── */
 
 @layer components {
@@ -265,16 +114,12 @@
     background-origin: border-box;
     background-clip: padding-box, border-box;
 
-    /* Four shadows, not one. A single centred blur reads as a drop shadow
-       that happens to be blue; the two HORIZONTAL casts are what make it
-       read as light coming off the panel. Same negative spread as the
-       elevation stack, so the glow stays tucked rather than haloing. */
+    /* Two horizontal casts make it read as light, not a blue drop shadow. */
     box-shadow: var(--sv-glow);
     transition: box-shadow 220ms var(--ease-geist);
   }
 
-  /* Lifts on hover and STAYS lifted while open, so the colour reports the
-     same state the chevron does. */
+  /* Lifts on hover and stays lifted while open. */
   .sv-panel:hover,
   .sv-panel[data-open="true"] {
     box-shadow: var(--sv-glow-lift);
@@ -286,11 +131,7 @@
     }
   }
 
-  /* One pass of light across the label as it opens — never a loop. A
-     repeating shimmer claims the thing is still working, which it isn't.
-     Drop the class on animationend so the label goes back to painted text:
-     background-clip: text with color: transparent is a text-selection and
-     forced-colours hazard to leave in place. */
+  /* One pass of light, never a loop; drop the class on animationend. */
   .sv-sheen {
     background-image: linear-gradient(
       100deg,

package/plugins/keyline/skills/keyline/glass/depth/depth-cues.md

@@ -20,22 +20,7 @@ Vertical dividers inside the dock are layout's (`glass/layout/radius-and-elevati
 
 ## 2. The shadow stack
 
-`.dock-shadow` lives in `glass/depth/assets/glass.css`, both themes side by side; depth law 4 gives each layer's job. Light to dark:
-
-```
-inset 0 1px 0 rgba(255,255,255,0.10),     /* highlight:  0.6  → 0.10 */
-0 1px 1px rgba(0,0,0,0.3),                /* shadows:    0.02 → 0.3  */
-0 8px 16px -4px rgba(0,0,0,0.5),          /*             0.04 → 0.5  */
-0 24px 32px -8px rgba(0,0,0,0.6)          /*             0.06 → 0.6  */
-```
-
-A 4%-black shadow on a `#0b0b0b` surface is invisible; dark mode needs 30–60% black before a shadow registers. It's also why the dark page is `#0b0b0b`, not `#000000` (depth law 5).
-
-Because the structure changes and not just the values, elevation **cannot be a single token**. It needs a per-theme pair — the one place raw `rgba()` outside the token file is acceptable — and it belongs in a **CSS class**, not a JS constant:
-
-```tsx
-<div className="glass-nav dock-shadow rounded-2xl border-[0.5px] border-gray-alpha-400 p-1">
-```
+`.dock-shadow` lives in `glass/depth/assets/glass.css`, both themes side by side; depth law 4 gives each layer's job. Light is 2–6% black with a 0.6 catch light; dark is 30–60% black with the catch light at 0.10, because a 4%-black shadow on `#0b0b0b` is invisible. It's also why the dark page is `#0b0b0b`, not `#000000` (depth law 5). Because the structure changes and not just the values, elevation **cannot be a single token**: it's a per-theme pair — the one place raw `rgba()` outside the token file is acceptable — in a **CSS class**, not a JS constant.
 
 The reference implementation started with an exported constant and moved to the class:
 

package/plugins/keyline/skills/keyline/glass/depth/performance-and-fallbacks.md

@@ -1,6 +1,6 @@
 # Performance and fallbacks
 
-Glass's budget and fallbacks, for depth laws 15 and 16. The cost model, what to avoid, how to measure, containment and the fallback order in general are in `domains/depth/fallbacks-and-performance.md`; glass's fallback code is in §8 of the guide.
+Glass's budget and fallbacks, for depth laws 15 and 16. The cost model, what to avoid, how to measure, containment and the fallback order in general are in `domains/depth/fallbacks-and-performance.md`.
 
 ## What makes it affordable here
 
@@ -20,17 +20,9 @@ The reference implementation runs three or four glass surfaces and stays smooth
 
 **The wrapper animates, the surface filters.** The `DropMenu` split in §3 of the guide is a double win: the wrapper animates on the compositor, and the child's filter isn't recomputed against a moving containing block every frame.
 
-## Reduced transparency, per material
+## The fallbacks
 
-The substitutions are per material, not blanket-white: chrome goes to `gray-100`, the raised-surface token, so the dock still reads as raised; the decorative pocket goes to `background-100`, fully opaque, since its whole purpose was translucency. The block names both `:root` and `:root[data-theme="dark"]`, or it wins in one theme only.
-
-## `prefers-contrast: more`
-
-An 8%-alpha hairline is the first thing to disappear under a contrast preference, so the edge goes to `gray-1000`, primary text colour, and the surface stays.
-
-## `@supports`
-
-Without the guard, the reference implementation's surfaces get a bare tint where `backdrop-filter` is missing: legible but weak, marginal at 72% over a photograph. Support is very good (Firefox shipped it unflagged in 103, mid-2022), so it's a small risk, not a live bug. `glass/depth/assets/glass.css` in this guide ships with the guard in place.
+The code is in `glass/depth/assets/glass.css` (baselines, `@supports`, the filter half of reduced transparency, `prefers-contrast`) and `glass/color/assets/color-tokens.css` (the tint half). Two decisions it encodes: the substitutions are per material, not blanket-white — chrome goes to `gray-100` so the dock still reads as raised, the decorative pocket to opaque `background-100` — and the `@supports` guard is one the live site lacks, a small risk given support (Firefox unflagged since 103) but cheap to close.
 
 ## The `-webkit-` prefix on the site
 

package/plugins/keyline/skills/keyline/glass/layout/adaptive-presentations.md

@@ -59,65 +59,13 @@ The desktop panel needs no equivalent: it *mounts fresh* on open and reads the v
 
 ## Case 2: the table of contents
 
-Same tree, two containers, shared row rendering.
-
-```tsx
-/** Shared — used by both presentations. */
-function Rows({ nodes, active, parents, onJump }) { … }
-
-/** The sticky rail, in the left margin on wide screens. */
-export function SectionNav({ nodes, active, onJump }) {
-  return (
-    <nav aria-label="On this page">
-      <ul className="flex flex-col">
-        <Rows … />
-      </ul>
-    </nav>
-  );
-}
-
-/** The narrow-screen disclosure — one line above the article. */
-export function SectionNavCompact({ nodes, active, onJump }) {
-  const [open, setOpen] = useState(false);
-  const jump = (id: string) => { setOpen(false); onJump(id); };
-  return (
-    <details open={open} onToggle={(e) => setOpen(e.currentTarget.open)}
-             className="group rounded-xl border border-gray-alpha-300">
-      <summary className="… [&::-webkit-details-marker]:hidden">
-        On this page
-        <span className="… group-open:rotate-180 motion-reduce:transition-none">
-          <ChevronDownIcon />
-        </span>
-      </summary>
-      <ul className="… border-t border-gray-alpha-300">
-        <Rows … onJump={jump} />
-      </ul>
-    </details>
-  );
-}
-```
-
-Both are rendered; CSS picks one:
-
-```tsx
-<div className="absolute inset-y-0 left-8 hidden w-[196px] xl:block">
-  <div className="sticky top-28 max-h-[calc(100dvh-11rem)] overflow-y-auto">
-    <SectionNav {...nav} />
-  </div>
-</div>
-
-<div className="reveal mt-8 xl:hidden">
-  <SectionNavCompact {...nav} />
-</div>
-```
-
-The props are memoised so both get a stable object:
+Same tree, two containers, shared row rendering: `glass/layout/assets/SectionNav.tsx`. Both are rendered and CSS picks one — the rail in the 1280px frame from `xl` (§2 of the guide), the compact `<details>` above the article below that (`reveal mt-8 xl:hidden`). The props are memoised so both get one stable object:
 
 ```tsx
 const nav = useMemo(() => ({ nodes: toc, active, onJump: jump }), [active, jump]);
 ```
 
-The compact version is a `<details>` (layout law 11); `open` is mirrored into React state only so it can close itself after a jump. `[&::-webkit-details-marker]:hidden` plus `list-none` removes the default triangle so the chevron can be styled, and `group-open:rotate-180` reads the parent's `open` attribute, so the rotation needs no state. It costs **one line** above the article, which is what makes a nav in the reading flow acceptable.
+The compact version is a `<details>` (layout law 11), and costs **one line** above the article, which is what makes a nav in the reading flow acceptable.
 
 ## Case 3: two views of one collection, chosen by the reader
 
@@ -125,24 +73,7 @@ The first two cases fork on a *device* capability; the gallery's **wall** and **
 
 ### The state can't live in either component
 
-The control and what it controls are siblings, so a third party owns the value:
-
-```ts
-export type GalleryLayout = "grid" | "roll";
-let current: GalleryLayout = "grid";
-
-const listeners = new Set<(layout: GalleryLayout) => void>();
-export function onGalleryLayoutChange(fn: (l: GalleryLayout) => void) {
-  listeners.add(fn);
-  return () => { listeners.delete(fn); };
-}
-export function setGalleryLayout(layout: GalleryLayout) {
-  current = layout;
-  for (const fn of listeners) fn(layout);
-}
-```
-
-The shape of a theme or sound store, for the same reason: neither consumer can be the other's parent without distorting the layout.
+The control and what it controls are siblings, so a module store owns the value (its code is §6 of the guide), mirrored in a hook:
 
 ```ts
 // Mirror it in a hook. Read in an EFFECT, not during render: on a
@@ -175,10 +106,6 @@ Find the item nearest the viewport's centre before the outgoing layout unmounts
 
 Nothing is cropped, so `object-cover` has nothing to do; nothing shifts on load; and one image travels between layouts undistorted, because both ends compute to the same shape.
 
-## Hover in Tailwind
-
-Tailwind v4's `hover:` variant already compiles to a `(hover: hover)` guard, so utility hover states are safe by default. Imperative JavaScript needs the explicit check.
-
 ## The touch-versus-hover audit
 
 Glass's answers to the audit in `domains/layout/forks-gating-and-disclosures.md`:
@@ -213,19 +140,6 @@ The last is a hover card *below* its row on narrow screens and *beside* it at `x
 | `sm` | 640px | Mobile dock ↔ desktop dock. Page padding. Masonry columns. Stack columns. |
 | `xl` | 1280px | The TOC rail appears. The hover card moves beside its row. |
 
-Two for the whole site, both derived from content. Both are viewport breakpoints only because here the column *is* the page. `sm` coincides with the reading measure: below it the column is padding-limited, the natural place for the layout to change character. `xl` is where a 640px column finally leaves margin for a 196px rail. Type size is *not* on the list: a 30px article title once stepped to 26px below `sm`, until an 18px type ceiling removed the need (`glass/layout/measure-and-rhythm.md`; the Glass type guide, `glass/type/guide.md`).
-
-## Breakpoints on the container
-
-Where a pane shares the screen with something that opens and closes, it breaks on its own width (layout law 8). In Tailwind:
-
-```tsx
-<section className="@container">                  {/* the pane, not the page */}
-  <div className="grid @2xl:grid-cols-[minmax(240px,1fr)_2fr]">
-    <List />
-    <Detail className="@container" />            {/* sizes its own insides */}
-  </div>
-</section>
-```
+Two for the whole site, both derived from content. Both are viewport breakpoints only because here the column *is* the page. `sm` coincides with the reading measure: below it the column is padding-limited, the natural place for the layout to change character. `xl` is where a 640px column finally leaves margin for a 196px rail. Type size is *not* on the list (`glass/type/scale.md`).
 
-Tailwind v4 ships `@container` and the `@sm:`…`@7xl:` variants; plain CSS is `container-type: inline-size` and `@container (min-width: …)`. The list is clamped with `minmax` so it narrows before the detail does, and the nested `@container` lets the detail size its own gutters, rail and labels.
+Glass uses no container breakpoints; where a pane shares the screen with something that opens and closes, see `domains/layout/forks-gating-and-disclosures.md`.