docs(web): prioritize source-backed Blender migration
This commit is contained in:
mes123456
39
nextTask.md
39
nextTask.md
@@ -25,6 +25,36 @@ 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.
|
||||
|
||||
## Blender Web Migration Mission Gate
|
||||
|
||||
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
|
||||
manifest:
|
||||
|
||||
1. `SOURCE_IMPLEMENTATION`: adds or wires a previously uncovered behavior in
|
||||
`blender-5.2.0/source/blender`, WebEngine Main, the unified WASM ABI,
|
||||
Worker/client routing, protocol types, or the Web UI entrypoint.
|
||||
2. `INTEGRATION_BUILD`: compiles or bundles the source-backed behavior just
|
||||
implemented and proves that the production path is connected.
|
||||
3. `QUEUE_ENABLEMENT`: generates the minimum manifest/task metadata needed to
|
||||
reach the next source implementation. It is bookkeeping, not a Blender
|
||||
capability, and must never be reported as implementation progress.
|
||||
|
||||
`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
|
||||
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.
|
||||
|
||||
Each productive handoff must record `capabilityId`, `behaviorMarker`, source
|
||||
paths, and before/after source or protocol hashes. A marker/hash already present
|
||||
in an ancestor manifest is reused and does not create a new capability. The
|
||||
original inventory and historical provenance remain read-only; only a later
|
||||
hash-bound verification overlay may change effective completion.
|
||||
|
||||
## 一键连续执行入口
|
||||
|
||||
把下面的文本作为用户消息发送，即可让执行代理从当前队列自动开始，并在
|
||||
@@ -150,7 +180,8 @@ and (when authorized) repository push:
|
||||
17. PUSH_COMPLETION_IRON_RULE：任何任务只有在 commit 成功、`git push origin main` 成功且 `git ls-remote --refs origin refs/heads/main` 返回的远端 HEAD 与本地 `git rev-parse HEAD` 相同后才算完成；确认前不得读取下一任务。网络失败最多按退避策略重试，状态未知时不得重放任务写入。
|
||||
18. GUARDIAN_CONTINUITY_IRON_RULE：无人值守运行必须由 `run-wbv2-guardian.mjs` 托管 supervisor。guardian 对可证明的 `handed_off` checkpoint 自动恢复，对 `running`、`started`、`blocked`、指针漂移、远端提交不明或任务闭合状态保持精确停止；“不停歇”仅适用于安全可恢复的进程/网络故障，不能解释为绕过真实阻塞。
|
||||
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 能力切片。只有当前任务没有可实现的源码能力或存在真实阻塞时，才允许处理辅助治理工作。
|
||||
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 移植完成。
|
||||
```
|
||||
|
||||
## Resume Command
|
||||
@@ -195,6 +226,8 @@ while queue has an active task:
|
||||
read docs/EXECUTION_QUEUE.md
|
||||
print and validate a fresh compact task context
|
||||
assert queue.currentTask == parentManifest.nextTask
|
||||
classify the task as SOURCE_IMPLEMENTATION, INTEGRATION_BUILD, or QUEUE_ENABLEMENT
|
||||
assert that any QUEUE_ENABLEMENT immediately unlocks a source-backed slice
|
||||
execute exactly that task's focused implementation command
|
||||
write report/status/manifest/task-context through repository generators
|
||||
run the required governance, typecheck, lint, build and diff gates
|
||||
@@ -215,7 +248,9 @@ capability family or unique behavior from the immutable 6900 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
|
||||
inventory and provenance; implementation progress is recorded in task reports,
|
||||
not completion overlays.
|
||||
not completion overlays. If the answer is "queue metadata only", record the
|
||||
handoff as `QUEUE_ENABLEMENT` and immediately continue to the unlocked source
|
||||
slice; do not treat the metadata handoff as feature progress.
|
||||
|
||||
For process-level unattended execution, run:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user