chore: close wasm status contract work

备忘/17备忘主要执行过程按钮逻辑.txt

@@ -8,6 +8,12 @@
 6、指导完善“/home/mes123456/cnc_wams/web-rtcp-5axis-xyzbc-trt-sim-plan”程序；
 7、上面的分析结果，写入单独的文档中，指导完善项目。
 
+
+补充看了构建脚本和测试：task-hal WASM 目前只编译 hal_runtime.cpp、motion_runtime.c、linuxcnc_task_hal_wasm.cpp，没有编译上游 emctaskmain.cc 或 taskintf.cc；文档也把它标为 runtime-edge adapter，而不是 native task。
+
+
+
+
 我会把 working9 定义为“执行 Run 按钮主线”，但文档会保留急停、上电、Home、暂停、单步作为 Run 的前置与运行期状态链，因为这些状态直接决定执行按钮能否按 LinuxCNC 语义工作。
 
 
@@ -35,7 +41,10 @@ task 层的核心状态已经清楚：task.state/mode/interpState/task_paused
 
 
 
-初步线索确认：AXIS 按钮入口在 src/emc/usr_intf/axis/scripts/axis.py 和 share/axis/tcl/axis.tcl，Python 扩展把按钮动作转换成 NML 命令，emctaskmain.cc 的状态机决定命令是否可执行。现在我会读关键函数的原始代码段并记录行号。
+初步线索确认：AXIS 按钮入口在 src/emc/usr_intf/axis/scripts/axis.py 和 share/axis/tcl/axis.tcl，Python 扩展把按钮动作转换成 NML 命令，
+emctaskmain.cc 的状态机决定命令是否可执行。现在我会读关键函数的原始代码段并记录行号。
+
+emctaskmain.cc task 主循环每周期读 motion
 
 
 

备忘/18、备忘执行机理.txt

@@ -0,0 +1,148 @@
+要做到“完全对标”，下一步应把 emctaskmain.cc 的周期结构迁到 
+wasm-port：在每个 lctask_run_cycles() task 
+周期建立 LinuxCNC 式 EMC_STAT.motion snapshot，
+执行等价的 command read、plan、execute、motion update、
+subordinate sync、task update、status write 顺序，
+并逐步用上游/ vendored emctask.cc、taskintf.cc、emccanon.cc 
+替换当前 JSON 自有状态机。
+
+
+目录"/home/mes123456/cnc_wams/wasm-port/working"这里面的工作内容，完全对标“下一步应把 emctaskmain.cc 的周期结构迁到 wasm-port：在每个 lctask_run_cycles() task 周期建立 LinuxCNC 式 EMC_STAT.motion snapshot，执行等价的 command read、plan、execute、motion update、subordinate sync、task update、status write 顺序，并逐步用上游/ vendored emctask.cc、taskintf.cc、emccanon.cc 替换当前 JSON 自有状态机。”，要完全对标“/home/mes123456/cnc_wams/linuxcnc”。继续完善实施文档
+
+
+status JSON
+实现策略是保持已有 JSON host 边界不动，
+但让 taskintf 内部的 jog/home/set-aout issue 
+都直接调用新的 lcmot_write_* 结构化 ABI；
+JSON 只继续作为外部兼容输入。
+现在开始补底层 ABI 和 taskintf envelope。
+
+我会新增一份专门的 status JSON 对标方案文档，并把它接入 README、任务矩阵、台账、证据和决策记录。这个方案会把 LinuxCNC 的 EMC_STAT/status buffer 模型映射到 WASM 的 StandaloneEmcStatus -> status JSON 输出边界。
+
+重建后的 task-HAL smoke 通过。继续复跑之前失败的 motion sync 和其它回归。
+对标“/home/mes123456/cnc_wams/linuxcnc”，完善“在wasm中解决status JSON”的方案
+
+
+接下来我会让 AUTO 无 JSON plan 路径真正调用 PlanRead/Line/Level/Command/Execute，并让 MDI PlanExecute 也经过同一个 execute evidence。
+
+
+
+
+Reconnecting /5
+
+
+
+
+
+
+Edited a fileEdited file
+
+
+
+linuxcnc_task_hal_wasm.cpp+86-0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+现在 RUN gate 需要允许 staged program 直接执行，不再强制 lctask_load_program_motion_plan_json()。我会把旧 JSON plan 要求降级为“有可执行行即可”。
+
+
+
+
+Edited a fileEdited file
+
+
+
+linuxcnc_task_hal_wasm.cpp+1-1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+下一步把 execute 阶段的 has_program_work 改成同时支持 JSON motion plan 和 staged program lines；无 JSON plan 时通过新 helper 读/执行当前行。
+
+我会把 no-JSON-plan 用例放到 smoke 末尾，避免影响前面依赖 timed motion plan 的 pause/resume/queue 行为。
+
+现在加入 no-JSON-plan smoke：只 stage/open 程序，不调用 lctask_load_program_motion_plan_json()，再验证 plan read/execute 和 interp_list evidence。
+
+我会把 state matrix 的 loadPlan:false 场景改成 T-040 验收：不加载 JSON plan 也能由 staged program lines 执行。
+
+state matrix 输出名也要改掉，不再声称缺 JSON interpreter plan 会被拒绝。
+
+该 focused case 只需要证明无 JSON plan 的 staged program 进入 PlanRead/Execute；为了避免多段 motion 完成时序影响最后行证据，我会把用例收敛成单行程序。
+
+subset anchor 已补上。下一步修改 wrapper 状态字段和 JSON 输出，所有计数都挂在已有 taskintf_command_from_canon() 路径上。
+wrapper 计数已接入 canon move 转换点。现在把这些字段暴露到 status JSON，供 WASM smoke 和专用脚本验证。
+
+现在更新 WASM 测试断言：主 smoke 覆盖 timed plan 的 traverse/feed evidence，no-json staged program 覆盖 PlanRead 后的 feed 到 EMC_TRAJ_LINEAR_MOVE。
+
+T-044 我会覆盖常见 spindle/tool canonical commands：SET_SPINDLE_SPEED、START_SPINDLE_*、STOP_SPINDLE_TURNING、SELECT_TOOL、CHANGE_TOOL、CHANGE_TOOL_NUMBER、RELOAD_TOOLDATA。这些只作为 interp_list command evidence，不接入真实 tool DB。
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+