3.6 KiB
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/M15-03A/next-task-plan.json |
Legacy regression cases; not a promise of implementation |
| 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 capability workflow, not an individual Blender operator or RNA field. A capability task owns one user-visible mutation and reuses shared command, context, resource, Main transaction, history, and case-runner primitives. Its data-driven cases may cover related legacy gaps in the same family.
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.
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.
- 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 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-P0-002 is the current production task. 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.