# 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.