# Blender Web execution control plane This is the operational policy for moving Blender 5.2 behavior into the browser. It keeps the existing desktop oracle, WASM/Main reader, Chromium checks, save/reopen receipts, hashes, and compact task context. It changes the unit of production work. ## One source per decision | Decision | Authoritative input | Meaning | | --- | --- | --- | | What runs next | `docs/EXECUTION_QUEUE.md` + its parent manifest | One active, serialized handoff pointer | | What is a product capability | `docs/BLENDER_WASM_CAPABILITY_MATRIX_TEMPLATE.json` | User-observable behavior and its proven parity level | | What is still covered | `tests/golden/WBV2/dynamic-inventory.json` | Source-derived units and conservative verified/unverified state | | Historical regression catalog | `tests/golden/M15-03A/next-task-plan.json` | Read-only 6900-entry estimate and regression cases | | What was already proven | `tests/golden//manifest.json` and `tests/golden/corrective/` | Immutable receipts and hashes | The old corrective handoff is historical evidence. A later queue task is valid only when its parent-manifest chain descends from that checkpoint; the checkpoint itself is never rewritten to make it appear current. ## Production unit The production unit is a module-backed capability workflow, not an individual Blender operator or RNA field. A module owns a coherent code, transaction, and rollback boundary; its capability commands are shared primitives, and its operator inventory rows are data-driven coverage cases. A single module task may therefore cover hundreds of related operators without creating hundreds of production tasks. The required relationship is: ```text module task -> capability/command -> operator case matrix ``` An operator ID is never a queue pointer. It maps to exactly one primary module and records its context, parameters, desktop oracle, expected mutation, negative boundary, persistence expectation, and result status. The historical 6,620+ figure is a catalog-scale estimate, not a promise to run 6,620 hand-authored commands; the current inventory has its own exact total/pending counts and SHA, recorded in the module manifest. Every capability task must state its parity level, positive mutation, negative boundary, save/reopen behavior, undo/redo behavior, resource budget, and Chromium receipt. A `CANCELLED`, `UNSUPPORTED`, metadata-only, snapshot-only, or external-resource result is coverage evidence, never a positive feature claim. ### Module completion gate Module work has a fast feedback loop and a mandatory batch gate: 1. Freeze the module contract and run a small representative positive/negative/reopen set. 2. Implement the shared production path and prove a real desktop/WASM Main mutation. 3. Freeze the source and run every mapped operator case through one versioned runner. Shards may run in parallel, but use the same catalog snapshot and deterministic inputs. 4. Before merge, run the full operator catalog as a sharded regression suite and compare it with the hash-bound baseline. Existing passes may not regress, and new failures/blocked cases require review; unsupported or retained-negative baselines are not treated as passes. 5. Publish one aggregate manifest containing case counts, shard exit codes, catalog/source hashes, and links to per-case evidence. Any failed, blocked, budget, or hash-drift case keeps the module in progress. Per-change checks may run only affected cases plus the representative set. A module cannot be marked complete until the full matrix has passed; the same matrix is then a scheduled regression suite. No operator-specific checker branch, queue slot, or production commit is created when the behavior uses an existing module primitive. ## Lifecycle and gates ```text scope -> capability contract -> desktop oracle -> WASM/Main mutation -> Chromium workflow -> negative/recovery -> manifest/hash -> handoff ``` The cheap control-plane check runs before Blender, WASM, or browser startup: ```bash node tools/web/check-execution-control-plane.mjs node tools/web/check-execution-health.mjs ``` The first command validates queue/index/catalog/parent consistency and reports the capability-to-legacy coverage ratio. The second validates the current task card and its concrete fixture/generator. Any blocked result stops expensive commands and keeps the task `in_progress` or `blocked`. ## Parallelism and throughput rules - Inventory, schema, fixture preparation, read-only UI work, and checkers may run in parallel when they do not share a mutable Main or generated queue file. - Main mutation, queue generation, manifest/status writes, and release-ledger writes are serialized through the parent manifest. - A capability implementation should close multiple related legacy cases. Three consecutive evidence-only tasks trigger a route review. - Module completion is measured by production changes plus aggregate operator coverage, not by the number of operator rows or generated fixtures. - Positive and negative cases are generated together. Failure, cancellation, budget, or hash drift never advances the successor. - Legacy `M16-GAP-*` records stay immutable; migration adds capability coverage references instead of rewriting their completion meaning. ## Current migration state The active production queue is the finite function-module plan at `tests/golden/WBV2-P1100-000/module-execution-plan.json`. It supersedes the generic `WBV2-P*` continuation chain without rewriting its historical manifests. The queue has completed the render, scene/mesh, material/animation, non-mesh, nodes/simulation, asset, sculpt/paint, editor, object, compositor/sequencer and inventory-gate modules; the completed chain now also includes `AUDIO_PARTICLE` (`WBV2-P1105-000`), `RIG_ANIMATION` (`WBV2-P1106-000`), `MODIFIER_SYSTEM` (`WBV2-P1107-000`), `NODES_GRAPH` (`WBV2-P1108-000`), `IO_FORMAT` (`WBV2-P1109-000`), `RENDER_PIPELINE` (`WBV2-P1110-000`), `SCRIPTING_SECURITY` (`WBV2-P1111-000`), `ANIMATION_TIMELINE` (`WBV2-P1112-000`), `SHADER_MATERIAL` (`WBV2-P1113-000`), `GREASE_PENCIL` (`WBV2-P1114-000`), `CURVE_SURFACE_EDITING` (`WBV2-P1115-000`), `STORAGE_RECOVERY` (`WBV2-P1116-000`), `SIMULATION_CACHE` (`WBV2-P1117-000`), `UI_INPUT_INTERACTION` (`WBV2-P1118-000`), `LIBRARY_WORKFLOW` (`WBV2-P1119-000`), `VOLUME_NANOVDB` (`WBV2-P1120-000`), `PAINT_STROKE` (`WBV2-P1121-000`), `ENGINE_RUNTIME` (`WBV2-P1122-000`), `GLB_ROUNDTRIP_REPAIR` (`WBV2-P1123-000`), `HISTORICAL_HASH_DRIFT` (`WBV2-P1124-000`), `GEOMETRY_NODES_ALLOWLIST_REPAIR` (`WBV2-P1125-000`), `GREASE_PENCIL_VIEWPORT` (`WBV2-P1126-000`), `TRACKING_MASK` (`WBV2-P1127-000`) and `SEQUENCER_MOVIE_CODEC` (`WBV2-P1128-000`) and `CORE_SCENE_GRAPH_SETTINGS` (`WBV2-P1129-001`) and `UI_EDITOR_VIEW2D_STATE` (`WBV2-P1130-001`) and `CURVE_TOPOLOGY_EDITOR` (`WBV2-P1131-001`). The Audio/Speaker/ParticleSettings gap was solved with a Web-safe Scene IDProperty retention path in authoritative Main; desktop Audaspace remains disabled because its Emscripten symbols are unavailable. New work is added only as a source-backed module with Chromium, negative and recovery gates. Queue authorization, batch indexing, repeated generic markers, and build-only smoke are not feature completion. The historical 6,900-entry inventory remains read-only. The current source-derived inventory is `tests/golden/WBV2/dynamic-inventory.json`; its unit count and source-tree hash are regenerated from Blender 5.2 source, while `5200` is a non-binding planning estimate. Units remain unverified until explicit behavior evidence binds them. ## Project completion audit The current migration epoch is a verified capability slice, not full Blender parity. It contains 38 completed source-backed function modules plus the bridge/root and successor-authorization tasks; the module plan is terminal at `WBV2-P1131-001`. The historical 15-family inventory has 281 legacy receipts and zero full-family parity claims; the dynamic source ledger is conservative until each unit is explicitly mapped. Pending volume is concentrated in UI (3,930), Media I/O (585), Nodes (543), Mesh Editing (431), Rig Animation (375), Object Operations (316) and Simulation (155). Follow-up waves must select one source-backed family at a time, reuse existing receipts by hash, and require the same Main/Worker/frontend, negative, recovery and Chromium gates. The next checkpoint is the first explicitly authorized corrective or uncovered-family task after `WBV2-P1130-001`; do not infer full-family parity from representative slices. The asset-operator evidence through `M16-GAP-00281` is integrated into the generated completion registry. `M16-GAP-00282` remains the single legacy coverage checkpoint, while `WBV2/dynamic-inventory.json` is the current source-statistics artifact. The corrective pilots already provide reusable asset-catalog, modifier, mesh, history, and Chromium workflow primitives. New implementation work should extend those family primitives and add representative capability cases rather than adding another checker branch for each operator.