@volter/editor-blender 0.1.0

package/contributions/blender.palette.json

@@ -0,0 +1,93 @@
+{
+  "schemaVersion": 3,
+  "name": "Blender",
+  "theme": {
+    "id": "blender",
+    "color": {
+      "surface": {
+        "shell": "#161616",
+        "panel": "#303030",
+        "chrome": "#1c1c1c",
+        "raised": "#545454",
+        "inset": "#1d1d1d",
+        "overlay": "rgba(48,48,48,0.94)"
+      },
+      "boundary": {
+        "default": "#3d3d3d",
+        "strong": "#3d3d3d",
+        "area": "#161616",
+        "indent": "#656565",
+        "divider": "#2e2e2e"
+      },
+      "content": {
+        "primary": "#e6e6e6",
+        "muted": "#c3c3c3",
+        "dim": "#969696",
+        "onAccent": "#ffffff",
+        "menu": "#dddddd",
+        "status": "#888888",
+        "placeholder": "#5e5e5e",
+        "active": "#ffa028",
+        "selected": "#e96a00",
+        "onBright": {
+          "primary": "#1d1d1d",
+          "muted": "rgba(29,29,29,0.82)",
+          "dim": "rgba(29,29,29,0.7)"
+        }
+      },
+      "accent": {
+        "default": "#4772b3",
+        "muted": "#4772b3"
+      },
+      "widget": {
+        "regular": "#545454",
+        "menu": "#282828",
+        "field": "#1d1d1d",
+        "emboss": "rgba(0,0,0,0.149)"
+      },
+      "viewport": {
+        "background": "#3d3d3d",
+        "grid": "#545454",
+        "axisX": "#cb293f",
+        "axisY": "#69aa15",
+        "selection": "#ed5700",
+        "active": "#ffa028"
+      },
+      "region": {
+        "outliner": "#282828",
+        "properties": "#303030"
+      },
+      "category": {
+        "object": "#e19658",
+        "modifier": "#74a2ff",
+        "material": "#cc6670",
+        "data": "#00d4a3",
+        "scene": "#cccccc",
+        "collection": "#ffffff",
+        "tool": "#cbcbcb",
+        "operator": "#95dab2"
+      },
+      "semantic": {
+        "danger": "#e0524a",
+        "dangerMuted": "rgba(224,82,74,0.28)",
+        "dangerFaint": "rgba(224,82,74,0.12)",
+        "warning": "#e5b83c",
+        "warningMuted": "rgba(229,184,60,0.28)",
+        "success": "#6fbf5f",
+        "successMuted": "rgba(111,191,95,0.28)",
+        "dynamic": "#e5b83c",
+        "dynamicMuted": "rgba(229,184,60,0.18)",
+        "instance": "#ffa028"
+      },
+      "neutralOverlay": {
+        "hover": "rgba(255,255,255,0.08)",
+        "active": "rgba(255,255,255,0.14)"
+      },
+      "scrim": "rgba(0,0,0,0.6)"
+    },
+    "typography": {
+      "sans": "'Inter', 'DejaVu Sans', system-ui, sans-serif",
+      "mono": "'DejaVu Sans Mono', Menlo, monospace"
+    }
+  }
+}

package/contributions/blender.status.tsx

@@ -0,0 +1,263 @@
+/**
+ * Blender's MOUSE HINTS, at the left of the status bar (`workspace.status`).
+ *
+ * Blender's bottom row opens with three tiny mouse glyphs, each with one
+ * button lit and the action it performs beside it — `Select`, `Rotate View`,
+ * `Options` in the reference (`modeling.png`). It is the one piece of chrome
+ * that tells a newcomer what the three buttons DO without a menu, and the
+ * gap a human build session measured here was exactly that question ("how do
+ * I move the camera", six times — `viewport-controls-hint.ts`).
+ *
+ * THEY ARE HOVER-DRIVEN THERE, AND ALWAYS-ON HERE. Measured across the whole
+ * reference set: `modeling.png` is the ONE frame with any ink left of centre
+ * in the status band; `layout`, `modeling-edit-none`, `modeling-edit-all`,
+ * `modeling-object-selected`, `sculpting` and `texture-paint` all have ZERO
+ * ink before device x 3325 — Blender publishes the keymap for whatever the
+ * cursor is over, so a still with the pointer outside the 3D View shows
+ * nothing. A still therefore cannot say whether Blender's band is empty by
+ * design; it can only say what the hints look like WHEN they are drawn, which
+ * is what the geometry below is measured from. Ours are unconditional
+ * because the editor has no hover-scoped keymap publisher and inventing one
+ * to match a screenshot would be a mechanism with no other reader.
+ *
+ * THE ACTION NAMES ARE OURS, NOT BLENDER'S. What each button does is a fact
+ * about THIS editor, so the labels are read from this editor's own contract,
+ * never transcribed from the reference:
+ *
+ *   - the KEYMAP (`keymap-presets.ts`, `@volter/editor-sdk/looks`) binds no
+ *     mouse buttons and structurally cannot: a `KeyChord` is
+ *     `{ key, code?, mod?, shift?, alt? }` (`editor-sdk/src/looks.ts:76-82`)
+ *     with no button field, so no keymap — the Blender one included — can
+ *     move a mouse binding. Nothing to read there.
+ *   - so the source is the VIEWPORT's own mouse contract:
+ *     `editor-viewport.ts:682-686` sets `orbitControls.mouseButtons` to
+ *     `{ LEFT: -1, MIDDLE: PAN, RIGHT: ROTATE }`, and the left button is left
+ *     free for the selection raycast (`editor-viewport.ts:3782`,
+ *     `if (e.button === 0 && !e.altKey)`). The editor's own prose says the
+ *     same thing (`ViewportControlsHint.tsx:22`: "Orbit: right-drag · Pan:
+ *     middle-drag").
+ *
+ * That contract is a constant of the host, not of any document, so the table
+ * below is a constant too — with the citations above as its provenance. When
+ * a surface ever makes a button mean something else, it publishes that and
+ * this reads it; it does not get hardcoded here.
+ *
+ * The inline styles spell the theme tokens directly (`var(--vgai-space-5)`,
+ * `var(--vgai-font-md)`) instead of importing the host's `spaceVar` /
+ * `fontSizeVar` handles: `@volter/editor-blender` is pinned at ZERO host imports
+ * (`validate-editor-closure.mjs`). See `blender-version.status.tsx`.
+ */
+
+export const point = 'workspace.status';
+export const title = 'Mouse hints';
+export const align = 'left';
+/** Front of the contributed band — see the note at the bottom of this file
+ *  for why that is not the front of the bar. */
+export const order = 0;
+
+/** Which button the glyph lights. */
+type MouseButton = 'left' | 'middle' | 'right';
+
+/**
+ * The viewport's three buttons, in Blender's order. Sourced from
+ * `editor-viewport.ts:682-686` + `:3782` (see the header) — the editor's
+ * contract, which is why the middle/right labels are Pan/Orbit and not
+ * Blender's own Rotate View/Options.
+ */
+const HINTS: readonly { readonly button: MouseButton; readonly label: string }[] = [
+  { button: 'left', label: 'Select' },
+  { button: 'middle', label: 'Pan View' },
+  { button: 'right', label: 'Orbit View' },
+];
+
+/**
+ * One mouse glyph in Blender's idiom, TRANSCRIBED FROM THE FRAME rather than
+ * estimated: `modeling.png` at native 2x (the only reference frame whose
+ * status bar carries the hints — see the note under {@link HINTS}), glyph 1 at
+ * device x 12..35, y 2065..2096. Halved, that is a 12 x 16 CSS ink box, and
+ * the viewBox IS that box so the SVG needs no scale factor to reason about:
+ * one unit is one CSS pixel at the size below.
+ *
+ * MEASURED BY COVERAGE, NOT BY A THRESHOLD. Every number below is the 50%
+ * contour of `(value - 23) / (135 - 23)` — an ink threshold reads a glyph's
+ * antialiasing as geometry and got two of these badly wrong on the first cut.
+ * Device reading -> CSS (the ink box's left edge is device -0.5, so
+ * `css = (device + 0.5) / 2`):
+ *
+ *   shell stroke       1.98 device, flat on every side row -> {@link STROKE} 1
+ *   button row height  16 of 32 device -> {@link BUTTON_H} 8, exactly half
+ *   lit button width   left fill ends 9.5 / right fill starts 13.5 device
+ *                      -> {@link BUTTON_W} 5, a button at each end
+ *   divider            the shell's top edge stops at 11.98 device in the
+ *                      left-lit glyph and starts there in the right-lit one
+ *                      -> {@link DIVIDER_X} 6.25, ONE boundary, not a gap
+ *                      centred on the middle
+ *   gap under button   2 device of nothing (fill ends row 15, stroke resumes
+ *                      row 18) -> {@link UNDER_GAP} 1
+ *   wheel              8 x 14 device at x 8, y 4, ends rounded at r 2.5
+ *                      -> 4 x 7 at 4, 2, rx 1.25
+ *
+ * THE LIT BUTTON IS NOT AN INSET NUB AND NOT A CLIPPED OVERLAY: in the frame
+ * the fill REPLACES the shell over its own quadrant (a mid row reads ten solid
+ * device px from the very left edge) and the shell stroke is absent for two
+ * device rows beneath it and across the divider on the top edge. So the fill
+ * is the outer silhouette intersected with the button rect, and the stroke is
+ * MASKED OUT over the button's side of the divider down to the hairline —
+ * which is why there is a mask here and not the clip the earlier cut used.
+ *
+ * (Superseded readings, kept so the next round does not re-derive them: a
+ * 13x17 box with a 1.7 stroke and a 0.45 hairline, sized to the text's own
+ * font size. Both came from a DPR-1 capture against a downscaled reference,
+ * which is the instrument WORK.md records as unable to settle stroke weights;
+ * at native 2x the glyph measures 16 CSS tall against 9 CSS of cap height,
+ * not the ~1:1 that reading reported.)
+ *
+ * RESIDUE, measured and not fitted away: Blender's TOP edge integrates 3.0
+ * device px of coverage where its sides integrate 1.98. One uniform stroke
+ * cannot draw both, and a second stroke for the top would be a constant with
+ * no reason behind it; the sides are the ones that set the glyph's weight.
+ */
+const STROKE = 1;
+const BUTTON_H = 8;
+const BUTTON_W = 5;
+const UNDER_GAP = 1;
+/**
+ * Where the shell's top edge stops for a lit LEFT button and starts again for
+ * a lit RIGHT one — ONE boundary, at device 11.98 in both glyphs, not a gap
+ * straddling the centre. The button fills stop short of it by 1.25 on the left
+ * and start 0.75 past it on the right, which is why modelling this as a
+ * symmetric "gap" beside a button could not reproduce either glyph.
+ */
+const DIVIDER_X = 6.25;
+/**
+ * The shell's OUTER corner radius, and the number two cuts got wrong — first
+ * as a capsule (half the width), then as 2 from an ink threshold. SOLVED on
+ * the 50% contour of the middle glyph's bottom-left and top-right corners
+ * (`modeling.png`, device x 122..145, y 2065..2096): the contour runs 4.04,
+ * 2.39, 1.33, 0.55, 0.05, -0.28 device from the straight edge over successive
+ * rows, and a circle of radius 7.16 device reproduces all six to within 0.11.
+ * The opposite corner independently gives 7.2. Halved, 3.6 — and both wrong
+ * answers were visible at full scale as the wrong SHAPE, not the wrong size.
+ */
+const RADIUS = 3.6;
+/** The ink box, in CSS px, and the viewBox. */
+const BOX = { width: 12, height: 16 } as const;
+
+function MouseGlyph({ button }: { button: MouseButton }) {
+  const id = `vgai-mouse-${button}`;
+  const rightX = BOX.width - BUTTON_W;
+  const fillX = button === 'right' ? rightX : 0;
+  // The stroke's own rect runs along the centre line of a 1-unit stroke, so it
+  // is inset half a stroke and its radius drops by the same half.
+  const half = STROKE / 2;
+  const outerRx = RADIUS;
+  return (
+    <svg
+      viewBox={`0 0 ${BOX.width} ${BOX.height}`}
+      role="presentation"
+      aria-hidden="true"
+      focusable="false"
+      // 16 CSS px, which is the `lg` icon rung — and Blender's glyph measures
+      // exactly 16 CSS tall in the frame. `width: auto` then resolves to 12
+      // from the viewBox, the measured width, with no second number to drift.
+      style={{ height: 'var(--vgai-icon-lg)', width: 'auto', display: 'block', flex: '0 0 auto' }}
+    >
+      <title>{button} mouse button</title>
+      {/* The outer silhouette: what the fill is intersected with, so the lit
+          quadrant follows the shell's rounded shoulder. */}
+      <clipPath id={`${id}-outer`}>
+        <rect x="0" y="0" width={BOX.width} height={BOX.height} rx={outerRx} />
+      </clipPath>
+      {/* Where the shell stroke is NOT drawn: the lit button's whole side of
+          the divider, down to the hairline beneath the button. */}
+      <mask id={`${id}-shell`}>
+        <rect x="0" y="0" width={BOX.width} height={BOX.height} fill="white" />
+        {button !== 'middle' && (
+          <rect
+            x={button === 'right' ? DIVIDER_X : -1}
+            y={-1}
+            width={button === 'right' ? BOX.width - DIVIDER_X + 1 : DIVIDER_X + 1}
+            height={BUTTON_H + UNDER_GAP + 1}
+            fill="black"
+          />
+        )}
+      </mask>
+      <rect
+        x={half}
+        y={half}
+        width={BOX.width - STROKE}
+        height={BOX.height - STROKE}
+        rx={outerRx - half}
+        fill="none"
+        stroke="currentColor"
+        strokeWidth={STROKE}
+        mask={`url(#${id}-shell)`}
+      />
+      {button !== 'middle' && (
+        <rect
+          x={fillX}
+          y="0"
+          width={BUTTON_W}
+          height={BUTTON_H}
+          fill="currentColor"
+          clipPath={`url(#${id}-outer)`}
+        />
+      )}
+      {button === 'middle' && (
+        <rect x="4" y="2" width="4" height="7" rx="1.25" fill="currentColor" />
+      )}
+    </svg>
+  );
+}
+
+export default function BlenderMouseHintsStatus() {
+  return (
+    <span
+      className="vgai-status-copy"
+      data-testid="status-blender-mouse-hints"
+      // Blender's hint-to-hint gap is 9.5 CSS (glyph 1 ends at 51.5, glyph 2
+      // starts at 61; the second gap repeats it to a tenth). `space-5` is 10.
+      style={{ display: 'inline-flex', alignItems: 'center', gap: 'var(--vgai-space-5)' }}
+    >
+      {HINTS.map((hint) => (
+        <span
+          key={hint.button}
+          data-mouse-button={hint.button}
+          // NO COLOUR HERE. The band declares its own ink and Blender's status
+          // bar is the DIMMEST text in its window — `#878787` (135) flat, on
+          // every frame, against the 216 its top-bar menus ink. A contribution
+          // that pins `content.muted` (194) makes itself the loudest thing in
+          // the quietest band; inheriting is what keeps the band one voice.
+          //
+          // The SIZE is measured: Blender's status text caps at 9.0 CSS (18
+          // device), which is the `md`/`base` rung (11px -> 8.8), not `sm`
+          // (10px -> 8.0).
+          style={{
+            display: 'inline-flex',
+            alignItems: 'center',
+            gap: 'var(--vgai-space-1)',
+            fontSize: 'var(--vgai-font-md)',
+          }}
+          title={`${hint.label} — the ${hint.button} mouse button in the viewport`}
+        >
+          <MouseGlyph button={hint.button} />
+          {hint.label}
+        </span>
+      ))}
+    </span>
+  );
+}
+
+/**
+ * ORDER, and the one thing this cannot have. Blender's hints are the
+ * LEFTMOST thing in its bottom row. A contributed status item cannot be:
+ * `tool-loader.ts:1145` registers it at `contributedSectionOrder(order)`,
+ * which is `CONTRIBUTED_SECTION_ORDER + (order ?? 999)`
+ * (`tool-loader.ts:359-361`) with `CONTRIBUTED_SECTION_ORDER = 5000`
+ * (`inspection/model.ts:475`), while the host's own left items register at
+ * -90..40 (`components/status-contributions.tsx`). Every contributed item
+ * therefore lands BEHIND every core item, by construction — the band exists
+ * precisely so a contribution cannot outrank a built-in. `order = 0` is the
+ * front of what the contract allows: first among contributed left items,
+ * after the host's save/console/play cluster.
+ */

package/contributions/blender.style.ts

@@ -0,0 +1,271 @@
+/**
+ * The BLENDER style bundle — Blender's greys and widget blue as a palette
+ * document (`blender.palette.json`, the same v3 shape a person imports), its
+ * own opaque material, and Blender's chrome regions
+ * (`@volter/editor-sdk/looks`, a `workspace.style` contribution).
+ *
+ * The material transcribes Blender's default theme: widgets round at 0.2 of
+ * their height (4px on a 20px widget), areas and panels are flat with no
+ * shadow, and only menus and popovers cast one (`menu_shadow_fac` 0.5 over
+ * `menu_shadow_width` 4). The `large` radius is our reading — Blender rounds
+ * its popovers the same as its menus. The density is measured from Blender
+ * 5.2's own frames at 1x (`/Volumes/PeakSSD/volter-work/blender-reference`):
+ * 26px top bar and area headers, 24px status bar, and — re-measured against
+ * the frames widget by widget — EVERY widget 20px tall, button/field/toggle
+ * alike, so all three control sizes are 20 rather than a 18/20/24 ramp
+ * Blender does not have. Its UI face measures 11px (an 8px cap+ascender on
+ * "Add Modifier"); the rest of the type scale is our reading.
+ *
+ * THE ICON SET (`blender.icons.json`) IS PART BLENDER'S, AND THAT IS WHY THIS
+ * PACKAGE CARRIES TWO LICENCES. Of its 346 glyphs, 197 are machine-TRACED —
+ * byte for byte — from Blender's own vector sources
+ * (`release/datafiles/icons_svg/*.svg`, 188 distinct files at the engine's
+ * pin): an affine transform of Blender's outline onto a 16-unit grid, nothing
+ * re-proportioned or re-centred, so a traced glyph IS Blender's drawing and a
+ * derivative of GPL-2.0-or-later artwork. Their provenance — `ICON_*` name,
+ * source file and sha256 per glyph — is `blender.icons.traced.json`, written
+ * by `blender-icon-trace.mjs`. The other 149 are our own drawings in Blender's
+ * idiom: a 16-unit grid, monochrome filled silhouettes, ~1.3-unit round-ended
+ * strokes, no outline around a fill.
+ *
+ * So `@volter/editor-blender` is `AGPL-3.0-only AND GPL-3.0-or-later` — our code AGPL,
+ * Blender's artwork GPL, combined under each licence's §13
+ * (`packages/blender/LICENSE` carries the notice and both texts). NOTHING
+ * TRACED MAY BE COPIED INTO AN APACHE-2.0 OR MIT PART OF THIS REPO;
+ * `packages/editor`'s own icon set in particular stays free of it.
+ *
+ * A glyph is EDITED in `blender-icons.source.mjs` and the JSON re-emitted by
+ * running it; a path `d` is not a thing a person edits by hand.
+ */
+import type { IconSetContribution, StyleContribution } from '@volter/editor-sdk/looks';
+import iconsJson from './blender.icons.json';
+import palette from './blender.palette.json';
+
+/**
+ * `resolveJsonModule` widens every string in a JSON import, so each glyph's
+ * `tone` arrives typed `string` rather than the `IconCategoryTone` union it
+ * holds. The generator is what narrows it: `blender-icons.source.mjs` checks
+ * every assignment against the union's own member list and throws on a name
+ * outside it, so the JSON cannot carry a tone this type does not have.
+ */
+const icons = iconsJson as IconSetContribution;
+
+export const point = 'workspace.style';
+export const style: StyleContribution = {
+  id: 'blender',
+  title: 'Blender',
+  paletteId: 'blender',
+  materialId: 'blender',
+  material: {
+    id: 'blender',
+    title: 'Blender',
+    description: 'Flat opaque areas, four-pixel widget corners, shadows under menus only.',
+    shape: { small: '4px', medium: '4px', large: '4px', full: '9999px' },
+    elevation: {
+      small: 'none',
+      medium: '0 4px 12px rgba(0,0,0,0.5)',
+      large: '0 6px 18px rgba(0,0,0,0.55)',
+    },
+    density: {
+      control: { compact: 20, default: 20, comfortable: 20 },
+      font: { xs: 9, sm: 10, base: 11, md: 11, lg: 12 },
+      // Blender's glyphs, measured at matched scale: 14 px through the
+      // chrome (the Properties tab rail in `properties-data-edit.png`, the
+      // Outliner's row and toggle marks in `outliner.png`).
+      //
+      // `2xl` is now MEASURED too, and it came down from the extrapolated 20.
+      // Its only consumer is the viewport navigation cluster
+      // (`ViewportFurniture.tsx`), and Blender's own cluster in
+      // `modeling-object-none.png` draws 15x15 px of INK at 1x. These glyphs
+      // ink at ~0.85 of their box (`blender-icons.source.mjs`'s `S` dial), so
+      // 15 px of ink is an 18 px box — at 20 the cluster measured 17x17,
+      // two pixels heavier than the frame it is copying.
+      //
+      // `xs` IS MEASURED NOW, and the note it replaces was wrong about the
+      // frames: they do show glyphs below the 14 px chrome rung — the claim
+      // had only ever looked at the status bar. The whole sub-14 inventory,
+      // ink bounding boxes in CSS px (device halved), all at native 2x:
+      //
+      //   `+` Add Modifier      `properties-modifier.png`   9.0 x 9.0
+      //   `+` list add          `properties-data-edit.png`  9.0 x 9.0
+      //   chevron, list button  `properties-data-edit.png`  9.0 x 5.0
+      //   chevron, panel band   `properties-data-edit.png`  9.0 x 5.0
+      //   caret, datablock well `properties-data-edit.png`  6.5 x 4.0
+      //   caret, editor-type    `properties-modifier.png`   6.5 x 4.0
+      //   grip `::::`           `properties-data-edit.png` 10.0 x 4.0
+      //   triangle, list row    `properties-data-edit.png`  6.0 x 5.0
+      //
+      // FOUR of those agree at 9.0 wide and that is the rung. Solved against
+      // the one glyph both sides draw on the same fill (`#535353`, so the
+      // threshold is identical): Blender's `+` arms measure 17.43 and 17.08
+      // device px by sub-pixel coverage, mean 8.63 CSS; ours at `xs` 12
+      // measure 20.75 device (10.38 CSS, against the path's own geometric
+      // bbox of 10.48 — they agree to a tenth). Our glyphs ink 0.865 of the
+      // box, so the box that inks 8.63 is 9.98. Two other estimators on the
+      // same pair — ink MASS (mass scales as the square, ratio 0.8171) and
+      // the pixel bbox (18/22 = 0.818) — give 9.81 and 9.82. The rung is 10.
+      //
+      // THE RUNG WAS CHECKED AGAINST A SECOND GLYPH FAMILY AFTER LANDING,
+      // and it holds: at 10 the dock well's caret inks 5.84 x 3.71 CSS
+      // against Blender's editor-type caret at 6.0 x 4.0 (12 x 8 device,
+      // `properties-modifier.png` x 62..73, y 23..30). Our chevron inks 0.58
+      // of its box where the `+` inks 0.87, so the two agree on the rung
+      // only because each was solved against its own counterpart — which is
+      // why both were measured rather than one inferred from the other.
+      //
+      // RESIDUE, measured not closed: Blender has TWO chevron sizes, the
+      // well caret at 6.0 wide and the panel-band / list-button chevron at
+      // 9.0, and they are not a uniform scale of each other (0.67 wide
+      // against 0.80 tall). One rung cannot serve both; our chevron lands on
+      // the well caret, so a band chevron drawn at `xs` would ink 5.84 where
+      // Blender's inks 9.0. Closing that needs a second glyph, not a rung —
+      // and no expanded band is on screen in the Model document to confirm
+      // it against.
+      icon: { xs: 10, sm: 14, md: 14, lg: 16, xl: 16, '2xl': 18 },
+      chrome: {
+        commandBar: 26,
+        panelHeader: 26,
+        localToolbar: 26,
+        treeRow: 20,
+        // The Outliner's tree is a SQUARE grid — one level steps by the row's
+        // own height. Measured on the native 2x `outliner.png`: the type
+        // glyphs of Scene Collection, Collection and Camera centre at x 60.5,
+        // 100.5 and 140.5 device px (30.25 / 50.25 / 70.25 CSS) and each
+        // row's chevron sits one cell to the left of its glyph (Collection's
+        // at 30.25, Camera's at 50.25), so the step is 20 and the chevron and
+        // the glyph each own one cell of it.
+        treeIndent: 20,
+        statusBar: 24,
+        // The toolbar, RE-MEASURED 2026-09-18 on the native 2x frame
+        // (`modeling-edit-none.png`, column x=25 and row y=400): a tool is a
+        // 40x35 BORDER BOX — 38x34 of `widget.menu` fill inside a one-pixel
+        // boundary — and the boxes are CONTIGUOUS within a group, sharing that
+        // one pixel, so the pitch down a strip is 35. Plain viewport shows
+        // only BETWEEN groups (four times in Blender's twenty-one-tool rail).
+        // These three numbers are the border box, because that is what the
+        // rail's CSS sets and what the collapse (`margin-block-start: -1px`
+        // in `workspace-dock.css`) measures against: 36 - 1 = the 35 pitch.
+        //
+        // `toolGap` RE-RE-MEASURED 2026-09-19 on the same frame, BOX EDGE TO
+        // BOX EDGE rather than fill to fill: group 1's border box ends at
+        // device y 312 and group 2's begins at 323, so the separation is 10
+        // device px — 5 CSS, not the 7 or 8 the two earlier readings gave.
+        // Both were counting the group's own 1 CSS px emboss (device rows
+        // 313-314, luminance 53 over the viewport's 63) and the two borders
+        // as part of the bare viewport between the groups.
+        toolSize: 36,
+        toolWidth: 40,
+        toolGap: 5,
+        // THE AREA SEAM, measured on the native 2x `modeling.png`: the
+        // Outliner-to-Properties groove (median over x 2900..3400) runs
+        // y 419..425 as (21,21,21) and the viewport-to-Properties groove
+        // runs x 2836..2842 as the same value — 7 device px, 3.5 CSS px,
+        // both times with a one-pixel lighter emboss on each side. The
+        // colour is the palette's `color.boundary.area`.
+        areaSeam: 3.5,
+        // THE EMBOSS on each side of that groove, as percent of white mixed
+        // into the area's OWN fill. SOLVED on the native 2x `modeling.png`
+        // from four fills and their light bands — Properties 47 -> 64
+        // (x=3200, y 426..427), Outliner 39 -> 57/56 (y=300, x 2843..2844),
+        // the Properties tab rail 23 -> 43/42 (y=1500, same columns), the
+        // Outliner's alternate row 42 -> 59/60 (x=3200, y 417..418) — whose
+        // individual alphas are 8.17/8.10/8.62/8.45%, mean 8.14; 8.2 is the
+        // one value that renders all four measured integers. The viewport's
+        // 63 -> 93/94 and the 3D View header's 52 -> 86 are this same lift
+        // applied TWICE; see `theme.ts`'s `areaEmbossValue`.
+        areaEmboss: 8.2,
+      },
+      viewport: {
+        // BLENDER'S GIZMO IS A CONSTANT SCREEN SIZE (owner, 2026-09-21: "is
+        // gizmo perhaps the wrong size?"). `U.gizmo_size` is 75
+        // (`DNA_userdef_types.h:1095`; Preferences > Viewport > Gizmos > Size,
+        // `rna_userdef.cc:5415-5419`, range 10..200), and it is px PER GIZMO
+        // UNIT: `wm_gizmo.cc:450-474` sets `scale_final = scale_basis *
+        // UI_SCALE_FAC * U.gizmo_size * ED_view3d_pixel_size_no_ui_scale(...)`,
+        // whose last term is world units per DEVICE px against a
+        // `UI_SCALE_FAC` of device px per UI px — so one gizmo unit is 75 CSS
+        // px whatever the display scale (read back from the engine's own pin
+        // on this box: `ui_scale=2.0 pixel_size=2.0 gizmo_size=75`).
+        gizmoSize: 75,
+        // BLENDER'S SHELF OPENS ON SELECT BOX, so a selected object carries no
+        // transform gizmo until one of the four transform tools is armed
+        // (`space_toolsystem_toolbar.py`: `_defs_view3d_generic.select_box` is
+        // the first entry of the Object Mode `_tools_default` tuple).
+        // Photographed at the engine's pin rather than remembered:
+        // `gizmo-select-box.png` has Select Box lit in the shelf, the default
+        // cube selected and outlined orange, and nothing at its origin but the
+        // 3D cursor and the object dot; `gizmo-move.png` has Move lit in the
+        // same frame. Ours opened on the COMBINED gizmo — Unity's shape, three
+        // tools' handles at once, on something merely selected.
+        shelfTool: 'select',
+        // BLENDER'S WORLD IS Z-UP, and the stage presents it through the exact
+        // signed permutation `(x, y, z) → (x, z, −y)` the presented root
+        // carries (`blender-runtime-view.ts`'s constructor). So three's Y is
+        // Blender's Z and three's Z is Blender's −Y, and the transform gizmo's
+        // colours, the side each arm is drawn on, the plane squares and the
+        // navigation gizmo's six labels all say so: the arm that points up is
+        // Z and it is blue, Y is green and points away.
+        upAxis: 'z',
+        // BLENDER'S SELECT BOX IS A TOUCH TEST — its object-mode box select
+        // reads the object-id buffer under the rectangle, so any drawn part of
+        // an object inside it selects that object. The editor's own answer is
+        // containment, for its own measured reason; see the field.
+        boxSelect: 'touch',
+      },
+    },
+  },
+  icons,
+  regions: {
+    workspaceTabs: 'shown',
+    // Blender has no document tab strip over its areas (the host's own note
+    // in `workspace-presets.ts` says so; the bundle contradicted it).
+    header: 'shown',
+    shelf: 'shown',
+    inspector: 'properties',
+    // Measured on `modeling.png`: Blender's top-right corner carries two quiet
+    // wells (Scene, ViewLayer) and nothing brighter than the 216 its labels
+    // ink at. Ours drew a yellow FPS/ms readout, an orange sparkline and a lit
+    // audio meter there — the brightest, highest-chroma thing in the frame and
+    // the first place the eye lands. The numbers keep their door (the Profiler
+    // utility, which the readout's own tooltip names).
+    telemetry: 'hidden',
+    // Measured on `outliner.png`: Scene Collection, Collection, Camera, Cube
+    // and Light each carry their NAME and nothing after it — no type text
+    // anywhere in the frame. The type is the GLYPH, which is why the glyph is
+    // coloured by category in the first place; a row that also spelled the
+    // type would say it twice. Ours printed `Hero Box ·HeroBox` at
+    // `content.dim` in a 10px face, one `space-2` past the name.
+    hierarchyTypeSuffix: 'hidden',
+    // Measured across all three Outliner frames — `outliner.png` (edit mode),
+    // `modeling-object-none.png` (object mode, nothing selected) and
+    // `modeling-object-selected.png` (object mode, everything selected):
+    // Blender draws NO rule, dotted or solid, under any name in that panel, in
+    // any selection state. Ours drew an orange dotted rule under every
+    // component-instance name — six of this scaffold's eleven rows — which is a
+    // mark with no counterpart in the frame at all. The instance fact keeps its
+    // doors (the label's tooltip, Go to Callsite / Open Component Source, the
+    // inspector's component sections); only the paint yields.
+    hierarchyInstanceRule: 'hidden',
+    // Measured on `outliner.png`: every object row carries an EYE (CSS ink
+    // 257.5-270.5, 32 px in from the area's right edge) and a render CAMERA
+    // (277.5-290.5, 12 px in) on a 20 px column pitch, and no lock glyph
+    // anywhere — Blender's Disable Selection column is off by default. Ours
+    // drew a lock 29-41 px in and the eye 6-18 px in, so the LOCK was sitting
+    // in Blender's eye column and the eye outboard of its camera column. The
+    // lock goes, and the render column is reserved blank so the eye lands on
+    // Blender's own; `workspace-regions.ts` carries why it stays blank.
+    hierarchyRestrictions: 'viewport+render',
+    // Measured at native 2x on `outliner.png` AND on the Properties area of
+    // `modeling-edit-none.png` — device x relative to each area's own left
+    // edge, and the two agree to half a pixel: every Blender area begins with
+    // an EDITOR-TYPE WELL at x 17..80, i.e. 8.5 CSS in and 32 CSS wide, 20
+    // tall, its glyph and a chevron inside a 1 px `#3c3c3c` outline over a
+    // `#272727` inner. It is there whether the area holds one editor or a
+    // dozen, and its dropdown is how an area changes editor. Ours began with
+    // a 203 px strip of WORDS, which is what squeezed the Outliner's search
+    // to 64 px against Blender's 115, truncated the third tab to `Libr`, and
+    // left the Properties area — a lone panel declaring no header controls —
+    // with no header band at all.
+  },
+  palette,
+};