SILVER/NODEDC_MISSION_CORE
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

feat(perception): keep worker shadow local

Browse Source
This commit is contained in:
DCCONSTRUCTIONS
2026-08-05 15:54:42 +03:00
parent 720487379c
commit 40794f13aa
5 changed files with 421 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/22_MILESTONE_4_OBJECT_CENTRIC_RECORDED_REALTIME_CV.md
+15 -4
View File
@@ -2,7 +2,7 @@
Date: 2026-08-05
Status: in progress; M4.0–M4.2 implemented, M4.3 execution seam ready/runtime gate open
Status: in progress; M4.0–M4.2 implemented, M4.3 local shadow artifact ready/runtime gate open
Audit base: `1b3e0b3` on `feat/simulation-polygon-s1`
@@ -727,9 +727,10 @@ runner:
This increment does **not** claim a new 4,489-frame Triton execution. The existing
E46J 47.840 FPS result remains the baseline evidence. A fresh provider execution
requires a digest-bound shadow package; ad-hoc executable staging on Worker 006
is prohibited by the deployment canon. Therefore M4.3 runtime/capacity exit and
its final checker remain open, and M4.4 does not start yet.
requires a digest-bound Mission Core shadow package with its own reviewed local
runner. NODEDC Platform, its repository, its deploy registry and server Docker
runtime are explicitly outside this boundary. Therefore M4.3 runtime/capacity
exit and its final checker remain open, and M4.4 does not start yet.
Validation after adding the execution seam: 42 focused-and-related tests and the
complete Python suite (`1230 passed, 1 skipped`). Scoped Ruff and strict mypy pass
@@ -739,6 +740,16 @@ Portable-worker hardening adds two architecture checks and leaves the complete
suite at `1232 passed, 1 skipped`; scoped Ruff and strict mypy remain clean. This
hardening changes no durable Worker 006 process and makes no fresh capacity claim.
The local shadow artifact now contains its own Mission Core PowerShell runner,
runtime wheel, baseline and descriptor. The runner verifies the artifact, all
eight pinned source/model files, dependency inventories, Worker/Triton identities
and free-space guard before creating a single one-shot candidate container. The
candidate reuses the existing Triton network namespace over loopback, exposes no
port, mounts source read-only, writes only immutable result evidence, and is
removed after success or failure. Durable E15 and Triton are re-verified after
the run. This is a Mission Core operator workflow, not a cross-repository deploy
workflow.
## Implementation order
The implementation sequence is intentionally strict: