@volter/editor-blender 0.1.150 → 0.1.152

package/contributions/blender.style.ts

@@ -1,45 +1,6 @@
-/**
- * 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/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:
- * 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.
- */
+/** Blender’s workspace style supplies theme colours, opaque material, typography and region geometry. Widgets round at 0.2 of their height; menus and popovers carry the theme shadow. blender-icons.source.mjs generates the icon set. Traced Blender artwork is GPL-3.0-or-later, combined with this package’s AGPL-3.0-only code under both licences’ section 13; preserve LICENSE and per-glyph provenance in blender.icons.traced.json. Do not copy traced artwork into Apache-2.0 or MIT packages. */
 import type { IconSetContribution, StyleContribution } from '@volter/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
@@ -54,7 +15,8 @@ export const point = 'workspace.style';
 export const style: StyleContribution = {
   id: 'blender',
   title: 'Blender',
-  paletteId: 'blender',
+  // Theme role values come from userdef_default_theme.c through scripts/workbench/generate-blender-theme.mjs. JSON carries the palette; constants below define this style’s chrome geometry.
+  colorTheme: 'blender',
   materialId: 'blender',
   material: {
     id: 'blender',
@@ -69,139 +31,47 @@ export const style: StyleContribution = {
     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 boxes account for each glyph’s optical extent; small controls, ordinary chrome and viewport navigation use distinct rungs.
       icon: { xs: 10, sm: 14, md: 14, lg: 16, xl: 16, '2xl': 18 },
       chrome: {
+        // The top bar's height, traced from Blender 5.2's own frames at 1x.
         commandBar: 26,
         panelHeader: 26,
         localToolbar: 26,
+        // Blender’s Outliner row pitch is 20 CSS pixels.
         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.
+        // Outliner depth steps by one row-height cell; each row’s chevron occupies the cell before its type glyph.
         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.
+        // Toolbar dimensions are border boxes. Adjacent tools share a one-pixel boundary; toolGap separates 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`.
+        // The area seam is a 3.5-CSS-px dark groove between docked areas.
         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`.
+        // Emboss mixes white into each area’s own fill; overlapping viewport passes apply the lift twice.
         areaEmboss: 8.2,
+        // Viewport navigation uses its own 28-px button size rather than the 20-px menu/header control height.
+        navigationControl: 28,
+        // Center the collapsed 4.5×9 and expanded 8.5×5 CSS-pixel carets in an 18-pixel cell.
+        treeCaret: 18,
+        // Outliner glyph plates use a 5-CSS-px corner radius.
+        treeGlyphPlateRadius: 5,
+        // Composite Outliner glyphs at 0.80 over the row fill.
+        treeGlyphOpacity: 0.8,
       },
     },
     stage: {
-      // 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`).
+      // Blender gizmo units stay 75 CSS px at every display scale, using world units per device pixel and UI_SCALE_FAC.
       gizmoSize: 75,
       // A resting handle at 0.6 opacity, a highlighted one opaque in its own colour
       // (`transform_gizmo_3d.cc`, `gizmo_get_axis_color`).
       gizmoOpacity: 0.6,
-      // BLENDER'S OUTLINE IS A HARD LINE, and hidden parts are not drawn: four device pixels
-      // of orange around the cube in `modeling-object-selected.png` (at 2x), no halo.
+      // Blender’s selection outline is a hard 2-CSS-pixel line without a halo; hidden parts are not drawn.
       outlineStyle: 'crisp',
       outlineWidth: 4,
       outlineHidden: false,
-      // BLENDER'S FLOOR LINES, in device pixels, measured across one scanline of
-      // `modeling-object-none.png` at device resolution: the 1 m line is 4 px at half rise and
-      // plateaus at 83, the 10 m line is 6 px and plateaus at 101 — so the major line is wider
-      // (2.25 against 1.5) and carried (102 − 63) / (84 − 63) past the minor's colour from the
-      // background they share. Stated here, the look's, since the editor's own floor is a
-      // single hairline level.
+      // The Blender floor uses distinct major/minor line widths and colour strengths over the shared background.
       gridLineWidth: 1.5,
       gridMajorWidth: 2.25,
       gridMajorContrast: 39 / 21,
@@ -215,5 +85,8 @@ export const style: StyleContribution = {
     },
   },
   icons,
-  palette,
+  typography: {
+    sans: "'Inter', 'DejaVu Sans', system-ui, sans-serif",
+    mono: "'DejaVu Sans Mono', Menlo, monospace",
+  },
 };

package/contributions/blender.verbs.ts

@@ -0,0 +1,52 @@
+/** Session Blender verbs relay to volter.<verb> commands registered by the page half. Each manifest entry owns its timeout and derived-refresh policy. Mutating commands present a frame and refresh the document; handlers use only SDK host doors. */
+import type { VerbHandler } from '@volter/sdk/commands';
+import { handleBlenderCommand } from '../host/blender-runtime-host';
+
+/** The lane's one handler, for every verb. */
+const handle: VerbHandler = (cmd) => handleBlenderCommand(cmd as { type: string; [key: string]: unknown });
+
+export const blenderVerbs: Readonly<Record<string, VerbHandler>> = {
+  // Presentation-only comparison, no engine mutation or derived frame refresh.
+  'blender-draw-batching': handle,
+  'blender-start': handle,
+  // Stop drains accepted modeling work and persists it before teardown.
+  'blender-stop': handle,
+  'blender-execute': handle,
+  'blender-native-preview': handle,
+  'blender-scene-info': handle,
+  'blender-object-info': handle,
+  'blender-screenshot-view': handle,
+  'blender-read-file': handle,
+  'blender-write-file': handle,
+  // File listing uses the worker-read timeout while presentation and derived reads finish.
+  'blender-list-files': handle,
+  // RNA reads expose properties and context without presenting; RNA writes mutate, present and derive.
+  'blender-rna': handle,
+  'blender-rna-context': handle,
+  'blender-rna-set': handle,
+  // Outliner reads expose the View Layer tree; restriction writes mutate, present and derive.
+  'blender-outliner': handle,
+  // The node-tree door is read-only and requires no derivation.
+  'blender-node-tree': handle,
+  // The UV door reads one mesh layout; no UV writer is registered here.
+  'blender-uv-layout': handle,
+  // THE RIG AND CLIP DOORS (the Timeline). Both READS — the skin binding a
+  // `THREE.SkinnedMesh` is built from and the action as three.js tracks — so
+  // neither presents and neither owes a derivation. There is deliberately no
+  // writer beside them: keying, moving a key and setting a range are edits,
+  // and the ONE write the Timeline makes (`scene.frame_current`, once on
+  // pause and at scrub-end) goes through `blender-rna-set`, which already
+  // exists and already presents.
+  'blender-action-clip': handle,
+  // Node-view commands inspect and navigate view state. Editing gestures return the same named refusal as pointer handlers.
+  'blender-node-view': handle,
+  'blender-outliner-set': handle,
+  // A FILM, RENDERED (`cyclotron render-movie`, a film's Blender shots): started, answering at once, then followed
+  // until it ends. The frames are Blender's own renders; each chunk puts the scene's render settings and frame back, so
+  // none presents a change to the model.
+  'blender-render-movie': handle,
+  'blender-render-status': handle,
+  // A read of whether this tab HAS a session; it never starts one — and the
+  // one verb that answers before a project session exists.
+  'blender-status': handle,
+};

package/contributions/model.layout.ts

@@ -1,10 +1,4 @@
-/**
- * The MODEL workspace — Blender-shaped modeling: a dominant document, outliner
- * above properties (`@volter/sdk/looks`, a `workspace.layout`
- * contribution). Its arrangement carries Blender 5.2's own MODELING-workspace
- * proportions; `../src/layouts.tsx` states the measurement and the host's
- * fixed-pane clamp that bounds it.
- */
+/** Model workspace: a dominant document, outliner above Properties and a lower Timeline area. The workbench owns pane geometry. */
 
 import type { WorkspaceLayoutContribution } from '@volter/sdk/looks';
 import { BLENDER_REGIONS } from '../src/regions';
@@ -26,32 +20,6 @@ export const layout: WorkspaceLayoutContribution = {
     inspector: 'properties',
     drawer: 'hidden',
   },
-  // THE TIMELINE IS THE BOTTOM AREA (owner, 2026-09-20: "doesn't blender have
-  // a timeline at the bottom?"). It does — and the workspace this Model
-  // document stands in is Blender's LAYOUT screen for us, not its Modeling
-  // one: Layout is the four-area screen with the Timeline, and Modeling is the
-  // same screen WITHOUT it (measured below).
-  //
-  // THE PROPORTION IS BLENDER'S OWN, measured through bpy on the installed
-  // Blender 5.2.1 at factory settings in a 1920-wide window
-  // (`bpy.data.workspaces['Layout'].screens[0].areas`):
-  //
-  //   PROPERTIES        x1579 y23  w339  h839
-  //   OUTLINER          x1579 y865 w339  h189
-  //   DOPESHEET_EDITOR  x2    y23  w1574 h74    ui_type TIMELINE  ← this area
-  //   VIEW_3D           x2    y100 w1574 h954
-  //
-  // and the same screen at a 1600×929 window gives the Timeline 63 of an
-  // 880-px centre column. Both are the same ratio to three places: 74/1029 =
-  // 0.0719 and 63/880 = 0.0716. The Modeling screen's own reading, for the
-  // contrast: VIEW_3D `x2 y23 w1574 h1031` and no DOPESHEET area at all.
-  //
-  // It is stated to four places because it is a measurement, not a preference;
-  // the dock uses it once, to size the group the first time this workspace
-  // stands up, and a capture of the settled grid wins afterwards.
-  //
-  // IN GAME MODE THE SAME AREA HOLDS THE GAME PANEL (`../src/play-mode.ts`):
-  // the document below draws the Timeline or the panel by the model's mode,
-  // so the area, its proportion and a person's resize all carry over.
+  // The Model workspace’s bottom editor area hosts the Timeline or Game panel. Initial Timeline ratio is Blender Layout’s 74/1029 ≈ 0.0719; a person’s later resize takes precedence.
   areas: [{ id: 'timeline', document: 'blender-timeline.document', place: 'below', ratio: 0.0719 }],
 };

package/contributions/models.finder.ts

@@ -1,33 +1,4 @@
-/**
- * The `modelsFromBlendFiles` FINDER (ARCHITECTURE-CORE §The project model,
- * "A model is Blender data, and a prefab is not a model"): every `.blend`
- * under the selection's `include` globs is a `model` document — a Blender
- * file the engine in the tab opens, edits and saves. The bpy scripts that
- * authored it are ordinary project files beside it (`src/models/<name>.py`);
- * this document does not run them, a person or an agent does, through the
- * session's Blender (`volter blender-mcp`).
- *
- * It replaced `modelsFromMeshModules`, which listed every module exporting
- * `build(): THREE.BufferGeometry` (owner ruling 2026-09-19, "do the delete":
- * the TypeScript mesh kit was the modeling engine while Blender could not run
- * in the tab; it now does, and a model is Blender data).
- *
- * Select it in `editor/volter.adapter.ts`:
- *
- *   documents: { find: [{ finder: 'modelsFromBlendFiles', include: ['src/models/**\/*.blend'] }] }
- *
- * THE SESSION'S OWN MODEL. A project that holds no `.blend` of its own still
- * needs ONE model — it is what `blender-start` presents into and what a first
- * bpy call models in, saved to the session's default `models/model.blend` — so
- * when the selection finds no file, the finder lists the standing
- * `blender:runtime` entry instead. Never beside a real model.
- *
- * This module is a plain object the HOST registers; it mounts no UI. It reads
- * the project only through `input.files` — the PATHS matching those globs.
- * Deliberately not `input.sources`: a `.blend` is binary, there is nothing in
- * it a text walk could honestly read, and the entry is the file itself. It says
- * so (`reads: 'files'`), and the host then lists the files without fetching them.
- */
+
 
 import { z } from 'zod';
 
@@ -62,6 +33,8 @@ export const finder = {
         authorable: true,
         reach: { kind: 'root-mount' as const },
         source: { path },
+        // (the Model document opens a `.blend` not written yet as Blender's empty file, and its first save writes it)
+        opensUnwritten: true,
       });
     }
     if (entries.length === 0) {

package/contributions/properties-bone-constraints.inspector.tsx

@@ -1,19 +1,4 @@
-/**
- * BLENDER'S BONE CONSTRAINTS TAB, as a Properties section (WORK.md §Blender in
- * the tab is Blender, "Inspection parity", I2): the active POSE BONE's
- * constraint stack, with the generic view beneath under "All properties".
- *
- * It is the Object Constraints tab over a different datablock, and Blender
- * says so itself: `properties_constraint.py` registers
- * `BONE_PT_constraints` beside `OBJECT_PT_constraints` with the same
- * `template_constraints()` body, differing only in reading
- * `context.pose_bone.constraints`. So it shares the header list that module
- * exports rather than restating it — a second copy is a second thing to keep
- * in step.
- *
- * It stands when: `buttons_context_path_pose_bone` — a pose channel for the
- * active bone, and never in Edit mode.
- */
+/** Blender’s Bone Constraints Properties tab follows scripts/startup/bl_ui/properties_constraint.py at the engine pin. Curated panels read the RNA context’s datablocks; the generic view remains under All properties. Match tab availability and engine-specific panels against the live context. */
 import { blenderPropertiesTabMatch, blenderPropertiesTabSection } from './blender-properties-tab';
 import type { BlenderCuratedPanel } from './blender-properties-view';
 import { CONSTRAINT_HEADER } from './properties-constraints.inspector';

package/contributions/properties-bone.inspector.tsx

@@ -1,26 +1,4 @@
-/**
- * BLENDER'S BONE TAB, as a Properties section (WORK.md §Blender in the tab is
- * Blender, "Inspection parity", I2). Blender's own panels over the RNA door,
- * with the generic view beneath under "All properties".
- *
- * THE SPECIFICATION IS `scripts/startup/bl_ui/properties_data_bone.py` at the
- * engine's pin: its `classes` tuple is the panel order, `bl_label` the title,
- * each `layout.prop(bone, "x")` an entry. Blender's UI layer is never run,
- * ported or recorded.
- *
- * TWO DATABLOCKS, AND THAT IS THE WHOLE STRUCTURE OF THIS TAB. Blender's panels
- * read `bone` (the armature's `Bone`, or the `EditBone` in Edit mode) for the
- * rest pose — head, tail, roll, envelope, collections, display — and `pchan`
- * (the `PoseBone`) for the POSE: its location/rotation/scale and its inverse
- * kinematics. `buttons_context_path_bone` and `_pose_bone` build both, and the
- * door hands this tab both as "Bone" and "Pose Bone", so each panel names the
- * one Blender's draw function reads. That is why Transform below is split in
- * two the way `BONE_PT_transform` (:39) is: its first half is `pchan`, its
- * second `bone`.
- *
- * It stands when: `buttons_context_path_bone` — an armature with an ACTIVE bone
- * (the edit bone in Edit mode).
- */
+/** Blender’s Bone Properties tab follows scripts/startup/bl_ui/properties_data_bone.py at the engine pin. Curated panels read the RNA context’s datablocks; the generic view remains under All properties. Match tab availability and engine-specific panels against the live context. */
 import { blenderPropertiesTabMatch, blenderPropertiesTabSection } from './blender-properties-tab';
 import type { BlenderCuratedPanel } from './blender-properties-view';
 
@@ -44,14 +22,7 @@ const CURATED: readonly BlenderCuratedPanel[] = [
     ],
   },
   {
-    // BONE_PT_transform, :39, rest half (:104-110) — the bone's own geometry.
-    // NO MATRICES. The first cut named `matrix` and `matrix_local` beside them
-    // and the live read showed why Blender does not: a 3x3 and a 4x4 draw as
-    // twenty-five numbered rows, which buries the five values the panel is
-    // about. They are still in "All properties" beneath, where a matrix is
-    // something you go looking for. (`roll` is an EditBone property, so it
-    // draws in Edit mode and not in Object mode — the datablock's answer, not
-    // a condition of ours.)
+    // BONE_PT_transform rest geometry excludes matrices; those remain under All properties. roll exists only on EditBone and draws only when that datablock exposes it.
     title: 'Transform',
     from: 'Bone',
     properties: ['head', 'tail', 'roll', 'length', 'lock'],

package/contributions/properties-collection.inspector.tsx

@@ -1,37 +1,4 @@
-/**
- * BLENDER'S COLLECTION TAB, as a Properties section (WORK.md §Blender in the
- * tab is Blender, "Inspection parity", I2). Blender's own panels over the RNA
- * door, with the generic view beneath under "All properties".
- *
- * THE SPECIFICATION IS `scripts/startup/bl_ui/properties_collection.py` at the
- * engine's pin — `classes` (`:146-155`) is the panel order and `bl_label` the
- * title. Blender's UI layer is never run, ported or recorded.
- *
- * THE FIRST PANEL IS CALLED "VISIBILITY" AT THIS PIN, not "Restrictions":
- * `COLLECTION_PT_collection_flags.bl_label` is `"Visibility"` (`:32`). Its
- * child View Layer (`:47`) does not read the collection at all — it reads
- * `view_layer.active_layer_collection` (`:56`), a different datablock, which
- * the context door now names beside the collection as this tab's second path.
- *
- * TWO CHECKBOXES BLENDER DRAWS INVERTED. `hide_select` is labelled
- * "Selectable" with `invert_checkbox=True` (`:41`) and `exclude` is labelled
- * "Include" the same way (`:60`). What stands here is the RNA's own value
- * under the RNA's own name, because inverting a value in the presentation is
- * exactly the fabrication the anti-shim rule forbids — the same reading the
- * Object tab's Visibility panel already made.
- *
- * WHAT THE TRANSCRIPTION DELIBERATELY DROPS: `COLLECTION_PT_importer`
- * (`:65`), whose poll is a PREFERENCE (`prefs.experimental.use_collection_
- * importer`) and whose body is `template_collection_importer()` — an operator
- * template. Exporters (`:80`) is the same widget over `collection.exporters`,
- * and the collection itself is real RNA (`rna_collection.cc:954`), so its row
- * stands. `COLLECTION_PT_collection_custom_props` (`:143`) is IDProperties
- * rather than RNA.
- *
- * It stands when: `buttons_context_path_collection` — the view layer's ACTIVE
- * collection, and never the scene's master collection, which only the engine
- * knows.
- */
+/** Blender’s Collection Properties tab follows scripts/startup/bl_ui/properties_collection.py at the engine pin. Curated panels read the RNA context’s datablocks; the generic view remains under All properties. Match tab availability and engine-specific panels against the live context. */
 import { blenderPropertiesTabMatch, blenderPropertiesTabSection } from './blender-properties-tab';
 import type { BlenderCuratedPanel } from './blender-properties-view';
 

package/contributions/properties-constraints.inspector.tsx

@@ -1,24 +1,4 @@
-/**
- * BLENDER'S OBJECT CONSTRAINTS TAB, as a Properties section (WORK.md §Blender
- * in the tab is Blender, "Inspection parity", I2): the STACK, each constraint
- * its own panel with its own settings, the generic view beneath under "All
- * properties".
- *
- * THE SPECIFICATION IS `scripts/startup/bl_ui/properties_constraint.py`, and
- * it has the same shape `properties_data_modifier.py` does: `draw` is
- * `layout.template_constraints()` and the per-type panels are built in C from
- * each constraint's RNA. So the stack is derived the same way — the shared
- * `Constraint` header properties named, then everything THIS constraint's own
- * struct declares (`andDeclared`, which reads `BlenderRnaRow.group`). A Copy
- * Location constraint gets `CopyLocationConstraint`'s target, subtarget, use_x
- * / use_y / use_z, invert flags and offset, in RNA's order.
- *
- * The ACTIVE constraint (`buttons_context_path_constraint`, reported as
- * `activeConstraint`) is marked.
- *
- * It stands when: `buttons_context_path_object` — Constraints shares Object's
- * path, so the engine grants it whenever it grants Object.
- */
+/** Blender’s Object Constraints Properties tab follows scripts/startup/bl_ui/properties_constraint.py at the engine pin. Curated panels read the RNA context’s datablocks; the generic view remains under All properties. Match tab availability and engine-specific panels against the live context. */
 import { blenderPropertiesTabMatch, blenderPropertiesTabSection } from './blender-properties-tab';
 import type { BlenderCuratedPanel } from './blender-properties-view';
 

package/contributions/properties-data.inspector.tsx

@@ -1,36 +1,4 @@
-/**
- * BLENDER'S OBJECT DATA TAB, as a Properties section (WORK.md §Blender in the
- * tab is Blender, "Inspection parity", I2). Blender's own panels over the RNA
- * door, with the generic view of the whole datablock beneath under "All
- * properties".
- *
- * THE SPECIFICATION IS `scripts/startup/bl_ui/properties_data_mesh.py`, read
- * at the engine's pin: its `classes` tuple is the panel ORDER, each class's
- * `bl_label` the title, each `layout.prop(me, "x")` an entry in the order the
- * draw function lists it, `bl_options = {'DEFAULT_CLOSED'}` a `closed`, and a
- * `template_list` a `collection` panel. Blender's UI layer is never run,
- * ported or recorded.
- *
- * ONE TAB, MANY DATA TYPES, ONE LIST. `buttons_context_path_data` builds this
- * tab for whatever the object's data IS, so the same section draws a Mesh, an
- * Armature, a Camera or a Light — and the panels for all of them live in one
- * list here, because a panel draws only where its properties exist. A Camera's
- * data carries no `remesh_mode`, so the Remesh panel finds nothing and renders
- * nothing; an Armature's carries no `uv_layers` and every mesh panel stands
- * down for it. That is the same answer `MeshButtonsPanel.poll` /
- * `ArmatureButtonsPanel.poll` give, from the datablock rather than from a copy
- * of their conditions — which is why there is no per-type branch in this file
- * and no second module per data type.
- *
- * NO "NORMALS" PANEL: the brief expected one and 5.2 does not have it. The
- * mesh's `DATA_PT_normals` was folded away before this pin — `has_custom_normals`
- * survives as the Geometry Data panel's operator condition (`:456`), and the
- * shading-per-face data now lives on the Attributes list. Stated rather than
- * invented.
- *
- * It stands when: `buttons_context_path_data` — the object HAS data (an Empty
- * usually has none).
- */
+/** Blender’s Object Data Properties tab follows scripts/startup/bl_ui/properties_data_mesh.py at the engine pin. Curated panels read the RNA context’s datablocks; the generic view remains under All properties. Match tab availability and engine-specific panels against the live context. */
 import type { ToolContributionNode } from '@volter/sdk/contributions';
 import { blenderPropertiesState, resolveBlenderSubject } from './blender-properties-model';
 import { blenderPropertiesTabMatch, blenderPropertiesTabSection } from './blender-properties-tab';
@@ -93,12 +61,7 @@ const CURATED: readonly BlenderCuratedPanel[] = [
     ],
   },
   {
-    // DATA_PT_customdata, :435, titled "Geometry Data". Its body is FIVE
-    // OPERATORS and one condition (`has_custom_normals`, :456) — no
-    // properties at all. Inspection parity is not editing parity
-    // (ARCHITECTURE-CORE §Blender north star), so what stands here is the
-    // condition the operators branch on, which is the only thing in the panel
-    // a reader can learn something from.
+    // Geometry Data exposes the condition and selection counts; its editing operators are not drawn here.
     title: 'Geometry Data',
     closed: true,
     properties: ['has_custom_normals', 'total_vert_sel', 'total_edge_sel', 'total_face_sel'],

package/contributions/properties-material.inspector.tsx

@@ -1,34 +1,4 @@
-/**
- * BLENDER'S MATERIAL TAB, as a Properties section (WORK.md §Blender in the tab
- * is Blender, "Inspection parity", I2). Blender's own panels over the RNA
- * door, with the generic view beneath under "All properties".
- *
- * THE SPECIFICATION IS `scripts/startup/bl_ui/properties_material.py` at the
- * engine's pin — its `classes` tuple is the panel order, `bl_label` the
- * title, each `layout.prop(mat, "x")` an entry. Blender's UI layer is never
- * run, ported or recorded.
- *
- * THE SLOTS LIST IS FIRST, and it is `MATERIAL_UL_matslots` over
- * `ob.material_slots` (`:76`, `EEVEE_MATERIAL_PT_context_material`, whose
- * `bl_label` is empty because in Blender it is the tab's header block rather
- * than a panel). The context door hands it to this tab as its own path, with
- * the ACTIVE slot named separately (`buttons_context_path_material`:
- * `BKE_object_material_get(ob, ob->actcol)`), so the list marks it.
- *
- * SURFACE IS A NODE TREE, AND THIS IS NOT THE NODE VIEW. Blender's Surface
- * panel (`:164`) calls `panel_node_draw`, which walks the material output
- * node's `Surface` input back to the shader that feeds it and draws THAT
- * node's inputs by name. Showing those values as a flat list needs the node
- * tree walked, which is I5's read-only node view (§Inspection parity, I5) —
- * and a half version of it here would be a second, worse implementation of
- * the same walk. What stands in this panel instead is what the MATERIAL
- * itself holds: `use_nodes` and the `node_tree` pointer, which drills into
- * the generic view, plus the settings Blender's own EEVEE panels read off the
- * material datablock directly.
- *
- * It stands when: `buttons_context_path_material` — the object's data holds a
- * `materials` collection (the tab stands even when the active slot is empty).
- */
+/** Blender’s Material Properties tab follows scripts/startup/bl_ui/properties_material.py at the engine pin. Curated panels read the RNA context’s datablocks; the generic view remains under All properties. Match tab availability and engine-specific panels against the live context. */
 import { blenderPropertiesTabMatch, blenderPropertiesTabSection } from './blender-properties-tab';
 import type { BlenderCuratedPanel } from './blender-properties-view';
 
@@ -44,8 +14,7 @@ const CURATED: readonly BlenderCuratedPanel[] = [
     properties: ['name', 'material', 'link', 'slot_index'],
   },
   {
-    // EEVEE_MATERIAL_PT_surface, :164 — see the header for why this is the
-    // material's own two node properties rather than the shader's inputs.
+    // EEVEE_MATERIAL_PT_surface, :164. Read the material’s node properties; shader inputs belong to its node tree.
     title: 'Surface',
     from: 'Material',
     properties: ['use_nodes', 'node_tree', 'surface_render_method', 'use_backface_culling'],