# 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

```text
按 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.