@volter/editor-blender 0.1.149 → 0.1.151

package/contributions/properties-render.inspector.tsx

@@ -1,48 +1,4 @@
-/**
- * BLENDER'S RENDER 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_render.py` at the
- * engine's pin — `classes` (`:1186-1236`) is the panel order, `bl_label` the
- * title, each `layout.prop(…)` an entry, `bl_parent_id` a `sub`. Blender's UI
- * layer is never run, ported or recorded.
- *
- * THIS TAB IS WHERE THE ENGINE POLLS BECOME REAL, and it is the ONE `poll`
- * this transcription reads. Every other condition is dropped because RNA
- * already answers it — a property a datablock does not carry does not draw.
- * `COMPAT_ENGINES` is different in kind: `scene.eevee` and `scene.display`
- * exist under every engine, so nothing about the datablock says whether
- * Blender would draw the panel. Each panel below carries Blender's own LIST
- * (`COMPAT_ENGINES`, once per class) and it is checked against the ENGINE's
- * live answer — `rna_context`'s `engine`, which is `scene.render.engine`,
- * which is what `context.engine` is. The three ids a script can name here are
- * CYCLES, BLENDER_EEVEE and BLENDER_WORKBENCH (`session.py::_register_engine`);
- * the factory engine is BLENDER_EEVEE (`wasm/BUNDLE.json`), so the EEVEE
- * panels are what a fresh file draws. Cycles' own panels are the add-on's, not
- * `bl_ui`'s, and are therefore not in this file's specification.
- *
- * SEVERAL PANELS DRAW TWO DATABLOCKS IN ONE LIST — `RENDER_PT_eevee_film`
- * (`:757`) takes `filter_size` and `film_transparent` off `scene.render` and
- * `use_overscan`/`overscan_size` off `scene.eevee`, in that order. The
- * qualified property form keeps the row in Blender's position while naming
- * the datablock it comes from (`BlenderCuratedProperty`); the context door
- * names every one of them as this tab's own paths.
- *
- * WHAT THE TRANSCRIPTION DELIBERATELY DROPS:
- *  - every operator and preset menu: `RENDER_PT_format_presets`,
- *    `RENDER_PT_eevee_raytracing_presets` (`:380`), the light-probe bake
- *    buttons. Inspection parity, not editing parity.
- *  - `template_curve_mapping` (the motion-blur shutter curve `:283`, the
- *    colour-management curves `:185`) and `template_colormanaged_view_settings`
- *    — curve widgets, which this view does not draw; the datablock is one
- *    drill away in the generic view beneath.
- *  - `RENDER_PT_hydra_debug` (`:1165`): its engine is HYDRA_STORM, which this
- *    build does not register, and its poll also wants a developer-UI
- *    preference.
- *
- * It stands when: `buttons_context_path_scene` — a scene always resolves.
- */
+/** Blender’s Render Properties tab follows scripts/startup/bl_ui/properties_render.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-scene.inspector.tsx

@@ -1,38 +1,4 @@
-/**
- * BLENDER'S SCENE 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_scene.py` at the
- * engine's pin — its `classes` tuple (`:471-488`) is the panel order,
- * `bl_label` the title, each `layout.prop(scene, "x")` an entry in the order
- * the draw function lists it, `bl_options = {'DEFAULT_CLOSED'}` a `closed`
- * and `bl_parent_id` a `sub`. Blender's UI layer is never run, ported or
- * recorded.
- *
- * SEVERAL OF THESE PANELS DRAW A SUB-STRUCT RATHER THAN THE SCENE: Units is
- * `scene.unit_settings`, Rigid Body World is `scene.rigidbody_world`, Light
- * Probes is `scene.eevee`. The context door names each of those beside the
- * scene as one of this tab's own datablocks (`session.py::rna_context`), the
- * way it already named the Output tab's `image_settings`, and each panel says
- * which it reads with `from`. An absent one — a file with no rigid body world
- * — is an absent path, and the panel does not draw: the same answer
- * `RigidBodySubPanel.poll` gives (`:361-367`), from the door rather than from
- * a copy of its condition.
- *
- * WHAT THE TRANSCRIPTION DELIBERATELY DROPS:
- *  - `SCENE_PT_context_scene` (`:37`, `bl_label = ""`) — the scene ID
- *    template, which is the host's identity row here.
- *  - the operator rows: `rigidbody.world_add`/`_remove` (`:357-359`), the
- *    keying-set list's add/remove, `object.lightprobe_cache_bake` (`:447`).
- *    Inspection parity, not editing parity (ARCHITECTURE-CORE §Blender north
- *    star) — an operator is not a property and this view draws properties.
- *  - `SCENE_PT_custom_props` (`:467`). Custom properties are IDProperties;
- *    they are not in `bl_rna.properties` and the door answers RNA. Same
- *    reading as the Object tab's.
- *
- * It stands when: `buttons_context_path_scene` — a scene always resolves.
- */
+
 import { blenderPropertiesTabMatch, blenderPropertiesTabSection } from './blender-properties-tab';
 import type { BlenderCuratedPanel } from './blender-properties-view';
 import { resolveBlenderSubject } from './blender-properties-model';

package/contributions/properties-texture.inspector.tsx

@@ -1,52 +1,4 @@
-/**
- * BLENDER'S TEXTURE 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_texture.py` at the
- * engine's pin — `classes` (`:958-986`) is the panel order and `bl_label` the
- * title — AND `space_buttons/buttons_texture.cc`, which is the only thing
- * that can say WHICH texture this tab is about. Blender's UI layer is never
- * run, ported or recorded.
- *
- * THIS TAB HAS NO DATABLOCK OF ITS OWN; IT HAS A USER.
- * `buttons_texture_users_from_context` (`buttons_texture.cc:244-366`) walks
- * the context for every struct holding a texture pointer, in this order: the
- * scene's compositing node tree ("Compositor"), the active line style's slots
- * and node tree ("Line Style"), the object's modifiers ("Modifiers"), the
- * ACTIVE particle system's `part.mtex[]` ("Particles"), the object's force
- * field when its type is TEXTURE ("Fields"), and the active paint brush's own
- * two slots ("Brush"). `buttons_texture_context_compute` (`:369`) then takes
- * user `ct->index` — 0 unless a person picks another from the menu — and the
- * texture it points at is `context.texture`. The door mirrors that walk in
- * the C's own order and names the resolved texture as this tab's first path,
- * the holder as its second, and `bpy.data.textures` as its third; the whole
- * user list is on the context as `textureUsers` for anything that wants it.
- *
- * A LIGHT IS NOT A TEXTURE USER AT THIS PIN, and it is worth saying because
- * older Blenders make it a reasonable guess: the C never looks at `ob->data`.
- * Lamp textures went with 2.8's renderer rewrite. Measured, not remembered.
- *
- * THE TYPE PANELS ARE THE `when` MECHANISM'S OTHER HOME. `TextureTypePanel`
- * (`:167`) is `tex.type == cls.tex_type and not tex.use_nodes`, once per type
- * — every one of those properties lives on the same `Texture` struct under
- * every type, so RNA cannot answer it and the condition is read from the
- * engine's live value.
- *
- * WHAT THE TRANSCRIPTION DELIBERATELY DROPS:
- *  - `TEXTURE_PT_preview` (`:68`) and `TEXTURE_PT_context` (`:99`) — a
- *    `template_preview` render and the user-picker/ID templates. The picker
- *    is an editing widget; what it selects is the context door's answer here.
- *  - `TEXTURE_PT_node` (`:143`), `template_node_view` over the active texture
- *    node — the read-only node view is I5.
- *  - `template_image` (`:404`) and `template_color_ramp` (`:910`) — an image
- *    browser and a ramp widget; the `image` pointer and the `color_ramp`
- *    pointer stand and drill.
- *  - `TEXTURE_PT_custom_props` (`:953`), IDProperties rather than RNA.
- *
- * It stands when: the door's mirror of `buttons_texture_context_compute`
- * finds a user, or the file holds textures at all.
- */
+/** Blender’s Texture Properties tab follows scripts/startup/bl_ui/properties_texture.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-view-layer.inspector.tsx

@@ -1,32 +1,4 @@
-/**
- * BLENDER'S VIEW LAYER 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_view_layer.py` at the
- * engine's pin — `classes` (`:345-360`) is the panel order, `bl_label` the
- * title, each `layout.prop(view_layer, "x")` an entry. Blender's UI layer is
- * never run, ported or recorded.
- *
- * THE PASSES PANEL IS TWO PANELS UNDER TWO ENGINES, and that is why this tab
- * reads `COMPAT_ENGINES`. `VIEWLAYER_PT_eevee_layer_passes_data` (`:111`) and
- * `VIEWLAYER_PT_workbench_layer_passes_data` (`:137`) carry the SAME
- * `bl_label` ("Data") and differ only by engine — Workbench shows three
- * passes where EEVEE shows seven, off the same `ViewLayer` datablock. Nothing
- * about the datablock could say which; `rna_context`'s `engine` does. The
- * Light panel (`:156`) is EEVEE-only for the same reason, and it also reads
- * `view_layer.eevee`, which the context door names beside the layer.
- *
- * WHAT THE TRANSCRIPTION DELIBERATELY DROPS: `VIEWLAYER_PT_context_layer`
- * (`:51`, `bl_label = ""`) — the layer search template, the host's identity
- * row here; `VIEWLAYER_PT_layer_custom_props` (`:340`), IDProperties rather
- * than RNA; and the AOV / light-group add-remove operators, which are
- * editing rather than inspection. The two lists themselves are here as their
- * collections.
- *
- * It stands when: `buttons_context_path_view_layer` — the window's view layer
- * always resolves.
- */
+/** Blender’s View Layer Properties tab follows scripts/startup/bl_ui/properties_view_layer.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-world.inspector.tsx

@@ -1,48 +1,11 @@
-/**
- * BLENDER'S WORLD 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_world.py` at the
- * engine's pin — `classes` (`:266-278`) is the panel order, `bl_label` the
- * title, each `layout.prop(world, "x")` an entry. Blender's UI layer is never
- * run, ported or recorded.
- *
- * SURFACE AND VOLUME ARE A NODE TREE, AND THIS IS NOT THE NODE VIEW.
- * `EEVEE_WORLD_PT_surface` (`:109`) asks the world's node tree for its EEVEE
- * output node and draws that node's `Surface` input with
- * `template_node_view`; Volume (`:140`) is the same call on the `Volume`
- * input. Reading those values as a flat list means walking the tree back
- * through its links, which is I5's read-only node view (§Inspection parity,
- * I5) — half of it here would be a second, worse implementation of the same
- * walk. Exactly the reading the Material tab already made for its own Surface
- * panel. What stands in these two panels is what the WORLD datablock itself
- * holds: `use_nodes` and the `node_tree` pointer, which drills into the
- * generic view, plus the volume flag Blender's own panel reads off the world
- * (`use_eevee_finite_volume`, `:159`).
- *
- * THE TAB'S TONE IS THE SHADING RED. `UI_icons.hh:193` declares WORLD under
- * `DEF_ICON_SHADING`, the same group as Material — corrected from a guess
- * during I2's first landing, and the reason the scene group is four tabs
- * rather than six.
- *
- * WHAT THE TRANSCRIPTION DELIBERATELY DROPS: `WORLD_PT_context_world`
- * (`:24`, `bl_label = ""`) — the world ID template, the host's identity row
- * here; the `world.convert_volume_to_mesh` operator (`:165`); and
- * `WORLD_PT_custom_props` (`:99`), IDProperties rather than RNA.
- *
- * It stands when: `buttons_context_path_world` returns true from the scene
- * alone, so the tab stands even when the scene holds no world — and then
- * every panel here finds no datablock and none of them draw.
- */
+/** Blender’s World Properties tab follows scripts/startup/bl_ui/properties_world.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';
 
 /** `properties_world.py`, panel by panel. Line numbers are that file's. */
 const CURATED: readonly BlenderCuratedPanel[] = [
   {
-    // EEVEE_WORLD_PT_surface, :109 — see the header for why this is the
-    // world's own node properties rather than the shader's inputs.
+    // EEVEE_WORLD_PT_surface, :109. Read the world’s node properties; shader inputs belong to its node tree.
     title: 'Surface',
     engine: ['BLENDER_EEVEE'],
     properties: ['use_nodes', 'node_tree'],

package/contributions/shading.layout.ts

@@ -1,56 +1,4 @@
-/**
- * The SHADING workspace — Blender's own: the 3D viewport over the Shader
- * Editor, with the Outliner above the Properties editor on the right.
- *
- * THE PROPORTIONS ARE BLENDER'S, MEASURED THROUGH bpy on the engine in the
- * tab (2026-09-19), not eyeballed from a screenshot:
- * `bpy.data.workspaces['Shading'].screens[0].areas` answers, in a 1920-wide
- * window, PROPERTIES `x1579 y23 w339 h839`, OUTLINER `x1579 y865 w339 h189`,
- * VIEW_3D `x294 y540 w1282 h514`, NODE_EDITOR `x294 y23 w1282 h514`,
- * FILE_BROWSER `x2 y540 w289 h514` and IMAGE_EDITOR `x2 y23 w289 h514`.
- *
- * AND THE ARRANGEMENT IS A LIVE CAPTURE, not a hand-derived one
- * (`workspace-preset-layouts.ts`: "Shipped defaults are authored by arranging
- * live and snapshotting `toJSON`" — never hand-written JSON). Hand-deriving it
- * from Model's cost exactly what that rule exists to prevent: sizes authored
- * against Model's 928-px grid were applied to an 824-px container, the dock
- * measured `grid 1920×802 in a 1920×824 container` and warned that it was
- * "forcing one relayout" (measured live, 2026-09-19 — and measured again on
- * three Model/Sculpt switches with no Shading in them, which raised nothing,
- * so the warning was this arrangement's own). What ships is the settled grid,
- * with two sizes set back to the measurement: the vertical split to an exact
- * 50/50 of the grid's own height, and the right column to Model's 306/173/755,
- * which is the same column and already carries Blender's 0.177/0.184.
- *
- * Two readings out of that, and both are in `shading-arrangement.json`:
- * the right column is 339/1920 = 0.177 of the window with the Outliner taking
- * 189/1028 = 0.184 of it — the SAME column the Modeling workspace has, which
- * is why this arrangement is Model's with one change; and the centre column is
- * split EXACTLY 50/50, 514 over 514 of the 1031 px between the top bar and the
- * status bar. On the captured 928-px grid that is 464/464, which is the size
- * `volter:bottom-center` was already carrying at `"visible": false`.
- *
- * WHICH AREA THE SHADER EDITOR IS, AND WHAT IT IS MADE OF. Blender's node
- * editor is the area BELOW the viewport — and an AREA IS AN EDITOR GROUP
- * (orchestrator ruling 2026-09-19), not the bottom utility drawer. So Shading
- * declares it as an `areas` entry holding the `blender-node-editor.document`
- * contribution, the dock puts it in `volter:area:shader` below the centre at
- * Blender's own 50/50, and the frame's layout host puts the same document in
- * a second VS Code editor group. The drawer is `hidden` here, as it is in
- * Model: Blender's Shading screen has no utility strip.
- *
- * WHAT IS NOT REPRODUCED, named rather than silently dropped: Blender's
- * Shading workspace also carries a File Browser over an Image Editor in a
- * 289-px LEFT column (15.0 % of the window). Neither editor exists here yet —
- * the image/texture view is I5's Texture Paint unit and the asset browser is
- * a different surface — and §Editor chrome's rule is that a reserved panel
- * ships WITH its capability, never as empty chrome. The column arrives with
- * the editors that fill it.
- *
- * THE STRIP GROWS ONLY AS A VIEW LANDS (§Editor chrome; WORK.md I5). Shading
- * appears in the workspace strip because this contribution exists, and this
- * contribution exists because the node view does.
- */
+/** The Shading workspace places the Shader Editor below the 3D view in equal halves, with Outliner over Properties at right. The arrangement is a captured dock layout. File Browser and Image Editor areas are omitted until their editors exist. */
 
 import type { WorkspaceLayoutContribution } from '@volter/sdk/looks';
 import { BLENDER_REGIONS } from '../src/regions';
@@ -71,32 +19,9 @@ export const layout: WorkspaceLayoutContribution = {
     header: 'shown',
     shelf: 'shown',
     inspector: 'properties',
-    // THE SAME AS MODEL: no drawer. Blender's Shading screen has no fourth
-    // area beyond the viewport, the node editor and the right column, and the
-    // node editor is not a drawer utility — it is an AREA, which is an EDITOR
-    // GROUP (the ruling below). Leaving the drawer `shown` would paint an
-    // empty utility strip Blender's own screen does not have.
+    // Hide the utility drawer; the Shader Editor is a document area.
     drawer: 'hidden',
   },
-  // THE NODE EDITOR IS AN EDITOR GROUP BELOW THE MODEL DOCUMENT.
-  //
-  // RULED 2026-09-19 (orchestrator): "A Blender editor AREA is an editor
-  // group; the drawer holds utilities." Blender's Shading screen splits the
-  // centre TOP AND BOTTOM — VIEW_3D `x294 y540 w1282 h514` over NODE_EDITOR
-  // `x294 y23 w1282 h514`, measured through bpy on the engine — and both the
-  // dock and the Code-OSS frame have exactly that shape in editor groups. So
-  // the Shader Editor is a `workspace.document` this workspace opens into
-  // `volter:area:shader`, not a `workspace.utility` in the drawer.
-  //
-  // AND THAT IS WHAT RETIRED THE DRAWER RACE BY CONSTRUCTION. Switching to UV
-  // Editing kept opening the Shader Editor — and the cause was NOT the dock
-  // ordering the previous landing named: `uv-editing-arrangement.json`'s
-  // mechanical substitution had missed two of the seven occurrences (the
-  // panel record's `params.utilityId` and its `title`), so the leaf carrying
-  // the UV panel's id rendered the NODE editor and called itself "Shader
-  // Editor". A view that is not in the drawer cannot have that defect at all.
-  //
-  // THE RATIO IS BLENDER'S OWN: 514 of the 1028 px the centre column spans,
-  // an exact 0.5 to within the 1-px splitter.
+  // Open the Shader Editor in the bottom editor group at half the centre-column height.
   areas: [{ id: 'shader', document: 'blender-node-editor.document', place: 'below', ratio: 0.5 }],
 };

package/contributions/uv-editing.layout.ts

@@ -1,49 +1,4 @@
-/**
- * The UV EDITING workspace — Blender's own: the UV editor BESIDE the 3D
- * viewport, with the Outliner over the Properties editor on the right.
- *
- * THE PROPORTIONS ARE BLENDER'S, MEASURED THROUGH bpy on the engine in the tab
- * (2026-09-19), not eyeballed from a screenshot:
- * `bpy.data.workspaces['UV Editing'].screens[0].areas` answers, in a 1920-wide
- * window, PROPERTIES `x1579 y23 w339 h839`, OUTLINER `x1579 y865 w339 h189`,
- * IMAGE_EDITOR `x2 y23 w786 h1031` with `SpaceImage.mode == 'UV'`, and VIEW_3D
- * `x791 y23 w785 h1031`.
- *
- * Three readings out of that:
- *  - the right column is the SAME column Modeling and Shading have — 339/1920
- *    = 0.177 of the window, the Outliner taking 189/1028 = 0.184 of it — which
- *    is why this arrangement is Model's with one change;
- *  - the centre is split SIDE BY SIDE, not top-and-bottom: 786 and 785 of the
- *    1571 px left of the right column, an exact 50/50 to within the 1-px
- *    splitter. This is the FIRST I5 workspace whose editor is not Blender's
- *    bottom area — Shading's node editor is (`workspace-regions.ts` says so
- *    where it explains why Model hides the bottom strip), and the UV editor is
- *    a left half of the centre;
- *  - the UV editor opens in UV mode, which is what makes its title "UV Editor"
- *    rather than "Image Editor".
- *
- * WHICH REGION THE UV EDITOR IS — and the deviation this file used to record
- * is GONE, because the ruling removed its cause. It said: this host has ONE
- * utility region, the bottom area, so a utility could not claim a leaf beside
- * the centre and the UV editor took the bottom at the height Blender gives
- * its width. **RULED 2026-09-19 (orchestrator): a Blender editor AREA is an
- * editor group; the drawer holds utilities.** The UV editor is not a utility
- * at all now — it is a `workspace.document` this workspace opens into
- * `volter:area:uv`, LEFT of the model document at Blender's own 786/1571, and
- * under the frame the layout host puts the same document in a second VS Code
- * editor group. Nothing is deviating and nothing is owed to U10 here.
- *
- * WHAT IS NOT REPRODUCED, also named: Blender's UV editor shows the IMAGE
- * behind the tile. Measured on both probe files — `arena-weapons.blend` has
- * four materials, all `use_nodes`, and NOT ONE image texture node; the whole
- * file has zero images, as does `arena-vanguard.blend` — so there is nothing
- * for a backdrop to show and the view says so in its own warning rather than
- * implying an empty tile is a drawn one.
- *
- * THE STRIP GROWS ONLY AS A VIEW LANDS (§Editor chrome; WORK.md I5). UV
- * Editing appears in the workspace strip because this contribution exists, and
- * this contribution exists because the UV view does.
- */
+/** UV Editing places the UV Editor left of the 3D view, with Outliner over Properties at right. The UV view opens in UV mode and names a missing image backdrop in its warning. */
 
 import type { WorkspaceLayoutContribution } from '@volter/sdk/looks';
 import { BLENDER_REGIONS } from '../src/regions';
@@ -68,29 +23,7 @@ export const layout: WorkspaceLayoutContribution = {
     // is a utility strip. The UV editor is an AREA — an editor GROUP — below.
     drawer: 'hidden',
   },
-  // THE UV EDITOR IS AN EDITOR GROUP TO THE LEFT OF THE MODEL DOCUMENT.
-  //
-  // RULED 2026-09-19 (orchestrator): "A Blender editor AREA is an editor
-  // group; the drawer holds utilities." Blender's UV Editing screen splits the
-  // centre SIDE BY SIDE, with the image editor on the LEFT: IMAGE_EDITOR
-  // `x2 y23 w786 h1031` (mode `UV`) and VIEW_3D `x791 y23 w785 h1031`,
-  // measured through bpy on the engine in a 1920-wide window.
-  //
-  // THE RATIO IS 786 of the 1571 px left of the 339-px right column — 0.5003,
-  // an exact half to within the 1-px splitter. 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.
+  // Open the UV Editor in the left editor group at 786/1571 ≈ 0.5003 of the centre width.
   areas: [{ id: 'uv', document: 'blender-uv-editor.document', place: 'left', ratio: 0.5003 }],
-  // THE ARRANGEMENT IS A LIVE CAPTURE, re-taken 2026-09-19 after the areas
-  // ruling. The one it replaced was Shading's capture with the node view's
-  // utility id substituted by hand — and that substitution MISSED TWO of the
-  // seven occurrences: the panel record's `params.utilityId` and its `title`
-  // both still said `blender-node-editor.utility` / "Shader Editor", so the
-  // leaf keyed by the UV panel's id rendered the NODE editor. That is the
-  // whole of the "switching to UV Editing opens the Shader Editor" defect the
-  // previous landing recorded as a dock ordering race; it was a bad derived
-  // blob, which is exactly what `workspace-preset-layouts.ts` forbids
-  // ("shipped defaults are authored by arranging live and snapshotting
-  // `toJSON` — never hand-written JSON"). This one is captured.
+  // The arrangement is a captured dock layout for these UV editor documents.
 };

package/dist-node/serving.mjs

@@ -24,7 +24,7 @@ function projectOutputRootOf(path) {
   );
 }
 
-// ../sdk/src/session/relative-path-guard.ts
+// ../sdk/src/relative-path-guard.ts
 function relativePathRejection(path) {
   if (!path || path.trim() === "") return "empty";
   if (path.includes("\0")) return "nul";
@@ -65,8 +65,8 @@ var SHIPPED_BLENDER_WASM_DIR = (() => {
   const candidate = fileURLToPath(new URL("../../blender-engine/wasm/", import.meta.url));
   return existsSync(candidate) ? candidate.replace(/\/$/, "") : null;
 })();
-function blenderWasmDir(env = process.env) {
-  const named = env[BLENDER_WASM_DIR_VARIABLE];
+function blenderWasmDir() {
+  const named = process.env[BLENDER_WASM_DIR_VARIABLE];
   if (typeof named === "string" && named.trim() !== "") {
     const dir = named.trim();
     return isAbsolute(dir) ? dir : null;
@@ -92,8 +92,8 @@ async function skewOf(dir) {
   if (existsSync(join(dir, BLENDER_WALI_ARTIFACT))) return "wali";
   return null;
 }
-async function blenderWasmStatus(env = process.env) {
-  const dir = blenderWasmDir(env);
+async function blenderWasmStatus() {
+  const dir = blenderWasmDir();
   if (dir === null)
     return {
       available: false,
@@ -117,13 +117,13 @@ async function blenderWasmStatus(env = process.env) {
         `${dir} holds neither ${BLENDER_WASM_FILES.join(", ")} (the standalone skew) nor ${BLENDER_WALI_ARTIFACT} (the substrate skew)`
       ]
     };
-  return skew === "wali" ? waliStatus(dir) : emscriptenStatus(dir, env);
+  return skew === "wali" ? waliStatus(dir) : emscriptenStatus(dir);
 }
 var BROWSER_SUBSTRATE_VARIABLE = "BROWSER_SUBSTRATE_URL";
-function servedFromTab(env = process.env) {
-  return (env[BROWSER_SUBSTRATE_VARIABLE] ?? "").trim() !== "";
+function servedFromTab() {
+  return (process.env[BROWSER_SUBSTRATE_VARIABLE] ?? "").trim() !== "";
 }
-async function emscriptenStatus(dir, env) {
+async function emscriptenStatus(dir) {
   const sizes = {};
   const encoded = {};
   const missing = [];
@@ -136,7 +136,7 @@ async function emscriptenStatus(dir, env) {
     sizes[file] = found.size;
     if (found.encoding) encoded[file] = found.encoding;
   }
-  return { available: missing.length === 0, skew: "emscripten", dir, sizes, encoded, missing, digests: await emscriptenDigests(dir), inTab: servedFromTab(env) };
+  return { available: missing.length === 0, skew: "emscripten", dir, sizes, encoded, missing, digests: await emscriptenDigests(dir), inTab: servedFromTab() };
 }
 async function emscriptenDigests(dir) {
   const digests = {};
@@ -217,7 +217,6 @@ async function runtimeIndex(dir) {
   if (cachedRuntimeIndex?.dir === dir) return cachedRuntimeIndex.index;
   const root = join(dir, BLENDER_WALI_RUNTIME);
   const files = [];
-  let newest = 0;
   const walk = async (where) => {
     for (const entry of (await readdir(where, { withFileTypes: true })).sort(
       (left, right) => left.name < right.name ? -1 : left.name > right.name ? 1 : 0
@@ -235,12 +234,11 @@ async function runtimeIndex(dir) {
         mode: info.mode & 4095,
         sha256: createHash("sha256").update(await readFile(path)).digest("hex")
       });
-      newest = Math.max(newest, info.mtimeMs);
     }
   };
   await walk(root);
   if (files.length === 0) throw new Error(`${root} is empty`);
-  const index = { files, newestMtimeMs: newest };
+  const index = { files };
   cachedRuntimeIndex = { dir, index };
   return index;
 }
@@ -358,9 +356,7 @@ function blenderRoutesPlugin(services) {
         json(res, await blenderWasmStatus());
       }
     },
-    // The substrate skew's own doors beside the standalone bundle's: Blender's runtime tree as
-    // one index and one blob (a request per file would be ~2,300 round trips), and the
-    // substrate's browser ESM with its bare specifiers rewritten.
+    // Serve the substrate runtime tree as one index and blob, plus browser ESM with rewritten bare specifiers.
     {
       method: "GET",
       match: /^\/__editor\/blender-wasm\/runtime\.idx$/,
@@ -657,20 +653,7 @@ function blenderRoutesPlugin(services) {
         }
       }
     },
-    // ---- The session's DOCUMENT, written back OUT into the project. A Blender session holds one
-    // `.blend`; its `save_as_mainfile` writes it into the engine's filesystem, and this is how
-    // those bytes reach the disk the project lives on. Unlike the spool, the destination shape is
-    // pinned BY THIS SERVER, and the write is the project's one attributed, conflict-checked
-    // transaction: a `.blend` is the project's file like any other.
-    //
-    // IT ARRIVES AS A DELTA. The page cuts each save into content-defined chunks
-    // (`blender-engine/browser/document-chunks.mts`) and posts their manifest; this answers with
-    // the chunks it does not already hold, the page posts those, and the manifest again commits.
-    // MEASURED 2026-09-29, native Blender 5.2 on the Stoneguard bridge: a 497 MB save, one object
-    // moved, changed 1 of 475 one-MiB chunks, so an edit carries about a megabyte instead of the
-    // whole file. Chunks this server reuses come from the document as it lies on disk, and each
-    // is hashed again against the manifest before the commit: a file changed underneath (another
-    // writer, a restore) is not drift but a missing chunk, re-sent.
+    // Save the session .blend through the attributed, conflict-checked project transaction. A chunk manifest requests only missing bytes. Rehash reused disk chunks at commit so an external file change requests replacement chunks.
     {
       method: "POST",
       match: /^\/__editor\/blender-document-chunk$/,