105 lines
6.1 KiB
Markdown
105 lines
6.1 KiB
Markdown
# 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`，不能以“模块测试通过”替代端到端完成。
|