NODEDC_MISSION_CORE/docs/audits/2026-09-19-planning-runtime-boundaries.md

# Planning: startup ownership, mixed ingress and onboard dependency closure

Date: 2026-09-19. Ops: MISSIONCOR-81; related architecture: MISSIONCOR-76/79.

## Scope and source identity

Implemented after the owner's approval of the second source-review findings.
Checkout: `NODEDC_MISSION_CORE_m5_observatory`, branch `main`, HEAD `be58d58`.
The working tree already contained substantial uncommitted implementation;
unrelated changes were preserved. HEAD alone does not identify this patch.

No scanner command, new acquisition, vehicle command, network reconfiguration,
onboard installation, Docker workload or physical replay was performed.
The running canonical8000 process was not restarted for these source tests.

## Changes

- `src/k1link/missions/live_tests.py`: startup owns a rollback stack until the
  planning thread actually starts. A busy source, report error, thread creation
  error or thread-start error cannot strand the shared compute lock. A successfully
  opened derived consumer is closed on startup failure. The response is prepared
  before ownership transfer, so response serialization cannot release a live
  worker's resources. Failed starts remain terminal in memory; report persistence
  is best-effort during storage failure. Executor construction is now inside the
  worker's protected lifetime. Shutdown/consumer-close/report failures still pass
  through compute-lock release and clear accepted live geometry.
- `src/k1link/device_plugins/xgrids_k1/planning_live.py` and
  `src/k1link/sessions/live_planning.py`: one take returns one receipt. Auxiliary
  camera modalities become payload-free `kind="ignored"` events retaining their
  identity, sequence and receipt timestamps. None is reserved for no receipt.
  The stationary loop already skips non-geometric kinds, so it cannot interpret
  a camera receipt as a drained prefix queue. There is no internal draining loop
  that could delay cancellation or freshness checks under camera traffic.
- `plugins/xgrids-k1/packaging/runtime-files.json`: includes the newly required
  stdlib-only `sessions/live_planning.py` ABI module. No mission algorithm,
  local planning adapter or local LAB composition was added to the onboard payload.
- Tests: new `test_planning_failure_boundaries.py`, new
  `test_planning_recording_ingress.py`, and additional boundary assertions in
  `test_k1_installer.py`.

No search radius, point budget, GICP threshold, ambiguity gate, wall deadline,
fresh-window rule, camera codec/queue policy or device-authority fence was relaxed.

## Regression evidence

The initial ten-case failure suite had nine failing cases against the old code.
It now passes; two subsequent cases cover partial report replacement/recovery
and the shared recorded ingress, giving twelve new cases in total.

Checks include failed persist, Thread construction/start, source open, executor
construction, worker persistence and consumer close; resource release and retry;
terminal restoration after a partially committed report; both camera modalities;
and the ten-second stationary prefix with two seconds of processing backlog.
The backlog fixture uses the production adapter to produce the camera receipt
and the production stationary loop, with a fake clock and no native search.

The shared-ingress test uses real MQTT and camera writers, real facade generation
checks/observers, the same LivePerceptionIngress, the production decoder and a
PlanningLiveTests owner. It proves raw-first MQTT delivery, committed camera
fragments before derived delivery, preserved event order, rejection of old MQTT
producer/camera epochs, and continued append-only recording after planning cancel.
Producer admission is explicitly a fixture, not physical proof; camera box bytes
are synthetic and are not a video-quality acceptance.

The isolated onboard test copies only the declared runtime payload/resources,
imports NodeBridge outside the Core checkout, reads idle state and closes it.
It verifies the ABI is available and the local planning adapter/mission worker
are not imported. No .deb release or board installation was made.

## Validation

- 184 focused backend tests passed, 0 failures/errors/skips, 22.615 seconds.
  Suites: new boundary/shared-ingress tests, planning live, stationary bootstrap,
  causal replay, entry acquisition, mission registration, LaunchAgent,
  K1 installer excluding private-release build, camera gateway/archive and MQTT
  capture. XML: `/private/tmp/mission-core-source-review.TfGl1a/implementation-tests.xml`.
- Five additional acquisition-lifecycle tests passed: first authoritative cloud
  before camera activation, stale published cloud rejection, later-frame retry,
  STOP priority during initial camera startup, and session-clock sealing order.
- Ruff check/format passed for changed Python owners/tests; git diff --check passed.
- Canonical8000 remained operational, plugin runtime1/1. Read-only K1 state had
  no acquisition, idle camera with recording.active=false, no connection intent
  or control session. The existing Interactive LaunchAgent plan has identical
  current/desired SHA256 `5d7a58122c016f8021fede27d1b21891ee20238fc38c281e5b33574ff8204e3f`.
- Local tests ran sequentially. Memory-pressure readout was39% free; swap readout
  was4783.88MiB used, lower than the earlier4831.88MiB snapshot. No Docker workload
  was started; the existing privileged vmnetd helper is not a running Docker VM.

## Corrected source fingerprints (SHA256)

| File | SHA256 |
| --- | --- |
| `src/k1link/missions/live_tests.py` | `58d44e7d7f0582feb2cdfdd62ed72b6d86f772da25ea3eb7d4a1c196ab9bf6e6` |
| `src/k1link/device_plugins/xgrids_k1/planning_live.py` | `82c5cf912502604479d4e5329a5d20130e37e6243d3f20645a280dd01f598610` |
| `src/k1link/sessions/live_planning.py` | `c242d4e6b42e6e59b81deafb5edfd25d9e3f301cba7376d0fa196ec4b3189dd1` |
| `plugins/xgrids-k1/packaging/runtime-files.json` | `39770adc8cdb7ff26cc7780a47024baf528508e8f2624fc98fafb02a4ce375dc` |

## Decision and remaining acceptance

The three source-review defects are corrected and covered. This is not proof
that they caused physical005; its damaged H.264 and unresolved STOP evidence
remain unchanged. Existing scheduling evidence is separate from this patch.

The owner subsequently confirmed K1 was off and recording had ended. The controlled
reload and runtime acceptance below supersede the source-only handoff. This owner
confirmation does not fabricate a physical STOP receipt for the earlier005 run.

The tests cover the relevant boundaries compositionally. They do not replace a
single full acquisition/publisher/RTSP/browser-MSE acceptance or a physical start
with clean video, complete search and three fresh validation windows. A successful
synthetic cancellation does not constitute an authoritative physical STOP.

The accepted-entry policy remains5m, not a proven10m capture radius. Arbitrary
route-position relocalization, full chassis pose/mount calibration, route following,
new obstacles and vehicle control remain separate stages.

## Canonical8000 reload and bounded field-test handoff

Before reload: PID83156; K1 phase/source_mode idle, producer_generation0,
acquisition null, camera recording false and producer absent. The active planning
record remained the completed historical005 run
`47dc5323-5d2c-4743-a13f-b4f837cf9fea`; no calculation was in progress.

The versioned `scripts/manage_mission_core_launch_agent.py` applied the freshly
reviewed, SHA-gated plan for the same WorkingDirectory. Current and desired plist
hashes were identical (`5d7a58122c016f8021fede27d1b21891ee20238fc38c281e5b33574ff8204e3f`):
no configuration, environment, scheduling class or source directory changed.
The script retained its private plist backup and accepted health after reload.

New PID91643, runtime start `2026-09-19T17:38:39.562133Z`, runtime identity
`snapshot-runtime-c5019daa9e912b67c31aa28f49453dd2`. Health operational, plugin1/1,
one listener on8000 and none on8765. K1/camera remained idle with no recording.
The four corrected source fingerprints above still matched. This is a fresh
interpreter started from the verified corrected working tree, not a hot-patch claim.

Actual browser check: LAB → Планировщик opens the saved
«JA-SADOVAYA · проверка 30 м» result, renders the Rerun point clouds and inspector;
reference JA-SADOVAYA-001, historical query JA-SADOVAYA-002, reference length30.01m.
Opening it did not start capture, fitting or a new planning profile. The historical
result is not presented as fresh tracking. No UI/build changes were made.

The owner can now travel to the reference location for a **short controlled
physical verification**, not an accepted autonomous mission. Arm the new planning
profile only on arrival, close to the start of the selected reference segment;
do not promise10m acquisition or an arbitrary route-position start. Use a new
recording identity. First remain stationary until fresh tracking is established
and camera video is healthy. Only then make a short manually controlled pass.
If initialization stops, tracking is lost or video is corrupt, remain/stop on site,
finish recording through the normal controls and retain the evidence; do not wait
for an automatic second search or repeatedly restart capture. Full physical
camera/localization acceptance and authoritative stop/archive remain uncompleted.