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.

Copyable Resume Prompt

Use the following prompt when continuous execution is needed. It deliberately keeps every task iteration bounded while allowing successful handoffs to proceed automatically:

按 nextTask.md 接续执行。

Treat this as an execution command, not a request for a plan or status report.
Enter CONTINUOUS mode and repeat the following bounded iteration until a stop
condition is reached:

1. Read docs/EXECUTION_QUEUE.md, run print-task-context, then run
   check-task-context before editing.
2. Read only the current task card, parent manifest/status, and the focused
   files named by the task context. Do not open the full next-task-plan.json,
   all status logs, or historical project plans.
3. Complete exactly the current task: implement the scoped behavior, run the
   focused desktop/npm/direct checks, verify save/reopen and the negative case,
   write reports/status/manifest/task-context with SHA-256 values, then run
   governance checks and git diff --check.
4. Advance the queue only after every exit criterion and hash check passes,
   using repository generators for the task index/catalog/card.
5. After a successful handoff, discard the previous task transcript and begin
   the next iteration from a fresh print-task-context package. Do not wait for
   another user message and do not carry prior task files into the next
   iteration except through the new parent manifest and status summary.

Keep tool output and context bounded. On any failure or hash drift, keep the
current task `in_progress`/`blocked`, do not advance `nextTask`, and stop the
loop. End only when a stop condition is reached, with a compact summary of all
tasks completed in this run (task, state, nextTask, command exit codes, and
artifact paths/hashes).
For stream-disconnect or remote-compact errors, stop the active request and
use the recovery procedure below in a new request. Do not paste the failed
transcript, invoke another compact operation, or blindly repeat a state-
changing command.

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 continuous run may contain many such iterations, but it must stop at the first failed gate or explicit stop request.

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

Continuous mode must stop immediately when any of these conditions occurs:

• 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;
• the queue has no next task or reaches its declared closure gate;
• the user explicitly asks to stop or pause.

On a 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. There is no retry loop for an unknown or failed result.

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. It is not evidence that the task failed or succeeded. 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. If the resumed request disconnects again, leave the task in_progress/blocked, preserve all files, and report the exact command and checkpoint state rather than starting a 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-22 America/New_York

Field	Value
Current task when this file was written	M16-GAP-00227
Current task state	in_progress
Parent manifest	tests/golden/M16-GAP-00226/manifest.json
Current task card	docs/tasks/M16-GAP-00227.md
Current task-context nextTask	M16-GAP-00228
Focused command	npm --prefix web run test:generated-gap -- --task M16-GAP-00227

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