Continue Blender Web parity task handoff

nextTask.md

@@ -4,37 +4,45 @@ 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 in a fresh request when continuous execution is
-needed. It deliberately names the bounded one-task-per-request contract so a
-long chain of tasks does not become one oversized context or remote compact
-payload:
+Use the following prompt when continuous execution is needed. It deliberately
+keeps every task iteration bounded while allowing successful handoffs to proceed
+automatically:
 
 ```text
 按 nextTask.md 接续执行。
 
 Treat this as an execution command, not a request for a plan or status report.
-Read docs/EXECUTION_QUEUE.md, run print-task-context, then run
-check-task-context before editing. 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.
+Enter CONTINUOUS mode and repeat the following bounded iteration until a stop
+condition is reached:
 
-Complete exactly one current task end to end: 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. Advance the queue only after every
-exit criterion and hash check passes, using repository generators for the
-task index/catalog/card. On any failure or hash drift, keep the task
-in_progress/blocked and do not advance nextTask.
+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. Do not paste long logs or carry the
-previous task transcript into the next request. After handoff, the next
-invocation of this same prompt starts from a fresh print-task-context package.
-This request has a hard stop after this one task: do not inspect, implement, or
-start the next task in the same request, even when the current task finishes
-early. End with only a compact checkpoint summary (task, state, nextTask,
-command exit codes, and artifact paths/hashes).
+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-
@@ -62,13 +70,14 @@ review, or diagnosis do not activate this procedure.
 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. On the next invocation of this command, start immediately from that new
-   pointer and a fresh compact context package.
+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 a valid handoff and the next
-invocation. This still means one task per execution turn/request: never run
-multiple numbered tasks in one request and never carry the previous task's
-full transcript, logs, or source context into the next request.
+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
 
@@ -87,17 +96,36 @@ previous conversation.
 
 ## Fresh-Context Boundary
 
-Handle at most one task per execution turn/request. At the end of a task, the
-machine handoff is the checkpoint; begin the next task 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
-preserving continuous execution across turns.
+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`.
@@ -118,9 +146,9 @@ For every task, run this exact order:
 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 and stop after reporting this task's checkpoint.
-   The next task is started only by a new request using this prompt and a fresh
-   context package.
+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:
 
@@ -168,7 +196,9 @@ 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:
+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:
 
 ```text
 按 nextTask.md 接续执行。
@@ -177,7 +207,9 @@ The recovery request must not include the old transcript or full command logs:
 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，完成后立即停止。
+生成、构建、保存或队列写入命令；恢复当前 task 后进入 CONTINUOUS mode，
+仅在完整 handoff 成功时自动开始下一个 iteration；再次发生同类错误时
+立即停止并报告 checkpoint，不要继续重试。
 ```
 
 ## Current Handoff Snapshot