# LinuxCNC Web/WASM 连续执行计划 更新时间:2026-08-21 本计划只服务于仿真实现的连续接续;`nextTask1.md` 是仿真状态入口, `context-lock.json` 只用于来源和工具链复现。 持续执行的可复制提示词集中在 [`持续执行提示词`](linuxcnc-web-wasm-autonomous-execution-prompt.md)。实际任务状态仍只以 `nextTask1.md` 为准。 ## 当前状态 当前仿真轨道直接按 `nextTask1.md` 认领和执行,不等待外部输入。 - `context-lock.json` 当前 context 为 `linuxcnc-2.10.0-pre0-wasm-m1-py-c1`。 - 已完成任务不重复执行,后续任务按依赖顺序连续认领。 - ABI/protocol/schema 变更可以在仿真需要时实施,但必须同时更新兼容性测试和恢复证据。 因此采用两条泳道: 1. **治理泳道**:等待 owner 输入,完成 intake 校验,审查新 context,再重开 K8 release 任务。 2. **技术泳道**:维护 INT-01..INT-10 的有序队列、设计和测试准备;只有当前 context 明确允许实现时才修改 ABI 或 runtime。 仿真轨道只有实现正确性、确定性和可恢复性状态,不设置发布泳道或 owner 阻塞状态。 ## 连续认领规则 每次接续按以下固定循环执行,避免再次停在模糊的“下一步”: 1. 读取 `nextTask.md` 的 `Current/Task/Verify/Stop`,再读取本任务直接输入。 2. 运行四个基线门禁: `validate_baseline.py`、`validate_download_index.py`、脚本 unittest、 `validate_task_pointer.py`。 3. 从下面队列中选择第一个依赖已满足、没有外部决策缺口的任务;不得跳过前置任务。 4. 先写任务测试和失败边界,再实现最小垂直切片;每个任务保留 native、WASM/Worker 和状态 hash 证据。 5. 运行任务专属测试和回归门禁,生成确定性报告;失败时保留样本和错误码,不删样本、 不降低检查、不把资源缺失重分类为 `REAL-EXCLUDED`。 6. 更新任务报告和本计划的任务状态;下一项只有在依赖、测试和报告均 verified 后才能 认领。 7. 遇到 owner、源码、ABI、protocol、schema、浏览器或许可证外部输入时,生成 blocked 证据并转入治理泳道;禁止自动重试同一阻塞任务。 任务认领必须能回答四个问题:`task_id`、`context_id`、直接输入、完成报告。没有这四项 就不开始实现。 ## 任务队列 | 顺序 | 任务 | 目标 | 主要产物 | 前置条件 | 当前状态 | |---|---|---|---|---|---| | 0 | `GOV-INTAKE-01` | 强化 owner decision 的字段、路径和证据 hash fail-closed 校验 | `scripts/validate_owner_decision_intake.py`、专项测试 | 当前 context | `verified` | | 1 | `OWNER-INPUT-01` | 收集并校验六项 owner decision | `coverage/owner-decisions.json`、intake report | 外部 owner 输入 | `blocked` | | 2 | `CONTEXT-REFRESH-01` | 审查新的锁定 context,确认源码/ABI/schema 变化 | 新 context lock、context packet | `OWNER-INPUT-01` 完整且已审查 | `blocked` | | 3 | `INT-01` | 建立 `sim_task` 状态对象、固定 tick 边界和 C ABI | `sim_task.h/.c`、native/WASM task test、ABI report | 新 context、protocol v1 | `queued` | | 4 | `INT-02` | 实现 `PROGRAM_LOAD/RUN/PAUSE/RESUME/ABORT/STEP` | minimal XYZ E2E、command golden | `INT-01`、配置 resolver | `queued` | | 5 | `INT-03` | 串联 TP -> IK -> motion -> FK,并实现事务回滚 | motion/gantry/TRT 差异报告 | `INT-01/02`、K0-K6 | `queued` | | 6 | `INT-04` | 把 HAL、IO、Python 放入同一固定 tick | IO/tool/probe/estop/remap 测试 | `INT-03`、M3-RT/PY | `queued` | | 7 | `INT-05` | 将配置资源解析结果接入 runtime 启动 | 233 入口 ready/blocked/error 报告 | `INT-01`、M3-CFG | `queued` | | 8 | `INT-06` | 执行 Python/remap/filter,保留能力拒绝边界 | remap、参数、异常、资源限制报告 | `INT-02`、M3-PY | `queued` | | 9 | `INT-07` | 接入真实 OPFS、journal、checkpoint 和 Worker 重启 | browser recovery/offline 矩阵 | `INT-01`、M3-FS | `queued` | | 10 | `INT-08` | 前端消费权威 Task snapshot/event | run/pause/step/alarm/recovery E2E | `INT-02/04`、FE-M1..M4 | `queued` | | 11 | `INT-09` | 用真实 pose/joints/toolpath 驱动 Three.js | vismach、canvas/WebGL、性能报告 | `INT-03`、`INT-08` | `queued` | | 12 | `INT-10` | 执行 233 个 sim entrypoint 的全量差异闭环 | startup matrix、source/resource/component 定位 | `INT-05..09` | `queued` | | 13 | `K8-REL-17+` | 重新生成 closure/audit/gate,处理六项 blocker | release candidate gate | owner decision、新 context、对应证据 | `blocked` | `INT-01..INT-04` 是功能主链;`INT-05..INT-07` 是运行时闭环;`INT-08..INT-09` 是前端 融合;`INT-10` 是规模化回归。任务状态只能按 `queued -> in_progress -> verified` 或 `in_progress -> blocked` 转移,不允许从 `blocked` 自动回到 `in_progress`。 ## 当前可执行动作 在 `OWNER-INPUT-01` 仍缺失时,只执行以下动作: ```bash python3 scripts/validate_baseline.py python3 scripts/validate_download_index.py python3 -m unittest discover -s scripts -p 'test_*.py' -v python3 scripts/validate_task_pointer.py python3 scripts/validate_owner_decision_intake.py python3 scripts/test_owner_decision_intake.py ``` 这些动作只确认仿真基线和阻塞证据,不重复实现已经完成的矩阵。 收到 owner 文件后,必须先验证六个 blocker 恰好各出现一次、context 一致、字段完整、 证据 hash 有效;即使六项都是 `approve`,也只能进入 `CONTEXT-REFRESH-01`,不能直接把 release 状态改为 accepted。 ## 任务完成门禁 每个技术任务至少需要: - 明确的输入 context 和来源 hash; - native 测试; - WASM 或 Worker 对照测试(适用时); - 错误、非有限值、容量、abort/恢复边界; - 确定性状态 hash 或报告 self-hash; - 不改变无关任务的报告和六项 release blocker。 最终项目完成还必须通过完整回归、浏览器矩阵、资源闭包、许可证决策、官方 oracle 和 owner review。任何一项缺失都只能保持 `blocked`,不能以“模块测试通过”替代端到端完成。