feat(web): authorize corrective smooth reader

This commit is contained in:
mes123456
2026-09-02 18:35:58 +08:00
parent 244e058999
commit 0d61c64150
51 changed files with 127040 additions and 67 deletions

View File

@@ -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 --`.