@xenosystem/elements-react 0.0.1

package/dist/useGooPill.js

@@ -0,0 +1,76 @@
+import { jsx as _jsx } from "react/jsx-runtime";
+import { useCallback, useRef } from 'react';
+const DEFAULT_ROW_SELECTOR = 'button[role^="menuitem"]:not(:disabled)';
+/**
+ * Where a row starts inside the host, in LAYOUT pixels.
+ *
+ * Offsets rather than `getBoundingClientRect()` because hosts animate in: a panel that scales or
+ * translates on entrance reports transformed rects, and a pill positioned from those would be off by
+ * whatever the entrance was doing on that frame. Offsets are untransformed.
+ *
+ * Walking the offset chain (rather than reading `row.offsetTop` once) does two jobs at once: it survives
+ * a row wrapped in a positioned div, and it returns `null` for a row that lives in a nested list —
+ * exactly the row this pill should refuse.
+ */
+function offsetWithin(row, host) {
+    let top = 0;
+    let node = row;
+    while (node && node !== host) {
+        top += node.offsetTop;
+        node = node.offsetParent;
+    }
+    return node === host ? top : null;
+}
+export function useGooPill(options = {}) {
+    const { rowSelector = DEFAULT_ROW_SELECTOR } = options;
+    const ownRef = useRef(null);
+    const hostRef = options.hostRef ?? ownRef;
+    const rows = useCallback(() => {
+        const host = hostRef.current;
+        if (!host)
+            return [];
+        return Array.from(host.querySelectorAll(rowSelector));
+    }, [hostRef, rowSelector]);
+    /**
+     * Written straight to the DOM rather than through state: this fires on every row the pointer crosses,
+     * and re-rendering a list to move a highlight is work for nothing.
+     */
+    const moveGoo = useCallback((row) => {
+        const host = hostRef.current;
+        if (!host)
+            return;
+        if (!row) {
+            host.removeAttribute('data-goo');
+            return;
+        }
+        const top = offsetWithin(row, host);
+        if (top === null)
+            return;
+        host.style.setProperty('--xeno-goo-y', `${top}px`);
+        host.style.setProperty('--xeno-goo-h', `${row.offsetHeight}px`);
+        // The index only exists to give the stretch a distinct animation name per row; a browser will not
+        // replay an animation whose name did not change, so without it the pill would deform once and then
+        // glide silently for the rest of the list.
+        const index = rows().indexOf(row);
+        host.setAttribute('data-goo-index', String(Math.max(0, Math.min(9, index))));
+        host.setAttribute('data-goo', 'on');
+    }, [hostRef, rows]);
+    const rowFrom = useCallback((target) => target?.closest(rowSelector) ?? null, [rowSelector]);
+    const onMouseOver = useCallback((e) => moveGoo(rowFrom(e.target)), [moveGoo, rowFrom]);
+    const onMouseLeave = useCallback(() => moveGoo(null), [moveGoo]);
+    // Keyboard too: a list like this is a keyboard surface first, and a highlight that only answers a
+    // mouse is half a highlight.
+    const onFocus = useCallback((e) => moveGoo(rowFrom(e.target)), [moveGoo, rowFrom]);
+    return {
+        hostRef,
+        hostProps: {
+            ref: hostRef,
+            className: 'xeno-goo-host',
+            onMouseOver,
+            onMouseLeave,
+            onFocus,
+        },
+        pill: _jsx("span", { className: "xeno-goo-pill", "aria-hidden": "true" }),
+        moveGoo,
+    };
+}

package/dist/useMenu.d.ts

@@ -0,0 +1,50 @@
+import type { KeyboardEvent as ReactKeyboardEvent, MouseEvent as ReactMouseEvent, MutableRefObject } from 'react';
+/**
+ * `useMenu()` — everything a menu has to DO, for a menu this library did not build.
+ *
+ * Focus lands on the first item when it opens, Arrow Up/Down walk the list and wrap, Home and End jump
+ * to the ends, Tab leaves and closes, and choosing an item closes it. None of that is visual, and all
+ * of it is what separates a menu from a floating list of buttons.
+ *
+ * It is the third hook of its kind and it exists for the third time for the same reason. {@link Menu}
+ * has all of this and a product cannot reach it: adopting the component means adopting its `Popover`
+ * placement and its looks in the same breath, so a product with its own dropdown design writes the
+ * behaviour again — or, as measured on one, does not write it at all. Twelve menus in that chat, and
+ * every row was its own Tab stop with the arrow keys doing nothing.
+ *
+ * ```tsx
+ * const { menuProps } = useMenu({ open, onClose: () => setOpen(false) })
+ * return open ? <div {...menuProps} className="my-dropdown">{rows}</div> : null
+ * ```
+ *
+ * Composes with {@link useGooPill}: hand it the same ref and one element carries the highlight and the
+ * keyboard.
+ */
+export interface UseMenuOptions<T extends HTMLElement> {
+    /** Whether the menu is open. Everything here is inert while false. */
+    readonly open: boolean;
+    /** Called when the menu should close — an item was chosen, or Tab left it. */
+    readonly onClose?: () => void;
+    /** An existing ref for the panel, if the caller already has one (e.g. from `useGooPill`). */
+    readonly menuRef?: MutableRefObject<T | null>;
+    /**
+     * Which rows the keyboard walks. Default is the ARIA menu family — `menuitem`, `menuitemcheckbox`,
+     * `menuitemradio` — and never a disabled one: a row you cannot choose is a row the arrows must skip
+     * rather than land on and strand you.
+     */
+    readonly itemSelector?: string;
+}
+export interface UseMenuResult<T extends HTMLElement> {
+    readonly menuRef: MutableRefObject<T | null>;
+    /** Spread on the element that carries `role="menu"`. */
+    readonly menuProps: {
+        readonly role: 'menu';
+        readonly 'aria-orientation': 'vertical';
+        /** So the panel itself can hold focus for the instant before the first item takes it. */
+        readonly tabIndex: -1;
+        readonly ref: (node: T | null) => void;
+        readonly onKeyDown: (e: ReactKeyboardEvent<T>) => void;
+        readonly onClick: (e: ReactMouseEvent<T>) => void;
+    };
+}
+export declare function useMenu<T extends HTMLElement = HTMLDivElement>({ open, onClose, menuRef: providedRef, itemSelector, }: UseMenuOptions<T>): UseMenuResult<T>;

package/dist/useMenu.js

@@ -0,0 +1,119 @@
+import { useCallback, useEffect, useRef } from 'react';
+const DEFAULT_ITEMS = 'button[role^="menuitem"]:not(:disabled), [role^="menuitem"]:not([aria-disabled="true"])';
+export function useMenu({ open, onClose, menuRef: providedRef, itemSelector = DEFAULT_ITEMS, }) {
+    const ownRef = useRef(null);
+    const menuRef = providedRef ?? ownRef;
+    const openRef = useRef(open);
+    openRef.current = open;
+    const items = useCallback(() => {
+        const root = menuRef.current;
+        if (!root)
+            return [];
+        return Array.from(root.querySelectorAll(itemSelector));
+    }, [menuRef, itemSelector]);
+    /**
+     * Put focus on the first row, and the guard is what took three tries to get right.
+     *
+     * The obvious latch — focus once per opening — is wrong, and wrong in a way that only shows on a real
+     * menu. Panels that animate their exit stay mounted and toggle `aria-hidden`, and several key their
+     * root on the animation state, so React REMOUNTS them as they open. The sequence measured on one: the
+     * effect focuses the first row, the key flips, React replaces the element the focus was on, and focus
+     * falls back to the document. A latch that has already fired cannot recover from that.
+     *
+     * The honest condition is not "have I done this yet" but "is focus where it belongs": while the menu
+     * is open, if nothing inside it has focus, put focus on the first row. That survives a remount, and it
+     * also refuses to steal focus from a row the user has arrowed to, which a re-fire otherwise would.
+     */
+    const focusFirst = useCallback((node) => {
+        if (!node || !openRef.current)
+            return;
+        if (node.contains(document.activeElement))
+            return;
+        Array.from(node.querySelectorAll(itemSelector))[0]?.focus();
+    }, [itemSelector]);
+    const setMenu = useCallback((node) => {
+        menuRef.current = node;
+        focusFirst(node);
+    }, [menuRef, focusFirst]);
+    /**
+     * The other way a menu opens: ALREADY MOUNTED.
+     *
+     * The callback ref above covers the panel that is rendered only while open. Plenty are not — a menu
+     * that animates its exit has to stay in the tree and toggle `aria-hidden`, and for those the ref
+     * fires once, on first mount, while the menu is still shut. Measured on a real one: the arrow keys
+     * worked and focus never entered.
+     *
+     * So both, guarded by the same latch. Whichever happens first wins and the other does nothing.
+     */
+    useEffect(() => {
+        if (!open)
+            return;
+        focusFirst(menuRef.current);
+    }, [open, menuRef, focusFirst]);
+    const focusAt = useCallback((index) => {
+        const list = items();
+        if (list.length === 0)
+            return;
+        // Wrap in both directions. A menu is a ring; stopping dead at the last row is a behaviour people
+        // only notice as the control feeling stuck.
+        list[((index % list.length) + list.length) % list.length]?.focus();
+    }, [items]);
+    const onKeyDown = useCallback((e) => {
+        const list = items();
+        if (list.length === 0)
+            return;
+        const current = list.findIndex((el) => el === document.activeElement);
+        switch (e.key) {
+            case 'ArrowDown':
+                e.preventDefault();
+                focusAt(current < 0 ? 0 : current + 1);
+                break;
+            case 'ArrowUp':
+                e.preventDefault();
+                focusAt(current < 0 ? list.length - 1 : current - 1);
+                break;
+            case 'Home':
+                e.preventDefault();
+                focusAt(0);
+                break;
+            case 'End':
+                e.preventDefault();
+                focusAt(list.length - 1);
+                break;
+            case 'Tab':
+                /* Tab CLOSES rather than moving on. A menu is a modal little world: leaving it by tabbing into
+                   the page behind, with the panel still open over that page, is the state nobody wants. */
+                e.preventDefault();
+                onClose?.();
+                break;
+            default:
+                break;
+        }
+    }, [items, focusAt, onClose]);
+    const onClick = useCallback((e) => {
+        const item = e.target.closest('[role^="menuitem"]');
+        if (!item)
+            return;
+        if (item.hasAttribute('disabled') || item.getAttribute('aria-disabled') === 'true')
+            return;
+        // A DISCLOSURE row keeps the menu. Activating an item normally dismisses the menu, because the
+        // item's job is elsewhere — but a row reporting `aria-expanded` opens a region INSIDE this
+        // menu, and closing on it destroys the panel in the same tick it was asked for. The symptom is
+        // a row that looks dead: click "Theme", the whole menu vanishes, and the accordion under it is
+        // never seen.
+        if (item.hasAttribute('aria-expanded'))
+            return;
+        onClose?.();
+    }, [onClose]);
+    return {
+        menuRef,
+        menuProps: {
+            role: 'menu',
+            'aria-orientation': 'vertical',
+            tabIndex: -1,
+            ref: setMenu,
+            onKeyDown,
+            onClick,
+        },
+    };
+}

package/dist/useTabs.d.ts

@@ -0,0 +1,88 @@
+import type { KeyboardEvent as ReactKeyboardEvent } from 'react';
+/**
+ * `useTabs()` — everything a tablist has to DO, for a tablist this library did not build.
+ *
+ * Arrow keys move between tabs, one Tab key press leaves the whole set, each tab names the panel it
+ * controls and the panel names the tab that labels it. None of that is visual, and all of it is what
+ * separates a row of tabs from a row of buttons that happen to sit next to each other.
+ *
+ * It exists for the same reason {@link useDialog} does, and the evidence is the same shape. Measured on
+ * one product's chat: FIVE tablists, and they disagreed with each other.
+ *
+ * - one had roving `tabIndex` and arrow keys, and pointed at no panel
+ * - three had neither — every tab was a Tab stop, so getting past a seven-section settings header meant
+ *   seven presses, and the arrow keys did nothing at all
+ * - one had a `role="tabpanel"` and nothing tying it to the tab that opened it
+ *
+ * None of them was wrong on purpose. The behaviour is just long enough that it gets written once,
+ * properly, and then the next tablist is copied from the markup rather than from the working one.
+ *
+ * ```tsx
+ * const tabs = useTabs({ ids: SECTIONS.map((s) => s.id), activeId: section, onChange: setSection })
+ * return (
+ *   <>
+ *     <div {...tabs.tablistProps} aria-label="Settings sections">
+ *       {SECTIONS.map((s) => <button key={s.id} {...tabs.tabProps(s.id)}>{s.label}</button>)}
+ *     </div>
+ *     <div {...tabs.panelProps}>…</div>
+ *   </>
+ * )
+ * ```
+ */
+export interface UseTabsOptions<Id extends string> {
+    /** Every tab, in the order they are rendered. Arrow keys walk this array. */
+    readonly ids: readonly Id[];
+    /** The selected tab. */
+    readonly activeId: Id;
+    /** Called with the tab the user moved to. */
+    readonly onChange: (id: Id) => void;
+    /**
+     * Which arrow keys walk the list. `horizontal` (default) is Left/Right; `vertical` is Up/Down.
+     * A vertical tablist must also say so to assistive technology, and `tablistProps` sets
+     * `aria-orientation` to match.
+     */
+    readonly orientation?: 'horizontal' | 'vertical';
+    /**
+     * Wrap from the last tab to the first. Default `true` — a tab strip is a ring, and stopping dead at
+     * the end is a behaviour people notice only as the control feeling stuck.
+     */
+    readonly wrap?: boolean;
+    /**
+     * Share one panel between two tablists.
+     *
+     * Normally the hook mints the panel's id and nobody has to know it. The case that needs this is a
+     * RESPONSIVE duplicate: the same sections rendered twice, once for wide screens and once for narrow,
+     * with CSS hiding one — both are in the document, and both must point at the single panel below them.
+     * Two hook instances would otherwise each invent an id and each claim to own the panel.
+     *
+     * Pass the same string to both; give the panel to whichever instance you like. The tab ids stay
+     * distinct either way, because those still come from `useId`.
+     */
+    readonly panelId?: string;
+}
+export interface UseTabsResult<Id extends string> {
+    /** Spread on the element that holds the tabs. */
+    readonly tablistProps: {
+        readonly role: 'tablist';
+        readonly 'aria-orientation': 'horizontal' | 'vertical';
+        readonly onKeyDown: (e: ReactKeyboardEvent<HTMLElement>) => void;
+    };
+    /** Spread on each tab. Pass the same id you passed in `ids`. */
+    readonly tabProps: (id: Id) => {
+        readonly role: 'tab';
+        readonly id: string;
+        readonly 'aria-selected': boolean;
+        readonly 'aria-controls': string;
+        readonly tabIndex: 0 | -1;
+        readonly ref: (node: HTMLElement | null) => void;
+    };
+    /** Spread on the panel the active tab controls. */
+    readonly panelProps: {
+        readonly role: 'tabpanel';
+        readonly id: string;
+        readonly 'aria-labelledby': string;
+        /** So a panel that scrolls can be reached and scrolled from the keyboard. */
+        readonly tabIndex: 0;
+    };
+}
+export declare function useTabs<Id extends string>({ ids, activeId, onChange, orientation, wrap, panelId: givenPanelId, }: UseTabsOptions<Id>): UseTabsResult<Id>;

package/dist/useTabs.js

@@ -0,0 +1,93 @@
+import { useCallback, useId, useRef } from 'react';
+export function useTabs({ ids, activeId, onChange, orientation = 'horizontal', wrap = true, panelId: givenPanelId, }) {
+    /* One id per hook instance, so two tablists on the same screen — a settings modal over a settings
+       page is the ordinary case — cannot both claim `#tab-general`. Duplicate ids do not throw; they
+       make `aria-controls` resolve to whichever came first, which is a bug with no symptom until
+       someone is using a screen reader. */
+    const uid = useId();
+    const tabId = useCallback((id) => `${uid}tab-${id}`, [uid]);
+    /* ONE panel id, not one per tab. Every tablist this was written for has a single panel element whose
+       CONTENTS swap — a settings page with one scroll container, a modal with one body — rather than N
+       panels of which N-1 are hidden. So every tab controls that one element, and the panel names the tab
+       currently labelling it. Minting an id per tab would describe a structure that is not there. */
+    const panelId = givenPanelId ?? `${uid}panel`;
+    /* The tabs, by id, so the hook can move focus without going through the document. `querySelector`
+       works and is what hand-rolled versions reach for; it also finds a tab from a DIFFERENT tablist
+       when both are open, because the selector it can write has nothing to scope by. */
+    const nodes = useRef(new Map());
+    /* Ref callbacks memoised PER ID. Returning a fresh closure from `tabProps` would give React a new ref
+       identity on every render, which it answers by calling the old one with null and the new one with
+       the node — every render, for every tab. Harmless and pointless; the map costs one lookup. */
+    const refs = useRef(new Map());
+    const setNode = useCallback((id) => {
+        let fn = refs.current.get(id);
+        if (!fn) {
+            fn = (node) => {
+                if (node)
+                    nodes.current.set(id, node);
+                else
+                    nodes.current.delete(id);
+            };
+            refs.current.set(id, fn);
+        }
+        return fn;
+    }, []);
+    const onKeyDown = useCallback((e) => {
+        const [prev, next] = orientation === 'vertical' ? ['ArrowUp', 'ArrowDown'] : ['ArrowLeft', 'ArrowRight'];
+        const at = ids.indexOf(activeId);
+        if (at < 0)
+            return;
+        let to = null;
+        if (e.key === next)
+            to = at + 1;
+        else if (e.key === prev)
+            to = at - 1;
+        else if (e.key === 'Home')
+            to = 0;
+        else if (e.key === 'End')
+            to = ids.length - 1;
+        if (to === null)
+            return;
+        if (to < 0 || to >= ids.length) {
+            if (!wrap)
+                return;
+            to = (to + ids.length) % ids.length;
+        }
+        const target = ids[to];
+        if (target === undefined || target === activeId)
+            return;
+        e.preventDefault();
+        onChange(target);
+        /* Focus AFTER the change has painted. Selection follows focus here — the ARIA pattern calls it
+           automatic activation, and it is right for tabs whose panels are already rendered — which means
+           the tab we want to focus is about to become the only one with `tabIndex: 0`. Focusing it in
+           this handler focuses the node as it is now, and React then re-renders and can replace it.
+  
+           Two frames, not one. A single `requestAnimationFrame` fires BEFORE the commit that React
+           schedules in response to `onChange`, so on a slow section it lands on the old node. */
+        requestAnimationFrame(() => {
+            requestAnimationFrame(() => nodes.current.get(target)?.focus());
+        });
+    }, [ids, activeId, onChange, orientation, wrap]);
+    const tabProps = useCallback((id) => ({
+        role: 'tab',
+        id: tabId(id),
+        'aria-selected': id === activeId,
+        'aria-controls': panelId,
+        /* Roving: exactly one tab is a Tab stop, and it is the selected one. Without this every tab is
+           a stop, and a seven-section header costs seven presses to walk past — which is the difference
+           between a control and an obstacle. */
+        tabIndex: (id === activeId ? 0 : -1),
+        ref: setNode(id),
+    }), [activeId, tabId, panelId, setNode]);
+    return {
+        tablistProps: { role: 'tablist', 'aria-orientation': orientation, onKeyDown },
+        tabProps,
+        panelProps: {
+            role: 'tabpanel',
+            id: panelId,
+            'aria-labelledby': tabId(activeId),
+            tabIndex: 0,
+        },
+    };
+}

package/package.json

@@ -0,0 +1,58 @@
+{
+  "name": "@xenosystem/elements-react",
+  "version": "0.0.1",
+  "license": "UNLICENSED",
+  "description": "The XENO web renderer \u2014 interprets element declarations as React/SVG. CSS-first, 0 kb runtime.",
+  "author": "XENO Corporation <emilian@bnkrsys.com>",
+  "type": "module",
+  "main": "./dist/index.js",
+  "types": "./dist/index.d.ts",
+  "sideEffects": [
+    "*.css"
+  ],
+  "exports": {
+    ".": {
+      "types": "./dist/index.d.ts",
+      "default": "./dist/index.js"
+    },
+    "./xeno-element.css": "./src/xeno-element.css",
+    "./xeno-theme.css": "./src/xeno-theme.css",
+    "./controls.css": "./src/controls.css",
+    "./xeno-elements.css": "./src/xeno-elements.css",
+    "./fonts.css": "./src/fonts.css"
+  },
+  "files": [
+    "dist",
+    "src/xeno-element.css",
+    "src/xeno-theme.css",
+    "src/controls.css",
+    "src/xeno-elements.css",
+    "src/**/*.css",
+    "LICENSE"
+  ],
+  "scripts": {
+    "prebuild": "npm run build -w @xenosystem/elements && npm run build -w @xenosystem/generate",
+    "build": "tsc -p tsconfig.json",
+    "pretypecheck": "npm run build -w @xenosystem/elements && npm run build -w @xenosystem/generate",
+    "typecheck": "tsc -p tsconfig.json --noEmit && tsc -p tsconfig.test.json --noEmit",
+    "test": "vitest run"
+  },
+  "peerDependencies": {
+    "react": ">=18"
+  },
+  "dependencies": {
+    "@fontsource-variable/inter": "^5.3.0",
+    "@xenosystem/elements": "0.0.1",
+    "@xenosystem/generate": "0.0.1"
+  },
+  "devDependencies": {
+    "@types/react": "^19.0.0",
+    "@types/react-dom": "^19.0.0",
+    "react": "^19.0.0",
+    "react-dom": "^19.0.0",
+    "typescript": "^5.4.0"
+  },
+  "publishConfig": {
+    "access": "public"
+  }
+}

package/src/chrome-separated.css

@@ -0,0 +1,132 @@
+/*
+ * ══════════════════════════════════════════════════════════════════════════════════════════════
+ *  OWNED FILE — INDUSTRIAL (`separated`)
+ * ══════════════════════════════════════════════════════════════════════════════════════════════
+ *
+ * One construction, one file, one owner, so the two can be worked on in parallel without either
+ * side touching the other's values. Everything a construction decides lives HERE — colours, box
+ * metrics, typography, radii. Nothing construction-specific belongs in a component stylesheet or
+ * in `xeno-theme.css`, because those are shared and a change there hits BOTH looks.
+ *
+ * THE CONTRACT BETWEEN THE TWO FILES, enforced by `theme.test.ts`:
+ *   1. Every token declared in `chrome-separated.css` must also be declared here, and vice versa.
+ *      Adding one on your side and not telling the other side is the failure mode — the missing
+ *      one silently inherits the other construction's value and half-renders.
+ *   2. Every token must actually DIFFER between the two files. If a value is the same in both, it
+ *      is not a construction decision: move it to the shared base.
+ *
+ * So adding a token is a two-file change and the suite will say so. That is deliberate: it is the
+ * cheapest possible coordination between two people editing in parallel.
+ */
+
+/* ── CHROME: construction, not colour ──────────────────────────────────────────────────────────
+ * A THIRD axis, orthogonal to `data-theme` (colour ramp) and `data-surface` (density). It needs its
+ * own attribute: `data-theme` already carries `light`, and one attribute cannot hold two orthogonal
+ * values — you would lose "industrial + light".
+ *
+ * 🔴 DECLARED ON `:root`, NOT ON `.xeno`, and that is load-bearing rather than tidy.
+ *
+ * `.xeno` is a SCOPE MARKER — an app nests it (a section that wants the light ramp is a `.xeno` with
+ * `data-theme`), and the playground nests seven. A custom property resolves from the NEAREST
+ * declaring ancestor, so while these lived on `.xeno` every nested scope silently re-declared them at
+ * the default and the root's `data-chrome` never reached a single component. The axis appeared to do
+ * nothing, which is exactly what it did.
+ *
+ * On `:root` the defaults are declared once. `[data-chrome=…]` is attribute-only so it applies to
+ * whatever element carries it — html, an app wrapper, or one subtree — and wins for its descendants
+ * by proximity without needing to out-specify anything.
+ *
+ * DEFAULT = separated, because `DESIGN_SYSTEM.md` §"Panel Structure" requires it.
+ */
+:root {
+  /* ── CHROME: construction, not colour ──────────────────────────────────────────────────────
+   * A THIRD axis, orthogonal to `data-theme` (colour ramp) and `data-surface` (density). It has to
+   * be its own attribute: `data-theme` already carries `light`, and one attribute cannot hold two
+   * orthogonal values — you would lose "industrial + light". Same lesson as RFC 0003.
+   *
+   * Every chrome-bearing element reads these instead of hardcoding. That is what lets ONE DOM render
+   * as either construction: no component knows a theme exists, and nothing is built twice.
+   *
+   * DEFAULT = separated, because `DESIGN_SYSTEM.md` §"Panel Structure" requires it ("They are NOT
+   * merged into a single container"). `unified` is the opt-in.
+   */
+  /*
+   * 6 / 2 / 6 / 4, from `xeno-tools/packages/tool-kit/src/ui/Plate.tsx` — "the canonical panel chrome,
+   * ported from xeno-motion's dialogs, the pattern the design language actually resolves to across 10
+   * of Motion's 12 dialogs."
+   *
+   * ⚠️ FIXED, not responsive. Motion and Pixel DO use `clamp()` — but only in `index.css`, for the
+   * DOCKVIEW panel chrome, where a docked panel scales with the viewport. A floating dialog or a tool
+   * panel does not, and `Plate` pins 6/4/2. An earlier version of this file generalised the wrong one.
+   */
+  --xeno-chrome-gap: 2px;
+  --xeno-chrome-inset: 6px;
+  /* What the SHELL paints. Separated: the page shows between plates. */
+  --xeno-chrome-shell: var(--xeno-canvas);
+  /* What a header/footer PLATE paints. */
+  --xeno-chrome-plate: var(--xeno-panel-header);
+  /* What the BODY plate paints. */
+  --xeno-chrome-body: var(--xeno-viewport);
+  /* Separation is the gap, so no divider line is drawn. */
+  --xeno-chrome-divider: none;
+  /* §"Modals / Overlays": "the backdrop provides the separation." */
+  --xeno-chrome-shadow: none;
+  --xeno-chrome-radius: 6px;
+  /*
+   * DERIVED, not picked from the scale — `Plate` rounds its shell 6px and its children 4px. Two
+   * rounded rects offset by a constant stay parallel only if the inner radius drops by that offset,
+   * so this is geometry rather than taste. An earlier version chose `sm` off the radius scale because
+   * "4 is not in the scale"; the scale was never the right source for this number.
+   */
+  --xeno-chrome-radius-plate: calc(var(--xeno-chrome-radius) - 2px);
+  /* The glass on the header plate. Both reference apps, identical values. */
+  --xeno-chrome-plate-filter: blur(14px) saturate(120%);
+  /*
+   * Button emphasis. The playbook: "Emphasis comes from surface lightness and text brightness. Never
+   * from hue." Separated follows the reference — primary is the lightest SURFACE with bright text,
+   * not an inverted fill. On the chrome axis rather than the base so `unified` keeps the inverted
+   * treatment this set already shipped; a button is a button, but which reading of "emphasis" applies
+   * is part of the construction.
+   */
+  /*
+   * The readout / detail block — `PlateDetail` in the reference: "raised back to plate colour against
+   * the recessed body. This is Motion's readout group and is where label-value pairs belong."
+   *
+   * So in `separated` a card is NOT a soft surface with a big radius and a shadow. It is a plate-
+   * coloured block, 4px, borderless, flat. `xeno-tools/DESIGN_SYSTEM.md` bans the alternative
+   * outright: "❌ Gradients in chrome, drop shadows for depth".
+   */
+  --xeno-chrome-card-bg: var(--xeno-panel-header);
+  --xeno-chrome-card-border: none;
+  --xeno-chrome-card-radius: var(--xeno-chrome-radius-plate);
+  --xeno-chrome-card-pad: 12px;
+  --xeno-chrome-card-shadow: none;
+  /* Hover "lifts alpha, never bounces or scales dramatically" — tools DESIGN_SYSTEM, Motion. */
+  --xeno-chrome-card-lift: none;
+
+  /*
+   * Typography and box metrics DIFFER between the constructions, so they belong on the axis too. An
+   * earlier version of this pass changed them in the BASE, which silently altered `unified` — the one
+   * thing this axis exists to prevent. Everything a construction decides lives here or it leaks.
+   */
+  --xeno-chrome-border: var(--xeno-border-subtle);
+  --xeno-chrome-panel-header-pad: 7px 12px;
+  --xeno-chrome-panel-header-min-h: 34px;
+  --xeno-chrome-panel-body-pad: 12px;
+  --xeno-chrome-title-size: 11px;
+  --xeno-chrome-title-color: var(--xeno-muted);
+  --xeno-chrome-title-transform: uppercase;
+  --xeno-chrome-title-spacing: 0.08em;
+  --xeno-chrome-dialog-header-pad: 6px 12px;
+  --xeno-chrome-dialog-title-size: 11px;
+  --xeno-chrome-dialog-title-weight: 500;
+  --xeno-chrome-dialog-body-pad: 12px;
+  --xeno-chrome-dialog-body-size: 12px;
+  --xeno-chrome-dialog-footer-pad: 6px;
+  --xeno-chrome-dialog-footer-gap: 6px;
+  --xeno-chrome-card-elevated-bg: var(--xeno-chrome-card-bg);
+
+  --xeno-chrome-btn-primary-bg: var(--xeno-control);
+  --xeno-chrome-btn-primary-fg: var(--xeno-text);
+  --xeno-chrome-btn-radius: var(--xeno-radius-xs);
+}