feat(web): authorize corrective smooth reader
This commit is contained in:
125
nextTask.md
125
nextTask.md
@@ -16,17 +16,31 @@ external documentation are supplemental references for toolchain/browser
|
||||
constraints only; they cannot override or replace behavior present in the
|
||||
Blender source.
|
||||
|
||||
Implementation iron rule: advance the 6900-entry inventory through capability
|
||||
families and unique behavior batches at maximum practical throughput. Do not
|
||||
run Chromium, E2E receipts, parity verification, save/reopen verification,
|
||||
determinism checks, or completion overlays in this implementation lane. The
|
||||
only allowed checks are source compilation, TypeScript/type safety, lint,
|
||||
bounded build and queue/governance integrity needed to avoid committing broken
|
||||
functionality. Do not drift into repeated maintenance-only waves while an
|
||||
unimplemented Blender capability family remains available.
|
||||
Implementation iron rule: derive the current inventory from
|
||||
`blender-5.2.0/source/blender` with the deterministic source inventory tool,
|
||||
then advance it through finite function modules. The historical 6900-entry
|
||||
catalog is a read-only estimate. A module owns a coherent source/protocol/Worker/frontend
|
||||
boundary and its aggregate operator case matrix. Do not run generic
|
||||
continuation tasks, repeated markers, or build-only tasks as feature work. A
|
||||
Mutation modules require source hash stability, real Main mutation, negative
|
||||
no-mutation, undo/redo, save/reopen, Chromium, and aggregate receipt evidence;
|
||||
read-only modules require an exact Main reader/context receipt instead of a
|
||||
fabricated writer claim. Every module still records its negative boundaries
|
||||
and recovery behavior before handoff.
|
||||
Completed module receipts are hash-checked and reused without rerun. The
|
||||
original inventory and historical provenance remain read-only.
|
||||
|
||||
## Blender Web Migration Mission Gate
|
||||
|
||||
## 项目移植铁律
|
||||
|
||||
1. 彻底梳理完整项目,以 `blender-5.2.0` 源码为第一依据,尽快按真实功能边界完成 Web/WASM 移植;不得用计划、索引、构建或占位接口替代生产能力。
|
||||
2. 从权威队列和 parent manifest 找出执行任务的开头,明确唯一合法的 `nextTask`;每轮完成一个受源码映射的任务后立即读取新 manifest,持续执行直到队列闭合或出现可证明阻塞。
|
||||
3. 按“功能族 -> 模块 -> capability/command -> operator case matrix”组织移植;复用已有 Main、WASM ABI、协议、Worker、前端和 hash-bound receipt,禁止重复实现或逐条重复处理。
|
||||
4. 以源码动态 inventory 为当前覆盖依据:运行 `node tools/web/generate-source-dynamic-inventory.mjs` 重新统计真实源码单元,并通过精确 source/case 映射、正负例、恢复、Chromium、save/reopen、确定性和聚合 manifest 逐步收敛。历史 `6900-entry` 仅是只读初始估算,`5200` 仅是非强制规划估计;每完成一个段落或模块,报告必须列出动态 unitCount、verifiedUnits、unverifiedUnits、源码树 SHA,以及本段绑定增量,未绑定单元不得计为覆盖。
|
||||
|
||||
以上铁律与历史 6900-entry inventory/provenance 只读规则、源码动态 inventory、Chromium-only 规则和失败保持 `in_progress`/`blocked` 规则同时生效;任何冲突以源码、parent manifest 和本节铁律为准。
|
||||
|
||||
This is the highest-priority rule for every continuation turn: the only
|
||||
deliverable is a real, source-backed Blender-to-Web/WASM capability. Before
|
||||
running a task entrypoint, classify the task against the current parent
|
||||
@@ -44,7 +58,7 @@ manifest:
|
||||
`SOURCE_IMPLEMENTATION` is the productive lane. A `QUEUE_ENABLEMENT` task may
|
||||
run only when it immediately unlocks an available source capability; it must
|
||||
not be repeated as a wave, counted as a completed feature, or used to reduce
|
||||
the 6900 effective pending count. If the task card or entrypoint is metadata
|
||||
the dynamic inventory without explicit evidence. If the task card or entrypoint is metadata
|
||||
only while an uncovered source capability is available, preserve the queue
|
||||
pointer, record the mismatch, and select the next source-backed slice through
|
||||
the repository generator rather than fabricating progress.
|
||||
@@ -64,18 +78,19 @@ hash-bound verification overlay may change effective completion.
|
||||
按 nextTask.md 不间断执行。
|
||||
|
||||
这是执行命令,不是计划、状态汇报或等待确认。读取仓库当前队列和 parent
|
||||
manifest,严格从当前 `nextTask` 开始。每次只完成一个任务,完成后写入
|
||||
manifest、status、task-context,提交并推送 `origin/main`,重新读取新的
|
||||
`nextTask`,立即开始下一轮,直到队列闭合或遇到真实阻塞。
|
||||
manifest,严格从当前模块 `nextTask` 开始。每次只完成一个功能模块;完成后写入模块
|
||||
receipt、manifest、status、task-context,提交并推送 `origin/main`,重新读取新的
|
||||
`nextTask`,立即开始下一模块,直到队列闭合或遇到真实阻塞。授权、索引、重复
|
||||
continuation 和单纯 build 不得推进模块完成。
|
||||
|
||||
主线是使用 `blender-5.2.0` 源码实现 Blender Web/WASM 全部能力:优先修改
|
||||
Blender Main、WebEngine C++、WASM、协议、Worker、客户端和前端真实入口;按
|
||||
capability family 和唯一行为批量推进 6900 条目,复用已有 hash 证据,禁止
|
||||
重复实现或逐条重复处理。
|
||||
module -> capability -> operator case matrix 推进源码动态 inventory,复用已有 hash
|
||||
证据,禁止重复实现或逐条重复处理;模块验证失败保持 `in_progress`,不推进 successor。
|
||||
|
||||
当前阶段只做实现和必要的源码编译、WASM 构建、TypeScript、lint、前端构建
|
||||
及队列治理检查;不执行 Chromium/E2E/parity/receipt/save-reopen/determinism
|
||||
验证,不写 completion overlay,不修改原始 inventory 或历史 provenance。
|
||||
当前模块阶段必须执行模块卡绑定的源码/WASM 构建、TypeScript、lint、Chromium 正负例、
|
||||
undo/redo、save/reopen、确定性和聚合 receipt;不写 completion overlay,不修改历史
|
||||
inventory 或 provenance,动态 unit 只有在证据绑定后才计为 verified。
|
||||
|
||||
每轮开始运行 `node tools/web/print-task-context.mjs` 和
|
||||
`node tools/web/check-task-context.mjs`;只读取当前任务卡和最小输入。任何
|
||||
@@ -126,6 +141,44 @@ guardian/supervisor 的连续契约:
|
||||
- guardian 或 supervisor 进程退出后,再次执行同一 guardian 命令即可从当前队列恢复;不复制旧日志、不重放未知命令。
|
||||
- guardian 只负责有效 handoff 和可证明的进程恢复,不能绕过真实阻塞、治理门禁、源码编译失败或 provenance 规则。
|
||||
|
||||
## 队列调度器
|
||||
|
||||
需要跨越聊天、终端和网络边界持续领取任务时,使用仓库内的最外层调度器:
|
||||
|
||||
```bash
|
||||
node tools/web/run-wbv2-scheduler.mjs --max-iterations 0 --commit --push
|
||||
```
|
||||
|
||||
脱离终端运行:
|
||||
|
||||
```bash
|
||||
setsid -f nohup node tools/web/run-wbv2-scheduler.mjs --max-iterations 0 --commit --push \
|
||||
> tests/golden/WBV2/continuous-scheduler.stdout.log 2>&1 < /dev/null
|
||||
```
|
||||
|
||||
调度器每轮重新读取 `docs/EXECUTION_QUEUE.md`、parent manifest 和 task-context,
|
||||
先检查当前源码能力是否有明确的非 generic 行为映射,再调用 guardian 执行恰好
|
||||
一个任务。子任务成功提交、推送并确认远端 `main` HEAD 等于本地 HEAD 后,立即
|
||||
重读新的 `nextTask` 并开始下一轮,不等待聊天消息。
|
||||
|
||||
调度器运行时写入 `tests/golden/WBV2/continuous-scheduler.lock`、
|
||||
`continuous-scheduler.json` 和 `continuous-scheduler.log`;checkpoint 使用临时
|
||||
文件加原子改名。源码映射缺失、旧 generic marker、任务失败、队列未前进、队列在
|
||||
失败后已前进、远端 HEAD 未确认或状态未知时,必须写入 `blocked` checkpoint 并停下,
|
||||
不得为追求连续而重放未知写操作、伪造能力或把 metadata handoff 当作功能完成。
|
||||
|
||||
启动前可以只做只读预检,不领取任务:
|
||||
|
||||
```bash
|
||||
node tools/web/run-wbv2-scheduler.mjs --preflight-only
|
||||
```
|
||||
|
||||
预检非零表示当前任务有真实源码/证据阻塞;修复后重新启动调度器。实时状态使用:
|
||||
|
||||
```bash
|
||||
node tools/web/print-wbv2-live-status.mjs --json
|
||||
```
|
||||
|
||||
### 动态运行状态
|
||||
|
||||
`nextTask.md` 的 Current Handoff Snapshot 只是写入时快照,不能用来判断进程
|
||||
@@ -142,10 +195,10 @@ node tools/web/print-wbv2-live-status.mjs
|
||||
node tools/web/print-wbv2-live-status.mjs --watch --interval-ms 2000
|
||||
```
|
||||
|
||||
状态输出中的 `RUNNING` 表示 guardian 和 supervisor 锁对应的 PID 均存活,且
|
||||
当前任务正在执行或进行交接;`IDLE` 表示没有活动实例;`BLOCKED` 表示必须先
|
||||
读取 checkpoint 原因。JSON 机器读取使用 `--json`,可用于 CI、监控或重连脚本。
|
||||
guardian 每两秒刷新 heartbeat,checkpoint 采用临时文件加原子改名,避免动态
|
||||
状态输出中的 `RUNNING` 表示 scheduler 锁存活,或 guardian 和 supervisor 锁对应
|
||||
的 PID 均存活,且当前任务正在执行或进行交接;`IDLE` 表示没有活动实例;`BLOCKED`
|
||||
表示必须先读取 scheduler/guardian/supervisor checkpoint 原因。JSON 机器读取使用
|
||||
`--json`,可用于 CI、监控或重连脚本。checkpoint 采用临时文件加原子改名,避免动态
|
||||
提示读到半个 JSON。
|
||||
|
||||
## Copyable Resume Prompt
|
||||
@@ -162,19 +215,19 @@ and (when authorized) repository push:
|
||||
1. 先读取 `AGENTS.md` 和 `docs/EXECUTION_QUEUE.md`,然后运行:
|
||||
`node tools/web/print-task-context.mjs`
|
||||
`node tools/web/check-task-context.mjs`
|
||||
2. 当前任务必须等于 parent manifest 的 `nextTask`。只读取当前任务卡、parent manifest/status 和 task-context 列出的最小输入;禁止默认读取完整历史计划、全部 `docs/status` 或 6900 条目详情。
|
||||
2. 当前任务必须等于 parent manifest 的 `nextTask`。只读取当前任务卡、parent manifest/status 和 task-context 列出的最小输入;禁止默认读取完整历史计划、全部 `docs/status` 或历史 6900 条目详情。
|
||||
3. 每次只实现当前任务卡规定的一个能力族或一个独立接线切片。以 `blender-5.2.0` 源码、Blender Main 数据结构和 C/C++ API 为第一依据,再同步 WebEngine dispatch、协议类型、worker/client 路由和前端入口;网页资料只补充构建/浏览器约束,不得用模拟数据、空壳接口或网页描述替代真实实现。
|
||||
4. 严禁重复工作:相同 source hash、behavior hash、dedupe key 或已存在的实现直接复用;不重复运行已有 Blender/WASM/Chromium 行为;6900 条目按 capability family 批量映射,完成条目只作未来回归引用。
|
||||
4. 严禁重复工作:相同 source hash、behavior hash、dedupe key 或已存在的实现直接复用;不重复运行已有 Blender/WASM/Chromium 行为;动态源码单元按 capability family 批量映射,历史条目只作回归引用。
|
||||
5. 实现波次只要求最小安全检查(源码语法、TypeScript typecheck、lint、可用时的 Vite/build 和浏览器启动 smoke);不为每个新能力生成完整 E2E receipt,不在实现阶段写 completion overlay,不声称历史 parity。
|
||||
6. 原始 P0 inventory、6900 总数、6618 legacy pending 和历史 provenance 始终只读。effective completed/pending 只由后续 hash-bound 验证 overlay 计算;实现完成不等于条目完成。
|
||||
6. 原始 P0 inventory、6900 历史总数、6618 legacy pending 和历史 provenance 始终只读。当前动态 inventory 由源码树哈希绑定;verified/unverified 只由后续 hash-bound 行为证据更新,实现完成不等于单元完成。
|
||||
7. 长输出写入 `tests/golden/<task>/command.log`;交互只报告退出码、短尾部、构件路径和 SHA-256。
|
||||
8. 任务成功后运行 `node tools/web/check-task-context.mjs --task <task-id> --write`、`node tools/web/check-context-governance.mjs`、`node tools/web/check-v2-task-index.mjs`、`npm --prefix web run typecheck`、`npm --prefix web run lint` 和 `git diff --check`;完整生产验证门禁统一在验证波次执行。
|
||||
9. 所有实现门禁通过后自动提交并推送 `origin/main`;必须再次用 `git ls-remote` 确认远端 `main` 与本地 `HEAD` 完全相同,确认完成后才从新 parent manifest 读取 `nextTask` 继续。凭据不得写入文件、URL、日志或提示词。
|
||||
10. 任一命令失败、输入缺失、队列不一致、环境不可用或状态不明时,保持 `in_progress`/`blocked`,不得推进指针、伪造完成或重复未知结果的状态改变命令。
|
||||
11. 每轮结束报告实现切片、当前任务、`nextTask`、最小检查退出码、原始 inventory、effective inventory 是否保持不变、提交/推送状态和剩余真实阻塞。
|
||||
11. 每轮结束报告实现切片、当前任务、`nextTask`、最小检查退出码、动态 inventory unitCount/verifiedUnits/unverifiedUnits/sourceTreeSha256、历史 inventory 是否保持只读、提交/推送状态和剩余真实阻塞。
|
||||
12. CONTINUOUS_LOOP_REQUIRED:成功交接后立即开始下一轮;不得在成功提交、推送或生成新 manifest 后等待用户确认、只写计划或只汇报状态。每轮必须重新运行 `print-task-context` 和 `check-task-context`,使用新 parent manifest 的 `nextTask`,不沿用上一轮上下文。
|
||||
13. 可使用仓库内 guardian 保持进程级连续执行:`node tools/web/run-wbv2-guardian.mjs --max-iterations 0 --commit --push`。它托管 supervisor,`0` 表示不限轮数,`--max-iterations N` 用于受控运行,`--commit --push` 才允许自动提交/推送。push 网络抖动由 runner 自动退避重试并确认远端 HEAD;任何入口失败、退出 0 但队列未前进、治理失败、远端无法确认或状态不明都保留 checkpoint,guardian 只自动恢复可证明安全的 handoff。
|
||||
14. 6900_IMPLEMENTATION_IRON_RULE:只按 capability family 和唯一行为批次实现全部 Blender 功能;不启动 Chromium/E2E/receipt/parity/save-reopen/determinism 验证,不写 completion overlay,不把维护 smoke 当作能力完成。若任务卡与本铁律冲突,以源码实现和本铁律为准,并将验证留到后续独立验证波次。
|
||||
14. SOURCE_DYNAMIC_INVENTORY_IRON_RULE:当前覆盖目标必须来自 `blender-5.2.0/source/blender` 的确定性统计;6900 是历史估算,5200 是非强制规划估计。任何新 verified unit 必须绑定源码位置、行为证据、负例和恢复证据;不得为了接近估计数字添加无效占位单元。
|
||||
15. UNIFIED_WASM_JSON_ABI_IRON_RULE:Worker 与 WASM 的新调用统一使用单一 C ABI `web_engine_call_json(handle, requestJson, resultOut)`;请求必须是 `{"cmd":"...","params":{...}}`,返回必须是 `{"ok":true,"cmd":"...","result":...}` 或包含 `code/error` 的失败 JSON,再由 Worker 解析为领域结果。`applyCommand`、快照、增量、撤销/重做、Depsgraph 等状态路径不得新增独立公开 WASM 函数;open/append/save/geometry 等仍未迁移的二进制专用 ABI 仅作为兼容边界保留,并不得扩散到新的状态调用。
|
||||
16. PROCESS_CONTINUITY_IRON_RULE:要实现跨会话不间断执行,必须使用 `run-wbv2-guardian.mjs --max-iterations 0` 托管 `run-wbv2-supervisor.mjs`;单次聊天执行完成后不得假定代理会在下一轮自动复活。guardian/supervisor 必须按任务原子迭代、锁队列、写 checkpoint、成功后立即重读 manifest;失败或状态未知时只能停在精确 checkpoint,不得自动重试或伪造队列前进。
|
||||
17. PUSH_COMPLETION_IRON_RULE:任何任务只有在 commit 成功、`git push origin main` 成功且 `git ls-remote --refs origin refs/heads/main` 返回的远端 HEAD 与本地 `git rev-parse HEAD` 相同后才算完成;确认前不得读取下一任务。网络失败最多按退避策略重试,状态未知时不得重放任务写入。
|
||||
@@ -182,6 +235,8 @@ and (when authorized) repository push:
|
||||
19. LIVE_STATUS_IRON_RULE:任何“当前是否在执行”的判断必须以 `node tools/web/print-wbv2-live-status.mjs` 的实时输出为准,不得使用 `nextTask.md` 的静态 snapshot、旧聊天消息或单个历史 manifest 推断。`RUNNING`、`IDLE`、`BLOCKED` 必须分别显示活动 PID、当前任务和 checkpoint 路径;状态工具只读,不得改变队列。
|
||||
20. BLENDER_WEB_MIGRATION_ONLY_IRON_RULE:本项目唯一任务是依据 `blender-5.2.0` 源码,将 Blender 能力完整、高效、可运行地移植到 Web/WASM。每个连续迭代必须优先产生真实的 Blender Main、WebEngine、WASM、Worker、协议、客户端或前端能力实现;执行监控、状态展示、文档整理、重复审计和维护性变更不得取代可用的 Blender 能力切片。只有当前任务没有可实现的源码能力或存在真实阻塞时,才允许处理辅助治理工作。任何 `QUEUE_ENABLEMENT` 只能作为一次性解锁步骤,不能冒充 `SOURCE_IMPLEMENTATION` 或减少 effective pending。
|
||||
21. MIGRATION_PROGRESS_ACCOUNTING_IRON_RULE:任务报告必须同时列出 `taskClass`(`SOURCE_IMPLEMENTATION`、`INTEGRATION_BUILD` 或 `QUEUE_ENABLEMENT`)、`capabilityId`、`behaviorMarker`、source/protocol before-after hash、实际变更文件和是否新增可运行 Web/WASM 路径;没有真实能力变化的任务只能记录为 enablement,不能宣称 Blender 移植完成。
|
||||
22. SCHEDULER_CONTINUITY_IRON_RULE:无人值守连续执行必须使用 `run-wbv2-scheduler.mjs --max-iterations 0`。调度器每轮只领取 authoritative queue 当前 `nextTask` 指向的一个任务,先通过源码能力映射预检,再委托 guardian/supervisor 完成原子 handoff;只有 child exit 为 0、队列确实前进、commit 成功、push 成功且远端 `main` HEAD 等于本地 HEAD 时,才允许进入下一轮。`QUEUE_ENABLEMENT` 不能冒充功能进度,source task 没有显式非 generic marker 时必须保持 `blocked`。进程崩溃、传输抖动只在 checkpoint 能证明 handoff 已完成时自动恢复;任何未知状态、源码/构建/治理失败或队列漂移都停止并保留精确 checkpoint。调度器不得通过无限重试绕过真实阻塞、重复状态写入或伪造移植完成。
|
||||
23. SCHEDULER_STARTUP_RULE:`run-wbv2-scheduler.mjs` 是连续执行的唯一推荐启动入口;`run-wbv2-guardian.mjs` 仍可用于单独调试,但无人值守运行必须由调度器托管。使用 `--preflight-only` 只能做只读映射检查,不得把预检通过解释为功能已完成;调度器退出后必须依据 `continuous-scheduler.json` 和实时队列恢复,禁止根据静态 snapshot 猜测下一任务。
|
||||
```
|
||||
|
||||
## Resume Command
|
||||
@@ -244,9 +299,9 @@ is itself an executable enabling task: run its declared root generator, then
|
||||
continue from the generated child task in the same continuous run.
|
||||
|
||||
Every implementation iteration must answer one question before editing: which
|
||||
capability family or unique behavior from the immutable 6900 inventory becomes
|
||||
capability family or unique behavior from the source dynamic inventory becomes
|
||||
more implemented by this change? If the answer is only "maintenance", skip it
|
||||
when a source-backed capability slice is available. Maintain the original
|
||||
when a source-backed capability slice is available. Maintain the historical
|
||||
inventory and provenance; implementation progress is recorded in task reports,
|
||||
not completion overlays. If the answer is "queue metadata only", record the
|
||||
handoff as `QUEUE_ENABLEMENT` and immediately continue to the unlocked source
|
||||
@@ -412,12 +467,12 @@ Recorded: 2026-08-29 Asia/Shanghai
|
||||
|
||||
| Field | Value |
|
||||
| --- | --- |
|
||||
| Current task when this file was written | `WBV2-P607-002` |
|
||||
| Current task state | `in_progress` |
|
||||
| Parent manifest | `tests/golden/WBV2-P607-001/manifest.json` |
|
||||
| Current task card | `docs/tasks/WBV2-P607-002.md` |
|
||||
| Current task-context nextTask | `WBV2-P607-003` |
|
||||
| Focused command | `node tools/web/generate-wbv2-capability-continuation-slice.mjs --task WBV2-P607-002 --write` |
|
||||
| Current task when this file was written | `WBV2-P1145-001` |
|
||||
| Current task state | `done` |
|
||||
| Parent manifest | `tests/golden/WBV2-P1145-001/manifest.json` |
|
||||
| Current task card | `docs/tasks/WBV2-P1145-001.md` |
|
||||
| Current task-context nextTask | `NONE` |
|
||||
| Focused command | `node tools/web/check-wbv2-module-execution.mjs` |
|
||||
|
||||
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
|
||||
@@ -427,7 +482,7 @@ number from this table or from historical status files.
|
||||
|
||||
- Chromium is the only permitted browser runtime; never run Firefox or WebKit.
|
||||
- `blender-5.2.0` source and Blender Main are the behavior authority; web references are supplemental and must be recorded only when they affect build/runtime constraints.
|
||||
- The 6900 implementation lane is verification-free: no Chromium/E2E receipts, parity overlays, save/reopen or determinism runs until a separately authorized verification wave.
|
||||
- The historical 6900 inventory and provenance are immutable. The current inventory is the source-derived `tests/golden/WBV2/dynamic-inventory.json`; 5200 is a non-binding planning estimate. Function modules use Chromium/E2E, save/reopen and determinism evidence, and only explicit source/case mappings can increase verified units.
|
||||
- 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 --`.
|
||||
|
||||
Reference in New Issue
Block a user