# Full-Process Runtime Boundary Design

Generated: 2026-06-10 CST

This document records the first design pass for `configs/sim` rows that are
already classified by the Node inventory, but must remain blocked until a
LinuxCNC-owned runtime boundary exists. It is a design and accounting artifact,
not an execution path.

## Scope

- `axis/vismach/millturn/example.ngc`, currently `L4-USER-M-PROCESS`.
- `axis/db_demo/base.ngc`, currently `L4-TOOL-DB`.
- Python-remap and broader full-process families remain inventoried in
  `build/wasm/sim-configs-inventory/blocked-dependency-summary.tsv`; they are
  not promoted here.

## Non-Goals

- Do not implement HAL, task, HALUI, Tcl, Python, tool-database, or external
  process semantics in JavaScript.
- Do not make blocked rows pass by editing upstream G-code, Tcl, Python, INI,
  or tool-table files.
- Do not treat native GUI code or config helper scripts as browser UI
  implementation code.
- Do not mark a row unblocked until native, Node, and browser validation prove
  the boundary where that layer is applicable.

## External User-M Process Boundary

### Current Block

`axis/vismach/millturn/example.ngc` is blocked because
`millturn.ini` declares:

- `[RS274NGC]USER_M_PATH = ./mcodes`;
- `REMAP = M428 ... ngc=428remap`;
- `REMAP = M429 ... ngc=429remap`;
- `[HAL]HALUI = halui`, `HALFILE`, `HALCMD`, and `POSTGUI_HALFILE`;
- `[HALUI]MDI_COMMAND = M128` and `M129`;
- `[DISPLAY]PYVCP = millturn.xml`.

The promoted execution chain reaches `remap_subs/428remap.ngc` and
`remap_subs/429remap.ngc`. Those LinuxCNC NGC remaps execute `M68`/`M66`
switchkins synchronization and then call external user-M process codes
`M128` or `M129`.

### LinuxCNC Owner Set

- `configs/sim/axis/vismach/millturn/millturn.ini` owns the machine
  declarations and search paths.
- `configs/sim/axis/vismach/millturn/remap_subs/428remap.ngc` and
  `429remap.ngc` own the NGC remap call sequence around `M128` and `M129`.
- `configs/sim/axis/vismach/millturn/mcodes/M128` and
  `configs/sim/axis/vismach/millturn/mcodes/M129` own the config side effects.
- `src/emc/task/emctask.cc` owns `USER_M_PATH` search, executable detection,
  `USER_DEFINED_FUNCTION_ADD()`, and queuing `EMC_SYSTEM_CMD`.
- `src/emc/task/emctaskmain.cc` owns `emcSystemCmd()` process spawning and
  completion tracking for queued system commands.
- `src/emc/usr_intf/halui.cc` owns HALUI MDI command queue behavior.
- The HAL runtime owns `hal getp`/`hal setp` state, including the `ini.*`
  soft-limit pins used by the scripts.

### Native Behavior To Preserve

`M128` is a Tcl process script that:

- requires the LinuxCNC and HAL Tcl packages;
- calls `emc_init -quick`;
- calls `parse_ini $::env(INI_FILE_NAME)`;
- checks `hal getp kinstype.is-0`;
- writes mill limits from `[AXIS_X]`, `[AXIS_Y]`, and `[AXIS_Z]` into
  `ini.x.*`, `ini.y.*`, and `ini.z.*` HAL pins.

`M129` follows the same process path, but checks `kinstype.is-1` and writes the
`MIN_LIMIT_TURN` / `MAX_LIMIT_TURN` values for X, Y, and Z. Both scripts also
restore `MAX_VELOCITY` and `MAX_ACCELERATION`.

The NGC remap files own the surrounding interpreter-visible work:

- set `motion.analog-out-03` through `M68`;
- force synchronization with `M66`;
- set G5x offsets with `G10 L2 P7` or `G10 L2 P8`;
- activate `G59.1` or `G59.2`;
- verify `_hal[motion.switchkins-type]` after the switch.

### Boundary Decision

This is not the same boundary as the existing deterministic `M110`/`M111`
registration adapter. `M110` and `M111` can currently be represented as
deterministic `USER_M_COMMAND` canonical events because the promoted tests only
need the interpreter to accept and queue the user-M command. `M128` and `M129`
must also prove HAL pin state updates that affect soft limits after a
kinematics switch.

The row therefore remains `L4-USER-M-PROCESS`.

### Current Machine-Readable Artifact

`user-m-process-boundary-summary.tsv` records the current designed-but-blocked
state target set for this boundary. It maps `M128` to
`remap_subs/428remap.ngc` and `M129` to `remap_subs/429remap.ngc`, records the
`kinstype.is-0` and `kinstype.is-1` guards, and expands the source-traceable
`ini.[xyz].min_limit`, `ini.[xyz].max_limit`, `ini.[xyz].min_velocity`, and
`ini.[xyz].max_acceleration` target pins from `millturn.ini`.
`user-m-process-state-targets.tsv` is the normalized companion table for that
same evidence. It has one pending proof row per `M128`/`M129` target pin,
including the config script source file, remap caller, mill/turn state mode,
guard pin, source INI section/field, and expected value. The current table has
24 target rows plus a header and keeps `proof_status=pending`,
`execution_enabled=0`, and `promotion_allowed=0`.
`user-m-process-transition-plan.tsv` records the next non-executing contract
for this boundary. It binds `M428` to `M128` and `M429` to `M129`, records the
`motion.analog-out-03` switchkins output, target kinstype values `0` and `1`,
the active `G59.1`/`G59.2` work offsets, `P7`/`P8` offset pockets, guard pins,
and the 12 expected `ini.[xyz].*` state outputs for each user-M code. This is
still a pending transition contract only; it does not execute Tcl, start HAL,
or permit standalone/browser promotion.
`user-m-process-native-state-alignment.tsv` aligns those 24 generated target
rows with the native source probe stdout keys, such as
`M128_X_AXIS_X.MIN_LIMIT_ok` and `M129_Z_AXIS_Z.MAX_LIMIT_TURN_ok`. This table
proves the generated pin targets still match the native LinuxCNC source/state
probe output, but it also remains `proof_status=pending`,
`execution_enabled=0`, and `promotion_allowed=0`.
`user-m-process-native-transition-alignment.tsv` aligns the two generated
transition-plan rows with native source probe stdout for `M428` and `M429`.
It verifies the source-owned `motion.analog-out-03` switchkins output, target
kinstype values `0` and `1`, active `G59.1`/`G59.2` offsets, `P7`/`P8`
offset pockets, and `M428 -> M128` / `M429 -> M129` process calls. This is
still source-transition alignment only; it does not execute the Tcl user-M
processes, start HAL, or allow promotion.
`user-m-process-native-runtime-state-plan.tsv` is the next native runnable
probe contract. It records the required LinuxCNC task/HAL/Tcl user-M runtime,
the required environment (`INI_FILE_NAME`, `motion.switchkins-type`,
`kinstype.is-0`, `kinstype.is-1`, and `ini.[xyz].*` pins), the two transition
steps, and the exact expected `ini.[xyz].*` values after each user-M process.
It requires the source transition/state alignment artifacts to be complete, but
keeps `native_runtime_status=pending_native_hal_tcl_process_probe`,
`proof_status=pending`, `execution_enabled=0`, and `promotion_allowed=0`.
`user-m-process-native-runtime-readiness.tsv` records whether the host has the
runtime commands needed to attempt that native probe. It currently checks
`tclsh`, `halrun`, `halcmd`, and `linuxcnc`, records PATH evidence where a
command exists, and keeps the boundary blocked with `proof_status=pending`,
`execution_enabled=0`, and `promotion_allowed=0` even if the commands become
available.
`user-m-process-native-runtime-probe-gate.tsv` is the generated execution gate
for the future runtime probe. It combines source proof readiness with host
runtime readiness for `M428/M128` and `M429/M129`, records missing runtime
commands, and keeps `proof_status=pending`, `execution_enabled=0`, and
`promotion_allowed=0`.
`tests/native/probe_millturn_user_m_runtime.sh` is wired into
`build_native_probes.sh` as `linuxcnc_millturn_user_m_runtime_probe`. On hosts
without `halrun`, `halcmd`, or `linuxcnc`, it exits successfully but reports
`millturn_user_m_runtime_probe_status=skipped_missing_host_runtime`; on a host
with the full LinuxCNC runtime it remains disabled by default. If explicitly
enabled with `ENABLE_MILLTURN_USER_M_RUNTIME_PROBE=1`, it starts the vendored
`millturn.ini`, runs the LinuxCNC-owned Tcl `M128`/`M129` scripts, and verifies
the resulting `ini.[xyz].*` HAL state targets before reporting
`runtime_state_probe_passed`.
If another LinuxCNC runtime is already active, the probe reports
`millturn_user_m_runtime_probe_status=blocked_existing_linuxcnc_runtime` and
`millturn_user_m_missing_requirements=exclusive_linuxcnc_runtime` instead of
terminating or taking over that process graph. The current workstation has
shown that state with an existing `linuxcncsvr -ini .../axis.ini` and
`rtapi_app load tpmod`.

The artifact keeps `execution_enabled=0` and `promotion_allowed=0`. It is not
a standalone Tcl/HAL executor and does not make `millturn` a Node/browser
representative.

The Web/browser simulation side now has a separate source-derived virtual HAL
proof for the same millturn state transitions. `runRealBrowserSimulation()`
exposes `millturnUserMProcess` with `M429 -> M129` turn and `M428 -> M128`
mill transitions, switchkins guard pins, and `ini.[xz].*` limit pin values.
Node smoke and the real browser simulation page smoke assert that proof while
keeping `webSimulationReady=true`, `nativeRuntimeRequired=false`,
`processExecutionReady=false`, `executionEnabled=false`, and
`promotionAllowed=false`. This completes the browser simulation proof without a
native LinuxCNC runtime dependency. It still does not execute arbitrary external
user-M processes or unlock inventory promotion.

`linuxcnc_millturn_user_m_boundary_probe` is the current native guard for this
evidence. It reads the LinuxCNC source `millturn.ini`, `mcodes/M128`,
`mcodes/M129`, and the `428remap`/`429remap` callers, then verifies the
source-derived guard pins, `M428`/`M429` switchkins transition fields, and
`ini.[xyz].*` target values recorded in the machine-readable tables. This is a
source/state-target and source-transition proof only: it does not execute Tcl,
start HAL, spawn the external user-M process, or permit promotion.

### Candidate Boundary

A valid future boundary would have to be LinuxCNC-owned and state based:

1. Reuse LinuxCNC task user-M search and registration behavior for discovering
   `M128` and `M129`.
2. Reuse a LinuxCNC-owned HAL/INI state boundary for the `ini.x.*`,
   `ini.y.*`, `ini.z.*`, `kinstype.is-*`, and `motion.switchkins-type` pins.
3. Execute or faithfully host the config-owned side-effect source without
   translating it into JavaScript CNC semantics. If the Tcl scripts cannot be
   executed in the target layer, the boundary must be narrowed to a documented
   LinuxCNC-owned state transition with source-traceable inputs and outputs.
4. Keep browser execution blocked unless the same state transition can be
   proven without spawning arbitrary host processes.

### Required Proof Before Promotion

Native proof:

- The existing `linuxcnc_millturn_user_m_boundary_probe` source/state guard
  must continue to prove that the pending M128/M129 state targets come from
  LinuxCNC config files rather than project-owned behavior.
- A LinuxCNC or standalone-native probe runs the `M428 -> M129 -> M429 -> M128`
  relevant switch path and records the `ini.[xyz].min_limit`,
  `ini.[xyz].max_limit`, `ini.[xyz].min_velocity`, and
  `ini.[xyz].max_acceleration` pin values before and after each user-M call.
- The same probe records the kinstype guard result and the active G5x offset.

Node WASM proof:

- The SDK stages the same INI, remap, and script assets for dependency
  accounting.
- The WASM runtime proves the same state output through a LinuxCNC-owned
  boundary. A `USER_M_COMMAND` event alone is not sufficient.

Browser proof:

- The browser smoke calls the already validated SDK/WASM boundary.
- The test labels the row as a millturn process-boundary representative only
  after the state proof exists. It must not claim full LinuxCNC HAL/task/UI
  process coverage.

## Tool Database Boundary

### Completed Proof

`axis/db_demo/base.ngc` was the `L4-TOOL-DB` row because
`db_nonran.ini` declares:

```text
[EMCIO]
RANDOM_TOOLCHANGER = 0
DB_PROGRAM = ./db_nonran.py
```

The INI explicitly notes that `TOOL_TABLE` is not used with `DB_PROGRAM`.
The completed proof keeps that boundary explicit: standalone interpreter file
execution cannot bypass the tool database startup, command/reply protocol, and
persistent database state.

### LinuxCNC Owner Set

- `configs/sim/axis/db_demo/db_nonran.ini` owns the DB program declaration.
- `configs/sim/axis/db_demo/db.py` owns the demo database behavior.
- `src/emc/task/taskclass.cc` owns reading `[EMCIO]DB_PROGRAM`, enabling DB
  mode, calling `tooldata_db_init()`, loading tooldata, and notifying DB state
  changes during tool load/unload paths.
- `src/emc/tooldata/tooldata_db.cc` owns child process startup, pipe setup,
  version handshake, `g` get-all requests, and `l`/`u`/`p` notifications.
- `src/emc/tooldata/tooldata_common.cc` owns common tooldata storage and DB
  refresh behavior.

### Native Behavior To Preserve

`tooldata_db_init()` splits `DB_PROGRAM` into argv, verifies that the program is
executable, forks it, connects stdin/stdout pipes, and waits for the version
reply `v2.1`. `tooldata_db_getall()` sends `g`, resets local tooldata, reads
tool lines until `FINI`, and calls `tooldata_read_entry()` for each line.

`tooldata_db_notify()` sends:

- `l ...` for `SPINDLE_LOAD`;
- `u ...` for `SPINDLE_UNLOAD`;
- `p ...` for `TOOL_OFFSET`.

The demo `db.py` uses LinuxCNC's `tooldb` module with callbacks for:

- `user_get_tool`;
- `user_put_tool`;
- `user_load_spindle_nonran_tc` or `user_load_spindle_ran_tc`;
- `user_unload_spindle_nonran_tc` or `user_unload_spindle_ran_tc`.

It maintains a persistent flat-file database, updates tool usage minutes, and
can call `linuxcnc.command().load_tool_table` to synchronize changes back to
LinuxCNC. Those details are DB process behavior, not interpreter file
execution behavior.

### Boundary Decision

This row is no longer blocked as `L4-TOOL-DB`. It can be inventoried as a Node
PASS only after the LinuxCNC-owned DB process protocol proof passes across
native, SDK/WASM, OPFS persistence, and browser smoke evidence. A standalone
adapter that merely loads a fallback `.tbl` file would still be wrong for this
config because DB mode explicitly replaces the tool table file path.

### Current Machine-Readable Artifact

`tool-db-process-boundary-summary.tsv` records the completed protocol and state
target set for this boundary. It records `DB_PROGRAM =
./db_nonran.py`, the LinuxCNC tooldata protocol messages `v2.1`, `g`, `l`, `u`,
and `p`, the demo DB callbacks `user_get_tool`, `user_put_tool`,
`user_load_spindle_nonran_tc`, and `user_unload_spindle_nonran_tc`, and the
nonrandom database state targets such as `T10..T19`, `/tmp/db_nonran_file`,
`tno+100` startup pockets, and pocket-0 spindle load/unload behavior.
`tool-db-process-protocol-gates.tsv` is the normalized companion table for
that evidence. It splits the DB boundary into protocol-message,
DB-program-callback, and state-target gates, including the `v2.1` startup
reply, `g` get-all through `FINI`, `l`/`u`/`p` notifications, demo callback
registration, ignored `TOOL_TABLE`, startup tools, nonrandom pocket mapping,
and persistence/sync targets.
`tool-db-process-transaction-plan.tsv` records the next non-executing contract
for this boundary. It orders the pending DB protocol into startup handshake,
initial get-all, spindle load notify, tool offset notify, and spindle unload
notify steps. Each step binds one LinuxCNC protocol message to the expected
`db.py` callback, required native/Node/browser proof, and source-traceable
state targets. This is still a transaction contract only; it does not start
`DB_PROGRAM`, run Python, mutate `/tmp/db_nonran_file`, fall back to a tool
table, or permit standalone/browser promotion.
`tool-db-process-native-protocol-alignment.tsv` aligns those generated gates
with the native source probe stdout keys, such as `tool_db_v2_1_handshake`,
`tool_db_getall_g_until_fini`, `tool_db_notify_l_u_p_protocol`, and
`tool_db_program_nonran_state_targets`. This table proves the generated gates
still match LinuxCNC-owned task/tooldata/config evidence.
`tool-db-process-native-runtime-readiness.tsv` records whether the host has
the runtime pieces needed to attempt a DB process protocol probe. It checks
`python3`, `linuxcnc`, `milltask`, `halcmd`, the configured
`axis/db_demo/db_nonran.py` program, and the LinuxCNC Python `linuxcnc.so` and
`tooldb.py` modules. It records PATH/source evidence where available and keeps
the DB runtime requirements that must be present before native protocol
evidence is accepted.
`tests/native/probe_tool_db_runtime.sh` is wired into `build_native_probes.sh`
as `linuxcnc_tool_db_runtime_probe`. On hosts without the required DB runtime
commands it exits successfully with `tool_db_runtime_probe_status =
skipped_missing_host_runtime`; on a ready host it remains disabled by default.
If explicitly enabled with `ENABLE_TOOL_DB_RUNTIME_PROBE=1`, it starts the
vendored `DB_PROGRAM`, drives the LinuxCNC `tooldb.py` `v2.1`/`g`/`p`/`l`/`u`
protocol over stdin/stdout, verifies nonrandom `T10..T19` startup state, tool
update, spindle load/unload, and flat-file persistence, then reports
`runtime_protocol_probe_passed`.

`wasm-port/tests/host/verify_tool_db_process_proof.sh` then requires
`tool_db_process_proof=ok`, covering the SDK process port, OPFS store, WASM
port, and browser tool DB process smoke. The unlocked inventory row therefore
uses the LinuxCNC-owned `DB_PROGRAM` proof chain; it does not replace
`DB_PROGRAM` with a fallback `.tbl`, and does not replace `DB_PROGRAM`.

`linuxcnc_tool_db_boundary_probe` is the current native guard for this
evidence. It reads the LinuxCNC source `db_nonran.ini`, `db.py`,
`src/emc/task/taskclass.cc`, and `src/emc/tooldata/tooldata_db.cc`, then
verifies the DB mode owner path, child-process protocol, `v2.1` startup
handshake, `g`/`FINI` get-all path, `l`/`u`/`p` notifications, demo DB
callbacks, and nonrandom state targets. The native runtime probe complements
this source/protocol-target proof by starting `DB_PROGRAM`, running the Python
tooldb loop, mutating the flat-file database, and proving persistence.

### Candidate Boundary

A valid future boundary should be a narrow tool-database host adapter:

1. Reuse `tooldata_db.cc` and `tooldata_common.cc` for DB mode behavior.
2. Isolate the process-spawn edge behind a host abstraction so native can spawn
   the configured DB program, while WASM/browser use an explicitly designed
   equivalent only if it preserves the LinuxCNC protocol.
3. Preserve the `v2.1`, `g`, `l`, `u`, and `p` command/reply protocol rather
   than parsing or inventing tool semantics in JavaScript.
4. Treat `db.py` as a config-owned process dependency. If it is not executable
   in a target layer, that layer remains blocked.

### Required Proof Before Promotion

Native proof:

- The existing `linuxcnc_tool_db_boundary_probe` source/protocol guard must
  continue to prove that the pending DB gates come from LinuxCNC task/tooldata
  and demo DB sources rather than project-owned behavior.
- A probe starts `db_nonran.py` through the LinuxCNC DB path and verifies the
  `v2.1` handshake.
- A get-all request returns the expected nonrandom startup tools.
- A load/unload or update path changes DB state through `l`, `u`, or `p` and
  is reflected by a subsequent get-all.

Node WASM proof:

- The same protocol is visible through the SDK boundary.
- Tool lookup/update behavior matches the native proof without staging a fake
  `.tbl` replacement.

Browser proof:

- Browser validation calls the Node-proven SDK/WASM boundary.
- OPFS may store DB files only as host persistence. It must not implement DB
  command semantics.

## Python-Remap Inventory Boundary

Python-remap rows remain inventory-only. The current
`blocked-dependency-summary.tsv` records Python modules, remap/prolog/epilog
functions, NGC-only subpaths, and HAL/UI/HALUI declarations.
`python-remap-boundary-summary.tsv` preserves the same evidence per blocked
path and records LinuxCNC Python runtime owner evidence from
`src/emc/rs274ngc/interp_python.cc` and
`src/emc/pythonplugin/python_plugin.cc`. `python-remap-family-summary.tsv`
aggregates it by runtime family so mixed Python/NGC-only subpaths remain
visible without promoting execution. No Python-remap row should be promoted
until a separate LinuxCNC-owned Python runtime boundary exists and has native
plus Node/browser proof appropriate to the target layer.
`python-remap-runtime-gates.tsv` expands each blocked path into Python module,
remap/prolog/epilog callable, NGC-only subpath, process-assumption, and
runtime-owner gates. `python-remap-native-runtime-alignment.tsv` aligns those
generated gates with the current native source probe stdout. Runtime owner
gates map to exact LinuxCNC runtime proof keys such as
`python_runtime_pycall_dispatch` and `python_plugin_callable_invoke`; dependency
inventory gates map to representative family inventory proof or the aggregate
`python_remap_native_source_inventory_proof`. Both tables remain
`proof_status=pending`, `execution_enabled=0`, and `promotion_allowed=0`.
`python-remap-runtime-contract.tsv` records the next non-executing family-level
contract. It keeps one row per blocked Python-remap family, records the
LinuxCNC-owned Python runtime phases (`initialize_python`,
`apply_ini_python_path`, `execute_toplevel`, callable lookup/invoke,
remap-phase dispatch, generator finish, execute-string/file, and reload),
aggregates Python modules/callables/NGC-only subpaths, carries HAL/UI/HALUI
process assumptions, and binds each family to native, Node, and browser proof
requirements. It is a runtime contract only: it does not initialize Python,
import modules, execute callbacks, or permit promotion.
`python-remap-native-runtime-readiness.tsv` records the current host/source
readiness for future native Python-remap runtime probes. It checks `python3`,
`linuxcnc`, the LinuxCNC interpreter/plugin owner source files, and each
configured Python module by blocked runtime family. The artifact remains a
gate only: every row stays `proof_status=pending`, `execution_enabled=0`, and
`promotion_allowed=0`.
`python-remap-native-runtime-state-plan.tsv` records the non-executing runtime
state plan for those future probes. It binds each blocked Python-remap family
to the required LinuxCNC Python phases, configured modules, callables,
NGC-only subpaths, process assumptions, readiness counts, source-alignment
artifacts, and future native proof targets. It does not initialize Python,
import modules, execute callbacks, or permit promotion.
`python-remap-native-runtime-fixture-plan.tsv` selects the first native runtime
fixture target, `axis/remap/stop-lookahead/nc_files`. That family is the
smallest current Python runtime lifecycle candidate because it needs the
LinuxCNC Python initialization/path/toplevel/runtime phases and configured
modules but avoids Python callable and NGC-only subpath complexity. The
fixture plan is still non-executing: it records the proof target only and
keeps `proof_status=pending`, `execution_enabled=0`, and
`promotion_allowed=0`.
`python-remap-bulk-promotion-plan.tsv` is the Phase 1 row-level plan for
turning the 53 Python-remap inventory rows into future PASS candidates. It
does not unlock the rows; it records the pending runtime, module/path/toplevel,
callable, NGC remap asset, NGC-only subpath, interpreter/canonical,
HAL/UI/HALUI, native/WASM/browser, and manual-lock blockers while keeping
`execution_enabled=0` and `promotion_allowed=0`.
`python-remap-row-runtime-proof.tsv` is the Phase 2 row-runtime proof table.
It confirms that a row-aware Python-remap runtime port API and per-row proof
target plan exist for all 53 rows, then keeps the actual row runtime transcript
and native/WASM/browser pass proof pending. It is not an inventory promotion
gate and keeps `execution_enabled=0`.
`python-remap-wasm-node-row-proof.tsv` is the Phase 4 WASM Node row proof
table. It is generated outside the inventory gate by the WASM runtime-port
test, consumes the native-ready row proof table path by path, and records
`wasm_node_pass_ready=1` only for validated per-row Node bridge transcripts.
It still leaves browser proof, execution, promotion, and the manual lock closed.
`python-remap-browser-row-proof.tsv` is the Phase 5 browser row proof table.
It is generated by the browser runtime smoke, consumes the Phase 4 WASM Node
row proof table path by path, and records `browser_pass_ready=1` only for
validated per-row browser worker transcripts. It still leaves execution,
promotion, and the manual lock closed.
`tests/native/probe_python_remap_runtime.sh` is wired into
`build_native_probes.sh` as `linuxcnc_python_remap_runtime_probe`. It records
the stop-lookahead fixture identity, configured Python modules, required
LinuxCNC Python runtime phases, host command readiness, and source/module
availability. On hosts without `linuxcnc`, it exits successfully but reports
`python_remap_runtime_probe_status=skipped_missing_host_runtime`; on hosts with
the runtime available it remains disabled by default. If explicitly enabled
with `ENABLE_PYTHON_REMAP_RUNTIME_PROBE=1`, it follows the `demo.ini`
`[PYTHON]` path/toplevel declarations, imports the vendored stop-lookahead
modules, verifies `queuebuster` callable lookup, confirms the callable returns
a generator, and checks that the first yield is the LinuxCNC
`INTERP_EXECUTE_FINISH` value from `interp_return.hh` before reporting
`runtime_lifecycle_probe_passed`.

`linuxcnc_python_remap_boundary_probe` is the current native guard for this
inventory. It reads the LinuxCNC Python runtime owners and representative
config families (`axis/laser`, `axis/remap/cycle`, TWP nutating, and
`gmoccapy` stdglue), then verifies the runtime dispatch/phase/callable owner
evidence plus representative Python modules, remap callables, prolog/epilog
callables, and Python path declarations. This is source inventory only: it
does not initialize Python, import modules, execute remap callbacks, or permit
promotion.

## Next Boundary Worklist

`next-boundary-worklist.tsv` is the machine-readable handoff for the next
runtime-boundary design phase. It is a planning artifact only: every row keeps
`execution_enabled=0` and `promotion_allowed=0`, records the LinuxCNC owner set,
records runtime owner evidence, records required native, Node, and browser
proof, and names the next boundary-design action before promotion.

`boundary-proof-gates.tsv` is the machine-readable proof checklist derived from
that worklist. It expands every target into native, Node, and browser proof
rows and keeps each row at `proof_status=pending`, `execution_enabled=0`, and
`promotion_allowed=0`. It must fail validation if a future edit tries to
promote a target without first replacing the pending gate with LinuxCNC-owned
proof for that layer. For the current blockers, event-only `USER_M_COMMAND`
coverage is insufficient for `millturn`, `.tbl` fallback coverage is
insufficient for `db_demo`, and JavaScript-owned behavior is insufficient for
Python runtime families.

`native-proof-alignment-summary.tsv` records whether the native source proof
summary, when present, is consumed by generated worklist and native proof-gate
rows. It currently aligns the `millturn` user-M source-state proof, `db_demo`
tool database protocol source proof, and Python runtime source-inventory proof
without enabling execution or promotion.
`runtime-boundary-native-alignment-summary.tsv` is the aggregate guard for the
detailed native alignment artifacts. It requires every user-M, tool DB, and
Python alignment row to have native stdout evidence, `alignment_ok=1`,
`proof_status=pending`, `execution_enabled=0`, and `promotion_allowed=0`.
`build/native/native-runtime-probe-summary.tsv` is the native companion for the
disabled runtime probe entry points. It summarizes the current runtime
readiness for `millturn` user-M, `db_demo` tool DB, and the Python
stop-lookahead fixture, records the missing host runtime requirements, points
back to each probe stdout log, and keeps every row at `execution_enabled=0` and
`promotion_allowed=0`.
`runtime-boundary-contract-summary.tsv` is the aggregate guard for the
non-executing runtime contracts. It ties the `millturn` user-M transition
contract, `db_demo` tool DB transaction contract, and Python-remap family
runtime contract to their native-alignment artifacts, and requires every
contract row to remain pending with execution and promotion disabled.
`blocked-runtime-promotion-lock.tsv` is the final machine-readable lock for
this phase. It combines the worklist, native/Node/browser proof gates, and
runtime alignment summary so every blocked target has `lock_active=1` until a
LinuxCNC-owned runtime boundary replaces the pending gates.

## Host Preflight Runbook

The blocked runtime probes are manual opt-in probes. They must not be run just
because the probe script exists. A future host must first pass the generated
preflight and dispatch checks for the specific blocked family.

Before attempting any opt-in probe, inspect:

```bash
wasm-port/tests/wasm/node/verify_sim_configs_inventory_wasm.sh
cat wasm-port/build/wasm/sim-configs-inventory/runtime-boundary-host-preflight.tsv
cat wasm-port/build/wasm/sim-configs-inventory/runtime-boundary-family-host-readiness.tsv
cat wasm-port/build/wasm/sim-configs-inventory/runtime-boundary-host-readiness-rollup.tsv
cat wasm-port/build/wasm/sim-configs-inventory/runtime-boundary-opt-in-probe-dispatch-plan.tsv
cat wasm-port/build/wasm/sim-configs-inventory/runtime-boundary-opt-in-probe-dispatch-rollup.tsv
cat wasm-port/build/wasm/sim-configs-inventory/native-runtime-probe-execution-plan.tsv
cat wasm-port/build/wasm/sim-configs-inventory/runtime-boundary-native-evidence-acceptance-gate.tsv
cat wasm-port/build/wasm/sim-configs-inventory/runtime-boundary-promotion-blockers.tsv
```

The current host is ready for manual blocked-runtime opt-in probes. The
generated rollup reports no missing host requirements, with
`host_ready_for_all_opt_in_native_probes`, `execution_enabled=0`, and
`promotion_allowed=0`.

The opt-in commands remain manual proof gates; dispatch rows may have
`dispatch_allowed=1`, but that does not enable execution or promotion:

```bash
ENABLE_MILLTURN_USER_M_RUNTIME_PROBE=1 bash wasm-port/tests/native/probe_millturn_user_m_runtime.sh
ENABLE_TOOL_DB_RUNTIME_PROBE=1 bash wasm-port/tests/native/probe_tool_db_runtime.sh
ENABLE_PYTHON_REMAP_RUNTIME_PROBE=1 bash wasm-port/tests/native/probe_python_remap_runtime.sh
```

A probe may be attempted only when all of these are true for that family:

- the corresponding runtime probe gate reports `runtime_ready=1`;
- `runtime-boundary-family-host-readiness.tsv` reports the family ready;
- `runtime-boundary-opt-in-probe-dispatch-plan.tsv` reports
  `dispatch_allowed=1`;
- `runtime-boundary-opt-in-probe-dispatch-rollup.tsv` does not block that
  command;
- the probe is run manually with its explicit `ENABLE_*_RUNTIME_PROBE=1`
  environment variable.

Passing a native opt-in probe is not promotion. After a native pass, the row
must still satisfy:

- `native-runtime-probe-pass-evidence-contract.tsv`;
- `runtime-probe-gate-alignment.tsv`;
- `runtime-boundary-promotion-readiness.tsv`;
- `runtime-boundary-post-native-pass-gates.tsv`;
- `runtime-boundary-native-evidence-acceptance-gate.tsv`;
- `runtime-boundary-promotion-blockers.tsv`;
- Node inventory proof;
- browser smoke proof where applicable;
- manual update of `blocked-runtime-promotion-lock.tsv`;
- documentation updates in this file, `compatibility-validation.md`, and
  `sim-configs-coverage-matrix.md`.

While the skip/evidence artifacts report
`skip_valid_until_host_requirements_available` and
`no_native_pass_evidence_accepted_while_host_blocked`, skipped probes provide
no native pass evidence. They only prove that the current host is correctly
blocked.

`native-runtime-probe-execution-plan.tsv` and
`next-boundary-recommendations.tsv` are planning handoffs, not permission to
run probes. They name the next recommended boundary work and exact opt-in
commands, but the host preflight and dispatch rows still decide whether those
commands are allowed on the current machine.

The current designed-but-disabled full-process block is:

1. `external_user_m_process` for `axis/vismach/millturn/example.ngc`;

Python runtime family rows follow as inventory-only targets. They must remain
behind a LinuxCNC-owned Python runtime boundary and must not be used to vendor
or execute `gmoccapy`, `axis/laser`, TWP nutating, or other Python-remap
families by path alone.

## Current Validation

These commands must continue to pass after any change to this document or to
the inventory code:

```bash
wasm-port/tests/wasm/node/verify_sim_configs_wasm.sh
wasm-port/tests/wasm/node/verify_sim_configs_inventory_wasm.sh
wasm-port/tests/browser/verify_interp_browser.sh
wasm-port/tests/host/verify_host_smokes.sh
wasm-port/tools/verify_vendor_sync.sh
wasm-port/tools/verify_no_standalone_cnc_semantics.sh
```