workinf_Blender_Wasm/nextTask.md

Continuous Task Handoff

This file is the bounded continuation entrypoint for the Blender Web execution queue. It is a procedure, not a second task pointer. The only authoritative pointer is docs/EXECUTION_QUEUE.md plus the parent manifest named there.

The phrase below starts continuous mode. Continuous mode is a loop of bounded task iterations: one task is completed and handed off at a time, then the next iteration starts from a fresh compact context without waiting for another user message. The loop stops only at an explicit stop condition described below.

Source authority is explicit: blender-5.2.0 and its Blender Main data/API implementation are the primary specification. Repository protocol, Worker, client and frontend code must be reconciled with that source. Web searches and external documentation are supplemental references for toolchain/browser constraints only; they cannot override or replace behavior present in the Blender source.

Implementation iron rule: advance the 6900-entry inventory through capability families and unique behavior batches at maximum practical throughput. Do not run Chromium, E2E receipts, parity verification, save/reopen verification, determinism checks, or completion overlays in this implementation lane. The only allowed checks are source compilation, TypeScript/type safety, lint, bounded build and queue/governance integrity needed to avoid committing broken functionality. Do not drift into repeated maintenance-only waves while an unimplemented Blender capability family remains available.

一键连续执行入口

把下面的文本作为用户消息发送，即可让执行代理从当前队列自动开始，并在 每个任务成功交接后立即进入下一个任务，不等待新的用户消息：

按 nextTask.md 不间断执行。

这是执行命令，不是计划、状态汇报或等待确认。读取仓库当前队列和 parent
manifest，严格从当前 `nextTask` 开始。每次只完成一个任务，完成后写入
manifest、status、task-context，提交并推送 `origin/main`，重新读取新的
`nextTask`，立即开始下一轮，直到队列闭合或遇到真实阻塞。

主线是使用 `blender-5.2.0` 源码实现 Blender Web/WASM 全部能力：优先修改
Blender Main、WebEngine C++、WASM、协议、Worker、客户端和前端真实入口；按
capability family 和唯一行为批量推进 6900 条目，复用已有 hash 证据，禁止
重复实现或逐条重复处理。

当前阶段只做实现和必要的源码编译、WASM 构建、TypeScript、lint、前端构建
及队列治理检查；不执行 Chromium/E2E/parity/receipt/save-reopen/determinism
验证，不写 completion overlay，不修改原始 inventory 或历史 provenance。

每轮开始运行 `node tools/web/print-task-context.mjs` 和
`node tools/web/check-task-context.mjs`；只读取当前任务卡和最小输入。任何
失败、缺失、hash 漂移或队列不一致都保留 `in_progress`/`blocked`，先自行
修复；状态未知时不得重复执行写操作。成功交接后不得停止、只汇报或等待确认，
必须继续读取新 manifest 的 `nextTask`。

需要在终端保持进程级无人值守连续执行时，运行：

node tools/web/run-wbv2-guardian.mjs --max-iterations 0 --commit --push

--max-iterations 0 表示不限迭代次数；runner 只执行当前任务卡声明的 入口。每次提交后必须同时满足 git push 成功和 origin/main 的远端 HEAD 等于本地 HEAD；网络抖动或远端确认延迟会自动退避重试，最终仍无法确认时保留 精确 checkpoint。凭据必须使用已配置的 Git 凭据，不得写入命令行历史、URL、 日志或仓库文件。

进程级不间断执行

聊天消息只能启动一次代理执行；要跨越终端、网络或会话边界持续运行，必须 启动仓库内 guardian。guardian 持有唯一锁并托管 supervisor；supervisor 每次 调用现有 runner 一个任务迭代，成功交接后立即启动下一迭代，并在重新启动时从 docs/EXECUTION_QUEUE.md 恢复，不依赖上一轮聊天上下文：

node tools/web/run-wbv2-guardian.mjs --max-iterations 0 --commit --push

需要脱离终端运行时使用：

setsid -f nohup node tools/web/run-wbv2-guardian.mjs --max-iterations 0 --commit --push \
  > tests/golden/WBV2/continuous-guardian.stdout.log 2>&1 < /dev/null

guardian/supervisor 的连续契约：

• --max-iterations 0 表示不限任务轮数；每轮只执行当前 manifest 的一个 nextTask。
• 每轮先运行 print-task-context 和 check-task-context，再调用 runner；成功后立即重读队列。
• 每轮状态写入 tests/golden/WBV2/continuous-supervisor.json，详细输出写入 continuous-supervisor.log。
• guardian 状态写入 tests/golden/WBV2/continuous-guardian.json，详细输出写入 continuous-guardian.log；两个锁文件均防止重复实例。
• runner 的 push 流程最多退避重试 6 次，并在每次提交后执行 git ls-remote origin refs/heads/main 对比本地 HEAD；未确认远端提交不得进入下一任务。
• supervisor 意外退出时，guardian 仅当 checkpoint 为 handed_off 且当前队列与 checkpoint.after 完全一致时自动拉起；这是唯一可证明不会重放未知写操作的恢复路径。
• 子进程失败、队列未前进、队列在失败后已经前进、推送无法确认或上下文不一致时保存 blocked checkpoint；不得盲目重试未知的状态变更。
• guardian 或 supervisor 进程退出后，再次执行同一 guardian 命令即可从当前队列恢复；不复制旧日志、不重放未知命令。
• guardian 只负责有效 handoff 和可证明的进程恢复，不能绕过真实阻塞、治理门禁、源码编译失败或 provenance 规则。

Copyable Resume Prompt

Use the following prompt when continuous execution is needed. It is the copyable, end-to-end command for bounded implementation, verification, handoff, and (when authorized) repository push:

按 nextTask.md 接续执行。

这是实现命令，不是计划或状态咨询。进入 IMPLEMENTATION-FIRST 连续模式：先使用仓库已有源码把完整功能链路（Blender WebEngine Main、协议、WASM worker、客户端和前端）逐能力族实现并接通；详细 Chromium 生产证据、双次确定性、逐项 parity overlay 延后到实现波次完成后的验证波次。

1. 先读取 `AGENTS.md` 和 `docs/EXECUTION_QUEUE.md`，然后运行：
   `node tools/web/print-task-context.mjs`
   `node tools/web/check-task-context.mjs`
2. 当前任务必须等于 parent manifest 的 `nextTask`。只读取当前任务卡、parent manifest/status 和 task-context 列出的最小输入；禁止默认读取完整历史计划、全部 `docs/status` 或 6900 条目详情。
3. 每次只实现当前任务卡规定的一个能力族或一个独立接线切片。以 `blender-5.2.0` 源码、Blender Main 数据结构和 C/C++ API 为第一依据，再同步 WebEngine dispatch、协议类型、worker/client 路由和前端入口；网页资料只补充构建/浏览器约束，不得用模拟数据、空壳接口或网页描述替代真实实现。
4. 严禁重复工作：相同 source hash、behavior hash、dedupe key 或已存在的实现直接复用；不重复运行已有 Blender/WASM/Chromium 行为；6900 条目按 capability family 批量映射，完成条目只作未来回归引用。
5. 实现波次只要求最小安全检查（源码语法、TypeScript typecheck、lint、可用时的 Vite/build 和浏览器启动 smoke）；不为每个新能力生成完整 E2E receipt，不在实现阶段写 completion overlay，不声称历史 parity。
6. 原始 P0 inventory、6900 总数、6618 legacy pending 和历史 provenance 始终只读。effective completed/pending 只由后续 hash-bound 验证 overlay 计算；实现完成不等于条目完成。
7. 长输出写入 `tests/golden/<task>/command.log`；交互只报告退出码、短尾部、构件路径和 SHA-256。
8. 任务成功后运行 `node tools/web/check-task-context.mjs --task <task-id> --write`、`node tools/web/check-context-governance.mjs`、`node tools/web/check-v2-task-index.mjs`、`npm --prefix web run typecheck`、`npm --prefix web run lint` 和 `git diff --check`；完整生产验证门禁统一在验证波次执行。
9. 所有实现门禁通过后自动提交并推送 `origin/main`；必须再次用 `git ls-remote` 确认远端 `main` 与本地 `HEAD` 完全相同，确认完成后才从新 parent manifest 读取 `nextTask` 继续。凭据不得写入文件、URL、日志或提示词。
10. 任一命令失败、输入缺失、队列不一致、环境不可用或状态不明时，保持 `in_progress`/`blocked`，不得推进指针、伪造完成或重复未知结果的状态改变命令。
11. 每轮结束报告实现切片、当前任务、`nextTask`、最小检查退出码、原始 inventory、effective inventory 是否保持不变、提交/推送状态和剩余真实阻塞。
12. CONTINUOUS_LOOP_REQUIRED：成功交接后立即开始下一轮；不得在成功提交、推送或生成新 manifest 后等待用户确认、只写计划或只汇报状态。每轮必须重新运行 `print-task-context` 和 `check-task-context`，使用新 parent manifest 的 `nextTask`，不沿用上一轮上下文。
13. 可使用仓库内 guardian 保持进程级连续执行：`node tools/web/run-wbv2-guardian.mjs --max-iterations 0 --commit --push`。它托管 supervisor，`0` 表示不限轮数，`--max-iterations N` 用于受控运行，`--commit --push` 才允许自动提交/推送。push 网络抖动由 runner 自动退避重试并确认远端 HEAD；任何入口失败、退出 0 但队列未前进、治理失败、远端无法确认或状态不明都保留 checkpoint，guardian 只自动恢复可证明安全的 handoff。
14. 6900_IMPLEMENTATION_IRON_RULE：只按 capability family 和唯一行为批次实现全部 Blender 功能；不启动 Chromium/E2E/receipt/parity/save-reopen/determinism 验证，不写 completion overlay，不把维护 smoke 当作能力完成。若任务卡与本铁律冲突，以源码实现和本铁律为准，并将验证留到后续独立验证波次。
15. UNIFIED_WASM_JSON_ABI_IRON_RULE：Worker 与 WASM 的新调用统一使用单一 C ABI `web_engine_call_json(handle, requestJson, resultOut)`；请求必须是 `{"cmd":"...","params":{...}}`，返回必须是 `{"ok":true,"cmd":"...","result":...}` 或包含 `code/error` 的失败 JSON，再由 Worker 解析为领域结果。`applyCommand`、快照、增量、撤销/重做、Depsgraph 等状态路径不得新增独立公开 WASM 函数；open/append/save/geometry 等仍未迁移的二进制专用 ABI 仅作为兼容边界保留，并不得扩散到新的状态调用。
16. PROCESS_CONTINUITY_IRON_RULE：要实现跨会话不间断执行，必须使用 `run-wbv2-guardian.mjs --max-iterations 0` 托管 `run-wbv2-supervisor.mjs`；单次聊天执行完成后不得假定代理会在下一轮自动复活。guardian/supervisor 必须按任务原子迭代、锁队列、写 checkpoint、成功后立即重读 manifest；失败或状态未知时只能停在精确 checkpoint，不得自动重试或伪造队列前进。
17. PUSH_COMPLETION_IRON_RULE：任何任务只有在 commit 成功、`git push origin main` 成功且 `git ls-remote --refs origin refs/heads/main` 返回的远端 HEAD 与本地 `git rev-parse HEAD` 相同后才算完成；确认前不得读取下一任务。网络失败最多按退避策略重试，状态未知时不得重放任务写入。
18. GUARDIAN_CONTINUITY_IRON_RULE：无人值守运行必须由 `run-wbv2-guardian.mjs` 托管 supervisor。guardian 对可证明的 `handed_off` checkpoint 自动恢复，对 `running`、`started`、`blocked`、指针漂移、远端提交不明或任务闭合状态保持精确停止；“不停歇”仅适用于安全可恢复的进程/网络故障，不能解释为绕过真实阻塞。

Resume Command

When the user says:

按 nextTask.md 接续执行

the phrase is an execution command, not a request for a plan or status report. Resume implementation autonomously from the repository checkpoint. Do not ask for confirmation, wait for a second message, or stop at a proposal while the queue and parent manifest are valid. A wording variant that quotes the same exact phrase has the same meaning; unrelated requests for explanation, review, or diagnosis do not activate this procedure.

“连续” means:

1. Start the task named by the current docs/EXECUTION_QUEUE.md pointer.
2. Finish or safely checkpoint that one task.
3. Write its manifest/status/task-context handoff and generate the next task pointer through repository tools.
4. If the handoff is successful, immediately start the next iteration from the new pointer and a fresh compact context package. No additional user message is required.

There is no intentional idle step between valid handoffs. Each iteration still has exactly one numbered task and must not carry the previous task's full transcript, logs, or source context. A guardian run may contain many such iterations and automatically recovers process exits after a proven handoff; it stops only at a real gate failure, unknown state, queue closure, or explicit stop request.

Continuous Loop Contract

The following loop is part of the execution command. It is not an optional checklist and it does not require another user message:

while queue has an active task:
  read docs/EXECUTION_QUEUE.md
  print and validate a fresh compact task context
  assert queue.currentTask == parentManifest.nextTask
  execute exactly that task's focused implementation command
  write report/status/manifest/task-context through repository generators
  run the required governance, typecheck, lint, build and diff gates
  if any gate fails: preserve in_progress/blocked and stop
  commit and push origin/main
  re-read the new queue and parent manifest
  immediately begin the next iteration

The loop must not interpret a successful implementation task as release parity, must not fabricate a successor when nextTask is null, and must not perform a second attempt after an unknown state-changing command. A root task is itself an executable enabling task: run its declared root generator, then continue from the generated child task in the same continuous run.

Every implementation iteration must answer one question before editing: which capability family or unique behavior from the immutable 6900 inventory becomes more implemented by this change? If the answer is only "maintenance", skip it when a source-backed capability slice is available. Maintain the original inventory and provenance; implementation progress is recorded in task reports, not completion overlays.

For process-level unattended execution, run:

node tools/web/run-wbv2-guardian.mjs --max-iterations 0 --commit --push

The runner is intentionally fail-closed. It derives the command from the current task card, requires the queue to advance after a successful exit, and writes one bounded log per task. Push completion is accepted only after the remote origin/main HEAD equals the local commit. The guardian retries only a proven handed_off process exit; it never invents a task, retries an unknown state-changing result, or turns implementation output into parity completion.

Activation Contract

The phrase activates implementation only when the queue is internally consistent. Before editing, the agent must prove all of the following:

• print-task-context reports the queue's current task and its parent manifest.
• check-task-context passes without --write.
• The queue task exactly equals the parent manifest's nextTask.
• The task card, production entrypoint, and focused test entrypoint exist.

If any proof fails, preserve the queue and report the checkpoint blocker. Do not infer a task number from nextTask.md, historical status files, or a previous conversation.

Fresh-Context Boundary

The boundary is per task iteration, not per user message. At the end of a task, the machine handoff is the checkpoint; the next iteration must begin from a fresh compact context package instead of carrying the previous transcript, logs, or source files forward. This keeps remote compact/reconnect payloads bounded while allowing a continuous run to advance through multiple tasks.

The handoff is durable only after the manifest, status, task-context, artifact hashes, and governance checks agree. A task that fails, is cancelled, exceeds budget, lacks its environment, or has hash drift remains in_progress or blocked; the next invocation resumes that same task instead of advancing.

Stop Conditions And Recovery

The unattended guardian does not stop for a transient process or push transport failure. The runner retries push/remote-HEAD confirmation with bounded exponential backoff, and the guardian restarts only after a proven handoff. Continuous mode stops only when an unsafe or irreversible condition remains:

• a focused command, exit criterion, governance check, or hash check fails;
• the queue, parent manifest, task card, task index, or nextTask pointer is inconsistent;
• the environment is missing, the task is cancelled, or a context/size budget would be exceeded;
• a stream disconnect, remote compact error, or other transport error makes the result of a state-changing command unknown after read-only reconciliation;
• the queue has no next task or reaches its declared closure gate;
• the user explicitly asks to stop or pause.

On an unsafe stop, preserve the current checkpoint, do not start another task, and report the exact task, state, failed gate or stop reason, and evidence paths. Only a successful handoff starts another iteration. A process exit is not by itself a reason to stop: the guardian re-enters only from a matching handed_off checkpoint; running/started or mismatched pointers remain blocked to prevent duplicate writes.

For every task, run this exact order:

1. Read docs/EXECUTION_QUEUE.md.

2. Run node tools/web/print-task-context.mjs and read only its required files, task-card inputs, and named production/test entrypoints.

3. Run node tools/web/check-task-context.mjs before any edit. Stop if the queue task is not exactly the parent manifest's nextTask.

4. Implement and verify only that task card's one behavior/evidence slice.

5. Keep command output out of the conversation. For output that may be long, write > tests/golden/<task>/command.log 2>&1, record the exit code, and report only a short tail plus the artifact paths and SHA-256 values.

6. Only after all exit criteria pass, run:

   node tools/web/check-task-context.mjs --task <task-id> --write
   

7. Write the report, status, manifest, and task context. A failed command, missing environment, or hash drift keeps the task in_progress/blocked; never advance the queue in that state.

8. Re-run the governance checks. If they pass, continue with the next iteration from a fresh context package; do not start the next task if any gate fails.

The normal post-handoff checks are:

node tools/web/check-blender-next-task-plan.mjs
node tools/web/check-task-index.mjs
npm --prefix web run test:task-context
npm --prefix web run test:context-governance
node tools/web/check-context-governance.mjs
git diff --check

Do not manually edit nextTask, task-index offsets, catalog lines, or parent evidence. Generate them through the repository tools and update the queue only to the newly completed manifest pointer.

Transport/Compaction Recovery

stream disconnected, error decoding response body, or a remote compact failure means that the request outcome is unknown. The process-level guardian continues independently when its checkpoint is valid; a chat client must first perform read-only reconciliation. Do not blindly repeat a generator, build, save, or queue-writing command.

Recover with read-only checks first:

node tools/web/print-task-context.mjs
node tools/web/check-task-context.mjs
git status --short

Then compare the current task's manifest, status, task-context, and artifact hashes. Continue from the first missing handoff step; if every criterion is already recorded, run only the missing governance/check command. The failed request's outcome is unknown, so do not claim success from the error message. Resume the request at most once in a chat session. For unattended execution, push transport retries are handled by the runner and proven-handoff process restarts by the guardian; if reconciliation cannot prove safety, leave the task in_progress/blocked, preserve all files, and report the exact command and checkpoint state rather than starting an unsafe retry loop.

If the client supplies a session id, codex resume <session-id> may be used, but the resumed turn must still reread the queue and print a fresh context. Do not paste the old transcript or full logs into the new request. Without a session id, start a new turn with this file and the repository checkpoint. The user does not need to repeat the failed command: the next invocation of the exact resume phrase performs the read-only recovery checks first and continues from the first missing handoff step.

The recovery request must not include the old transcript or full command logs. It re-enters continuous mode only after the read-only checkpoint proves which handoff step is missing:

按 nextTask.md 接续执行。

上一请求发生 stream disconnected / remote compact failure。先只读运行
node tools/web/print-task-context.mjs、node tools/web/check-task-context.mjs
和 git status --short；比较当前 task 的 manifest、status、task-context 与
artifact SHA-256，只从第一个缺失的交接步骤继续。不要重复任何未知结果的
生成、构建、保存或队列写入命令；恢复当前 task 后进入 CONTINUOUS mode，
仅在完整 handoff 成功时自动开始下一个 iteration；再次发生同类错误时
立即停止并报告 checkpoint，不要继续重试。

Current Handoff Snapshot

Recorded: 2026-08-29 Asia/Shanghai

Field	Value
Current task when this file was written	WBV2-P514-000
Current task state	in_progress
Parent manifest	tests/golden/WBV2-P513-003/manifest.json
Current task card	docs/tasks/WBV2-P514-000.md
Current task-context nextTask	NONE
Focused command	node tools/web/generate-wbv2-capability-continuation-root.mjs

The snapshot is informational and may become stale. On every resume, the queue, parent manifest, and fresh print-task-context output win. Never infer a task number from this table or from historical status files.

Non-Negotiable Boundaries

• Chromium is the only permitted browser runtime; never run Firefox or WebKit.
• blender-5.2.0 source and Blender Main are the behavior authority; web references are supplemental and must be recorded only when they affect build/runtime constraints.
• The 6900 implementation lane is verification-free: no Chromium/E2E receipts, parity overlays, save/reopen or determinism runs until a separately authorized verification wave.
• Do not read full historical plans, all status logs, or the full gap plan by default.
• Keep unrelated user changes. Never use git reset --hard or git checkout --.
• Keep long-running sessions alive and poll them to completion.
• If the same blocker persists through three safe investigation attempts, leave the task unadvanced and report the blocker, exit codes, evidence state, and required user decision.

Completion Report

Report completed task IDs, the current queue pointer, parent manifest, focused commands and exit codes, generated evidence paths, SHA-256/governance results, remaining uncommitted task files, and any blocker. Do not include full command logs or the previous conversation transcript.