workinf_Blender_Wasm/nextTask1.md

Corrective Continuous Task Handoff

This is the continuation entrypoint for the corrective execution plan. The authoritative legacy queue remains docs/EXECUTION_QUEUE.md; this file points only to the shadow corrective task and must never advance M16-GAP-*.

Current Task

Field	Value
plan	docs/BLENDER_WASM_CORRECTIVE_TASK_PLAN.json
current corrective task	C6-003
task card	docs/corrective/C6-003-reactivate-queue.md
lifecycle (plan)	in_progress
checkpoint status (handoff)	in_progress
blocker	none; owner review approved
gate	G5
write scope	queue_reactivation
queue mutation	true
execution mode	corrective_continuous
auto continue after successful handoff	true (conditional)
auto continue now	true after post-handoff gates
fresh compact context after handoff	required
stop on failure or drift	true
handoff required before successor	true
legacy queue checkpoint	M16-GAP-00277 / parent nextTask=M16-GAP-00277
reserved legacy successor	M16-GAP-00278
corrective handoff	tests/golden/corrective/C6-003/handoff.json
handoff next task	C6-003 (post-write verification)

Blocker

The durable corrective checkpoint is C6-003: its dry-run and write-preview bytes match, the explicit owner review is recorded, protected legacy hashes were verified before the write, and the atomic queue write exited 0. The handoff is in_progress for post-write verification with queueMutation=true; the legacy queue now points to M16-GAP-00277 and the rollback receipt is recorded. Do not run another queue write unless the post-write gates identify concrete drift.

The completed predecessor handoffs (C0-001 through C5-003, C6-001, and C6-002) remain immutable evidence. Their completion does not release the current G5 post-write verification gate.

Resume Prompt

按 nextTask1.md 接续执行。

激活 corrective continuous mode。只要用户消息要求“按 nextTask1.md 接续执行”、
“继续执行”或等价含义，就先做只读 checkpoint recovery，再开始当前 Current
Task；不要要求确认、不要只给计划。只有成功 handoff 才能自动开始下一轮；每轮
完成一个 corrective task 后进入 fresh compact context，重新读取本文件的新
Current Task。遇到阻塞、失败、环境缺失、预算耗尽、传输异常、闭合门或用户要求
停止时立即停在当前 checkpoint，不得为了保持连续而越过门禁。

每次请求的第一步固定为只读恢复（即使上一次请求只报告了 remote compact
错误）：

```bash
node tools/web/print-task-context.mjs
node tools/web/check-task-context.mjs
git status --short
jq '{task,status,queueMutation,nextCorrectiveTask,inputDigest,commandExitCodes}' \
  tests/golden/corrective/C6-003/handoff.json

随后运行 node tools/web/check-corrective-plan.mjs。若 plan、task card、handoff 的当前任务/状态/ready/next 不一致，或 handoff status=blocked，只记录精确 阻塞并停止；不得重跑未知结果的生成、构建、保存或 queue-write 命令。恢复请求 最多重试一次；再次出现 stream disconnect、error decoding response body 或 remote compact 失败时保持当前状态并结束本轮。

本文件只驱动 corrective shadow plan。docs/EXECUTION_QUEUE.md 是 legacy M16 指针；两者不可混用。当前 corrective task、依赖、状态、ready 标志和下一任务只 接受 docs/BLENDER_WASM_CORRECTIVE_TASK_PLAN.json、当前 task card 和最新 durable handoff manifest（成功或阻塞）的交叉证明，禁止从历史编号或 Markdown 猜测。

每个 iteration 只完成一个 C0-C6 任务，并严格按以下顺序执行：

1. 读取 docs/EXECUTION_QUEUE.md。
2. 运行 node tools/web/print-task-context.mjs。
3. 运行 node tools/web/check-task-context.mjs。
4. 运行 node tools/web/check-corrective-plan.mjs。
5. 只读取当前 C task card、其明确列出的输入和最小必要 fixture。
6. 若当前 task 为 planned，在所有 preflight 通过后将当前 task/card 标记为 in_progress；若 handoff 为 blocked，保持当前 task/card 和 pointer 不变， 不得提前把任何 successor 标记为 ready 或修改 next pointer。
7. 执行任务卡中的真实命令，把长日志写入 tests/golden/corrective/<task>/，并记录每个命令的退出码。
8. 完成 focused、negative、persistence、hash、determinism 和 governance gate。
9. 在所有 evidence 文件最终化后运行 node tools/web/write-corrective-handoff.mjs，更新该任务的 handoff.json 和 manifest.json；同时更新该 C task 的 status 文档。 handoff 命令不要用会在 hash 扫描后再次截断/写入同一个日志的重定向；若日志 属于 evidence，先写完日志，再运行 handoff，handoff 完成后不得再编辑 evidence。
10. 校验 handoff 的 artifact SHA-256、inputDigest、queueMutation、 nextCorrectiveTask 和命令退出码。dry-run、write、handoff 三者的 inputDigest 必须一致。
11. 只有 handoff 完整成功且所有必需 gate 通过后，才将当前 task 标记为 done， 仅按 handoff manifest 的 nextCorrectiveTask 从依赖图选择 successor；为 successor 创建/校验 task card，并将唯一 successor 标记为 ready。若 handoff 为 blocked，只更新本文件的 durable checkpoint 字段并保留同一 current task， 不创建 successor、不推进 pointer。成功 handoff 后再更新本文件 Current Task 表，重新执行第 1-4 步，开始下一 iteration。
12. 任何状态迁移、task card、plan 或 Current Task 更新都必须由已通过的 handoff 支持；禁止先改指针再补证据。

下一任务只能来自 corrective plan 的依赖图，不能猜测。

严格遵守以下边界：

• C0-C5 期间禁止修改旧 M16 queue、parent manifest、completion registry、 catalog、index、旧 M16 task card 和历史 evidence；corrective task card 只可 按本协议在对应 handoff 前后更新生命周期。
• 禁止手工推进 legacy nextTask、offset、completion 状态或 parent pointer； corrective lifecycle 和 nextCorrectiveTask 只能由通过 handoff 的 evidence 与 corrective dependency graph 支持。
• queueMutation 必须保持 false，直到 C6-003 且 G5 通过。
• --write 只能写入明确的 corrective staging 目录，不能覆盖正式生成物。
• 不得把 CANCELLED、UNSUPPORTED、EXTERNAL_REQUIRED、metadata-only、 snapshot/read-only 或 negative-only evidence 当作正向功能完成。
• 浏览器验收永久只使用 Chromium；禁止 Firefox 和 WebKit。
• 不要删除、重置或回滚用户已有改动；失败证据必须保留。

任何命令失败、hash drift、plan/index/catalog/queue 不一致、parent pointer 失配、digest 不一致、预算异常、环境缺失、传输异常或 gate 阻塞，都立即停止 自动迭代；当前 task 保持 in_progress/blocked，不得创建 successor handoff， 保留失败证据并报告精确路径。不得用重跑覆盖失败日志来伪造通过状态。

当前从 C6-003 checkpoint 恢复。C0-001 至 C5-003、C6-001 和 C6-002 的 handoff 均已完成；明确的 owner review 已记录，queue write 已完成， M16-GAP-00277 现在是唯一 active legacy successor。

上下文大小必须按仓库预算管理：每个 iteration 只保留当前任务卡、parent manifest、parent status、print-task-context 输出和任务卡列出的最小输入；不要 把完整 next-task-plan.json、全部 docs/status/、历史 transcript、完整 parity ledger 或长命令日志带入上下文。默认上下文上限约为 3,500 tokens，serialized context envelope 上限为 1,024 tokens；先运行 check-task-context，只有报告 withinBudget 才能继续。大 JSON 使用 jq 读取指定字段，大日志使用 sed/tail 读取窄范围；完整日志只保存在 evidence root，不复制到对话中。每个命令返回后只 保留退出码、关键摘要、证据路径和 hash。

每次 handoff 后开始 fresh compact context：丢弃上一轮长输出，下一轮只从新 manifest 的 nextCorrectiveTask、status、evidenceRoot、commandExitCodes、sourceHashes、 inputDigest 和 queueMutation 恢复，不依赖上一轮对话。若上下文接近预算，先 停止读取、写入摘要并重新运行 print-task-context；不得用扩大读取范围来解决预算 问题。若 compact、resume 或传输发生异常，先检查已有日志、manifest 和 hash， 从第一个缺失步骤继续；不要盲目重复成功的写入或推进指针。

## Context Budget Protocol

每轮执行前必须建立最小上下文，并把上下文治理本身视为 gate：

1. 只读 `docs/EXECUTION_QUEUE.md`、`print-task-context` 输出列出的文件，以及当前
   task card 的 `inputPaths`、`commands` 和 `exitCriteria`。
2. 先运行 `node tools/web/check-task-context.mjs`；`withinBudget=false`、
   `estimatedContextTokens > 3500` 或 `envelopeTokens > 1024` 时保持当前任务不变，
   缩小读取范围后重试。
3. 不打开完整 `next-task-plan.json`、全部历史 status、完整 generated report、
   完整 git diff 或完整命令输出；需要判断时用 `jq -e/-r` 提取字段、用
   `sha256sum` 校验来源、用 `rg` 定位小节。
4. 将长输出直接写入 `tests/golden/corrective/<task>/`，对话和下一轮上下文只保留
   `exitCode`、一行结果、报告路径、artifact count/hash 和失败原因。
5. 一个 iteration 结束时，必须形成可独立恢复的 compact handoff：
   `task`、`status`、`gate`、`evidenceRoot`、`commandExitCodes`、`sourceHashes`、
   `inputDigest`、`queueMutation`、`nextCorrectiveTask`。
6. 下一 iteration 丢弃上一轮的临时解释和长日志，只读取该 handoff 及新任务卡；
   不把完整历史 transcript 作为隐式输入。
7. 出现 compact/remote transport error 时，停止自动推进，按 Resume Prompt 的
   只读顺序检查磁盘上的证据和 handoff；只在 checkpoint 明确显示某命令缺失且
   不存在未知状态时重跑一次，确认 digest/hash 后再继续。不得用旧 transcript
   或完整日志填充下一轮上下文。

## Iteration Contract

1. Run `node tools/web/print-task-context.mjs` and
   `node tools/web/check-task-context.mjs`.
2. Run `node tools/web/check-corrective-plan.mjs` before editing.
3. Read only the current C task card and its named inputs.
4. Keep all corrective outputs under `tests/golden/corrective/<task>/`.
5. Before and after every task, compare the protected legacy source hashes; a changed
   protected hash is a hard stop, not a reason to re-sign history.
6. A task is complete only when its card's commands, evidence hashes, deterministic
   output check, handoff fields, and all gates pass.
7. Run `node tools/web/write-corrective-handoff.mjs` only after all evidence files
   are final; do not add or edit evidence afterward without regenerating the handoff.
8. Update this file only from a durable successful or blocked corrective handoff. The
   current value and any successor come from the handoff manifest and corrective plan
   dependency graph, never from a guessed legacy task number. A blocked handoff may
   refresh the checkpoint fields but must keep the same task and pointer.

## Stop Rules

- Never run a queue-writing command before `C6-003` and `G5`.
- Never count `CANCELLED`, `UNSUPPORTED`, `EXTERNAL_REQUIRED`, metadata-only, or
  negative-only evidence as positive parity.
- Never edit `docs/EXECUTION_QUEUE.md`, legacy `next-task-plan.json`, task
  catalog/index, parent manifest, parent status, or legacy task cards as part of
  C0-C5. Corrective cards and shadow plan state may change only after the
  preflight/handoff rules above are satisfied.
- Stop on the first failed command or inconsistent hash; keep the current task
  `in_progress`/`blocked` and preserve all evidence.
- `owner_review_required` is cleared by the recorded review artifact; any post-write
  hash or pointer drift remains a hard stop and requires rollback receipt review.

## Handoff Fields

Completed handoffs: `C0-001` through `C5-003`, `C6-001`, and `C6-002` are `done`.
The current evidence is under `tests/golden/corrective/C6-003/`; its handoff is
`in_progress`, with `queueMutation=true` and `nextCorrectiveTask=C6-003` while
post-write G5 verification remains active.

After each successful iteration, record `task`, `status`, `gate`, `evidenceRoot`,
`commandExitCodes`, `sourceHashes`, `queueMutation`, and `nextCorrectiveTask` in the
task's machine-readable handoff. Then replace the Current Task table above with the
new corrective task before starting the next iteration.