@xenosystem/elements-react 0.0.3 → 0.0.5

package/LICENSE

@@ -1,18 +1,18 @@
-Copyright (c) 2026 XENO Corporation. All rights reserved.
-
-PROPRIETARY AND CONFIDENTIAL.
-
-This software and its source code are the confidential and proprietary property
-of XENO Corporation. No licence, express or implied, is granted to any person to
-use, copy, modify, merge, publish, distribute, sublicense, or sell copies of this
-software, in whole or in part, without the prior written permission of XENO
-Corporation.
-
-Unauthorised copying of this file, via any medium, is strictly prohibited.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
-FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
-COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
-AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
-WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+Copyright (c) 2026 XENO Corporation. All rights reserved.
+
+PROPRIETARY AND CONFIDENTIAL.
+
+This software and its source code are the confidential and proprietary property
+of XENO Corporation. No licence, express or implied, is granted to any person to
+use, copy, modify, merge, publish, distribute, sublicense, or sell copies of this
+software, in whole or in part, without the prior written permission of XENO
+Corporation.
+
+Unauthorised copying of this file, via any medium, is strictly prohibited.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
+FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
+COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
+AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

package/README.md

@@ -1,41 +1,41 @@
-# @xenosystem/elements-react
-
-**Web + Electron renderer**
-
-> Status: 🔵 **planned** — see [`../../SPEC.md`](../../SPEC.md) §13 for the build order.
-
-Interprets `@xenosystem/elements` declarations as React components and web components.
-
-**Not built yet** — Phase 2. The contract lands first, deliberately (`SPEC.md` §13).
-
-## When it is built, it must
-
-1. **Honour every declared axis.** Silently ignoring one produces an element that looks
-   interactive and isn't — the worst failure in the set.
-2. **Never invent state.** No `pressed` binding in the declaration means pressed looks like idle.
-3. **Map input modalities** per `docs/STATE-MODEL.md` §3 — including the **agent** row, or
-   agent-driven UI diverges from what a human would have seen.
-4. **Be visually indistinguishable** from every other renderer given the same declaration. Testable, and tested.
-5. **Add nothing.** No renderer-local colours, timings or easing.
-
-## Hard constraints
-
-- **CSS-first, 0 kb runtime.** Axes become `data-*` attributes; bindings become CSS custom
-  properties and transitions. This diverges from the 2026 norm (@animateicons, LivelyIcons,
-  Itshover all build on `motion/react`) because XENO elements must run inside **sandboxed
-  iframes** and survive **web export**, where a JS animation runtime is weight in every sandbox
-  and a dependency that cannot be removed later.
-- **`motion` is an opt-in entry point only** (`/motion`), for genuinely orchestrated cases —
-  multi-step morphs, physics. ~4.6 kb with `m` + `LazyMotion` vs 34 kb naive. **Never a
-  dependency of the base renderer.**
-- **No barrel.** Per-element entry points, `sideEffects: false`. A single index importing
-  everything is why `lucide-react` is 2.4 MB — and `lucide-react/dynamic` collapses to an empty
-  chunk in production builds.
-- **Base UI is an implementation detail here**, used for composite behaviour and accessibility.
-  It is never exposed as the system's foundation. (Radix stalled after the WorkOS acquisition;
-  Base UI reached v1.0 in Dec 2025 with full-time MUI engineering.)
-- **Components are generated**, never hand-written. Editing one to fix a glyph means the
-  declaration is wrong.
-
----
-Part of [`xeno-elements`](../../README.md). Visual authority: [`DESIGN_SYSTEM.md`](../../DESIGN_SYSTEM.md) — LOCKED.
+# @xenosystem/elements-react
+
+**Web + Electron renderer**
+
+> Status: 🔵 **planned** — see [`../../SPEC.md`](../../SPEC.md) §13 for the build order.
+
+Interprets `@xenosystem/elements` declarations as React components and web components.
+
+**Not built yet** — Phase 2. The contract lands first, deliberately (`SPEC.md` §13).
+
+## When it is built, it must
+
+1. **Honour every declared axis.** Silently ignoring one produces an element that looks
+   interactive and isn't — the worst failure in the set.
+2. **Never invent state.** No `pressed` binding in the declaration means pressed looks like idle.
+3. **Map input modalities** per `docs/STATE-MODEL.md` §3 — including the **agent** row, or
+   agent-driven UI diverges from what a human would have seen.
+4. **Be visually indistinguishable** from every other renderer given the same declaration. Testable, and tested.
+5. **Add nothing.** No renderer-local colours, timings or easing.
+
+## Hard constraints
+
+- **CSS-first, 0 kb runtime.** Axes become `data-*` attributes; bindings become CSS custom
+  properties and transitions. This diverges from the 2026 norm (@animateicons, LivelyIcons,
+  Itshover all build on `motion/react`) because XENO elements must run inside **sandboxed
+  iframes** and survive **web export**, where a JS animation runtime is weight in every sandbox
+  and a dependency that cannot be removed later.
+- **`motion` is an opt-in entry point only** (`/motion`), for genuinely orchestrated cases —
+  multi-step morphs, physics. ~4.6 kb with `m` + `LazyMotion` vs 34 kb naive. **Never a
+  dependency of the base renderer.**
+- **No barrel.** Per-element entry points, `sideEffects: false`. A single index importing
+  everything is why `lucide-react` is 2.4 MB — and `lucide-react/dynamic` collapses to an empty
+  chunk in production builds.
+- **Base UI is an implementation detail here**, used for composite behaviour and accessibility.
+  It is never exposed as the system's foundation. (Radix stalled after the WorkOS acquisition;
+  Base UI reached v1.0 in Dec 2025 with full-time MUI engineering.)
+- **Components are generated**, never hand-written. Editing one to fix a glyph means the
+  declaration is wrong.
+
+---
+Part of [`xeno-elements`](../../README.md). Visual authority: [`DESIGN_SYSTEM.md`](../../DESIGN_SYSTEM.md) — LOCKED.

package/dist/containers/Chip.js

@@ -7,7 +7,7 @@ export function Chip({ children, leadingIcon, selected = false, onSelectedChange
     const glyph = iconPx(size);
     const selectable = onSelectedChange !== undefined;
     const inner = (_jsxs(_Fragment, { children: [leadingIcon && _jsx(XenoElement, { decl: leadingIcon, size: glyph }), children != null && _jsx("span", { className: "xeno-chip-label", children: children })] }));
-    return (_jsxs("span", { className: cx('xeno-chip', className), "data-selection": selected ? 'on' : 'off', "data-availability": availability, "data-removable": onRemove ? 'true' : undefined, ...sizeAttr(size), ...rest, children: [selectable ? (_jsx("button", { type: "button", className: "xeno-chip-body xeno-chip-select", "aria-pressed": selected, disabled: disabled, onClick: (e) => {
+    return (_jsxs("span", { className: cx('xeno-chip', className), "data-selection": selected ? 'on' : 'off', "data-availability": availability, "data-removable": onRemove ? 'true' : undefined, "aria-disabled": disabled || undefined, ...sizeAttr(size), ...rest, children: [selectable ? (_jsx("button", { type: "button", className: "xeno-chip-body xeno-chip-select", "aria-pressed": selected, disabled: disabled, onClick: (e) => {
                     if (!e.defaultPrevented)
                         onSelectedChange?.(!selected);
                 }, children: inner })) : (_jsx("span", { className: "xeno-chip-body", children: inner })), onRemove && (_jsx("button", { type: "button", className: "xeno-chip-remove", "aria-label": removeLabel, disabled: disabled, onClick: (e) => {

package/dist/containers/Panel.js

@@ -2,5 +2,5 @@ import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
 import { cx } from '../controls/util.js';
 export function Panel({ title, actions, footer, className, children, ...rest }) {
     const hasHeader = title !== undefined || actions !== undefined;
-    return (_jsxs("div", { className: cx('xeno-panel', className), ...rest, children: [hasHeader && (_jsxs("div", { className: "xeno-panel-header", children: [title !== undefined && _jsx("div", { className: "xeno-panel-title", children: title }), actions !== undefined && _jsx("div", { className: "xeno-panel-actions", children: actions })] })), _jsx("div", { className: "xeno-panel-body", children: children }), footer !== undefined && _jsx("div", { className: "xeno-panel-footer", children: footer })] }));
+    return (_jsxs("div", { className: cx('xeno-panel', className), ...rest, children: [hasHeader && (_jsxs("div", { className: "xeno-panel-header", children: [title !== undefined && _jsx("div", { className: "xeno-panel-title", children: title }), actions !== undefined && _jsx("div", { className: "xeno-panel-actions", children: actions })] })), _jsx("div", { className: "xeno-panel-body", tabIndex: 0, role: "region", "aria-label": typeof title === 'string' ? title : 'Panel content', children: children }), footer !== undefined && _jsx("div", { className: "xeno-panel-footer", children: footer })] }));
 }

package/package.json

@@ -1,58 +1,58 @@
-{
-  "name": "@xenosystem/elements-react",
-  "version": "0.0.3",
-  "license": "UNLICENSED",
-  "description": "The XENO web renderer — 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.3",
-    "@xenosystem/generate": "0.0.3"
-  },
-  "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"
-  }
-}
+{
+  "name": "@xenosystem/elements-react",
+  "version": "0.0.5",
+  "license": "UNLICENSED",
+  "description": "The XENO web renderer — 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.5",
+    "@xenosystem/generate": "0.0.5"
+  },
+  "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

@@ -1,132 +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);
-}
+/*
+ * ══════════════════════════════════════════════════════════════════════════════════════════════
+ *  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-text);
+  --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);
+}