# Blender Web Task System

The WBV2 capability workflow is intentionally driven by small, source-backed
module cards. The current task is the row in `docs/EXECUTION_QUEUE.md`; its
parent manifest must be `done` and point to that task. The task card, not a
historical plan or static snapshot, defines the commands and exit criteria.

## Lifecycle

1. Run `node tools/web/print-task-context.mjs` and
   `node tools/web/check-task-context.mjs`.
2. Read only the listed task card, parent manifest/status and minimal inputs.
3. Execute the card's native Blender/WASM implementation and Chromium gates.
4. Write receipt, manifest, status and task-context with source/protocol hashes.
5. Run governance, handoff, typecheck, lint and diff checks.
6. Commit and push only the exact handoff after remote HEAD verification.
7. Continue from the new manifest's `nextTask`.

The loop is owned by `tools/web/run-wbv2-scheduler.mjs`, which delegates one
atomic task to guardian/supervisor. `my-tools` only launches and observes it.

## Evidence Rules

All behavior must execute through Blender 5.2 WebEngine/WASM and Chromium.
JavaScript-only simulation, fake data, generic continuation markers and
unbound inventory rows do not count as coverage. Failed or uncertain work
stays `in_progress`/`blocked`; the queue is never hand-edited to claim progress.

## Commands

```sh
python3 my-tools/check_continuation_state.py
python3 my-tools/validate_web_context.py
my-tools/start_unattended.sh
python3 my-tools/show_blender_web_scheduler.py --json
```