按text25.txt规划,实现L4-PYTHON-REMAP接入数控系统仿真系统

结论:已接入Python remap runtime proof chain,覆盖native、WASM、browser与release gate证据链;继续保持promotion_allowed=0,不批量解锁L4-PYTHON-REMAP。
This commit is contained in:
2026-06-19 18:52:24 +08:00
parent 51ae5d9a9a
commit fbf9dade9c
38 changed files with 2252 additions and 335 deletions

View File

@@ -214,9 +214,10 @@ Browser proof:
## Tool Database Boundary
### Current Block
### Completed Proof
`axis/db_demo/base.ngc` is blocked because `db_nonran.ini` declares:
`axis/db_demo/base.ngc` was the `L4-TOOL-DB` row because
`db_nonran.ini` declares:
```text
[EMCIO]
@@ -225,8 +226,9 @@ DB_PROGRAM = ./db_nonran.py
```
The INI explicitly notes that `TOOL_TABLE` is not used with `DB_PROGRAM`.
Standalone interpreter file execution would therefore bypass the tool database
startup, command/reply protocol, and persistent database state.
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
@@ -267,26 +269,27 @@ execution behavior.
### Boundary Decision
This row remains `L4-TOOL-DB`. A standalone adapter that merely loads a
fallback `.tbl` file would be wrong for this config because DB mode explicitly
replaces the tool table file path.
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 current designed-but-blocked
protocol and state target set for this boundary. It records `DB_PROGRAM =
`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 blocked DB boundary into pending protocol-message,
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. The current table keeps `proof_status=pending`,
`execution_enabled=0`, and `promotion_allowed=0`.
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
@@ -299,15 +302,14 @@ table, or permit standalone/browser promotion.
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, but it also remains
`proof_status=pending`, `execution_enabled=0`, and `promotion_allowed=0`.
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 boundary blocked with `proof_status=pending`, `execution_enabled=0`,
and `promotion_allowed=0`.
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 =
@@ -318,19 +320,20 @@ 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`.
The artifact keeps `execution_enabled=0` and `promotion_allowed=0`. It is not
a standalone tool database executor, does not replace `DB_PROGRAM` with a
fallback `.tbl`, and does not make `axis/db_demo/base.ngc` a Node/browser
representative.
`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. This is a source/protocol-target proof
only: it does not start `DB_PROGRAM`, run the Python tooldb loop, mutate the
flat-file database, or permit promotion.
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
@@ -559,11 +562,9 @@ 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 first two priorities are the current designed-but-disabled full-process
blocks:
The current designed-but-disabled full-process block is:
1. `external_user_m_process` for `axis/vismach/millturn/example.ngc`;
2. `tool_database_process` for `axis/db_demo/base.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