按规划继续工作

结论：解释器 WASM、SDK 统一入口、浏览器解释器 smoke 与兼容性文档已闭环，native 和 host/WASM/browser 验证全部通过。

wasm-port/docs/porting-steps-standalone.md

@@ -888,14 +888,20 @@ Keep these documents under `wasm-port/docs/`:
 
 ## Immediate Next Step
 
-Continue expanding the standalone interpreter core from the verified minimal
-traverse path:
+Continue from the current verified extracted-core baseline without adding
+project-authored CNC semantics:
 
-1. keep `convert_g()` execution on vendored LinuxCNC interpreter conversion
-   code and reject any new standalone `Interp::convert_g()` implementation.
-2. identify and shim the native runtime symbols blocking direct compilation of
-   `interp_convert.cc`, `interp_execute.cc`, and related interpreter files.
-3. keep fixture coverage as regression protection while deleting temporary
-   hand-written semantics.
-4. keep all source changes inside `wasm-port/` and leave `../linuxcnc/`
-   read-only.
+1. Keep all `Interp::...` interpreter member behavior on vendored LinuxCNC
+   source. Standalone code may only provide documented runtime-edge stubs such
+   as the current Python/remap boundary.
+2. Expand WASM interpreter coverage by routing more existing native fixture
+   paths through `runtime/core/linuxcnc_wrap/linuxcnc_interp_wasm.cpp`, using
+   the same vendored interpreter source set as the native harness.
+3. Promote remaining standalone-only fixture expectations to native LinuxCNC
+   baselines where possible, especially adapter-heavy paths such as INI/HAL
+   named parameters, tool-change host state, and richer machine session state.
+4. Move browser-facing work through SDK and OPFS adapters only after the core
+   behavior is validated against native LinuxCNC or vendored-source harnesses.
+5. Before adding any CNC feature, update `tools/source-manifest.txt`, extract
+   the LinuxCNC source file, add a source probe or harness, and document the
+   reuse boundary in `docs/source-reuse-map.md`.