Reorganize Blender Web execution around capabilities

docs/BLENDER_WEB_EXECUTION_CONTROL_PLANE.md

@@ -0,0 +1,72 @@
+# 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
+
+```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.
+- 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.