workinf_Blender_Wasm/docs/BLENDER_WEB_EXECUTION_CONTROL_PLANE.md

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/<task>/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:

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

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:

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.