chore: checkpoint web Blender migration source, tools and docs
Accumulated uncommitted work: GHOST Web backend, WebGL/GPU web layer, web workflow engine and protocol, tooling, docs and task records. Large generated evidence, user-testing archives, build snapshots and imported test assets remain untracked. Co-Authored-By: Claude Code <noreply@anthropic.com>
This commit is contained in:
mes123456
217
nextTask1.md
Normal file
217
nextTask1.md
Normal file
@@ -0,0 +1,217 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user