NODEDC_MISSION_CORE/docs/audits/2026-09-19-live-stationary-integration.md

# Stationary bootstrap in the existing LAB planning profile

The owner approved extending the scanner's existing preparation sequence with
reference alignment, then testing it by hand. The LAB planner remains the entry:
new named project → saved reference and section → new scanner pass or recorded
pass. This increment changes the new scanner pass. Recorded comparison retains
its existing algorithm and opening an archived result does not recalculate it.

## Runtime and presentation

`PlanningLiveTests` now delegates live ingestion to `stationary_live.py`, using
the already qualified `stationary-fresh-bootstrap/v1` state machine. The initial
ten seconds start at the first usable cloud with a recent matching pose, not at
session opening or during hardware calibration. Original session/generation,
receipt times, continuity and exclusive derived-consumer ownership are retained.
The numerical policy, thresholds, single prior trial and no-fallback rule are
unchanged. Capture and physical START/STOP remain owned by the K1 plugin.

The provisional initialization is stored separately from current results. It
does not publish a tracking transform or green points. Three consistent fits on
disjoint, fresh receipt windows are required. Cancellation, source end/change,
gap, stale input, failed or expired fitting removes live authority. Numerical
work is bounded, serialized and joined before the exclusive lease is released.

The shared plugin SDK accepts optional session-bound presentation through
`SpatialActivityPresentation`. `SpatialWorkspace` passes it into the existing
device controls. K1 shows it only while acquiring authoritative data for that
exact capture session; calibration, stopping, recovery and cleanup take priority.
The existing `K1SpatialSession` and canonical activity indicator present:

1. Hardware calibration, unchanged.
2. «Накопление данных» — stationary input collection.
3. «Привязка к эталону» — bounded initial search.
4. «Подтверждение привязки» — new observations and temporal checks.
5. «Сопровождение» — three current consistent fits; the operator may begin the
   diagnostic walk.
6. «Привязка потеряна» / completed / error — no readiness claim.

The presentation no longer promotes one geometric candidate to success. Stale
tracking also removes the old invitation to begin walking. Camera ownership,
scene toolbar, device buttons, layout and saved-project selection remain in the
shared spatial workspace. The planner inspector and connection window both
explain waiting at the selected entry until «Сопровождение».

## Integrated archive qualification

Private evidence: `data_dir/missions/causal-replays/20260919-live-bootstrap-001`.
`scripts/check_planning_live_bootstrap.py` freezes protocol, exact source copies
and hashes before running the actual `PlanningLiveTests` service in isolated
storage. A read-only archive adapter supplies B at its original 1× receipt
intervals, rebased to the current monotonic clock; original receipt clocks and
epoch timestamps remain in evidence. No HTTP source replacement, synthetic
device authority, new capture, hardware commands or second server is involved.

Fixed A is the predecessor's forward 39.926109 m / 52,965 point reference; B is
the independent saved pass. Prior fitted B transforms or future B headings are
not supplied. The original 9.972693 s / 10.406525 m receipt gap is retained.

Run `a30fc78f-6d41-4272-9ebd-5da8528feb02`:

- 2026-09-19 13:04:41.226–13:05:44.543 UTC; replay monotonic origin
  `840758859762625`. 974 delivered events, maximum delivery delay 0.164782 s.
- Initial search starts after ten seconds. Provisional seed at 31.486786 s;
  worker wall 21.464897 s. Its 21.802489 s old input is never accepted as live.
- Six fresh fits; the third establishes tracking at 44.613764 s.
  Fresh worker wall 0.202423–0.329659 s; accepted source ages 0.241667–1.530939 s.
  All fit receipt IDs are disjoint and strictly after their fresh-window floors.
- The real live-scene method exports a valid RRD while tracking. At the distance
  bound, state is completed/lost and accepted live geometry is cleared. The
  periodic UI distance field last published 39.232500 m; the terminal pose crosses
  the 40 m bound. That field is not a higher-frequency trajectory measurement.
- Initialization is only a prior; input/code hashes, cleanup, temporal admission
  and every one of the 72 sealed evidence files pass verification.

SHA-256:

- manifest: `114e823dced5d5f6b2075706b8fc12c1b2fff29969be1d2d290397da52d9b1d1`
- summary: `359f2285290215d14fe08c6e813c0f9b995db6d56d117f26acd7663c396013c2`
- seal: `d0f2485680f0d593e2b5662c2be7d0f51ff8fbc5c808870ad29a6efa9c201bc8`

This qualification does not replace the predecessor's wrong-region controls.
The algorithm is unchanged and its existing negative/unit cases remain tested.
The archived B moved while its initialization was running. A physical scanner
held stationary until full confirmation is the next experiment, not a proved
result. Startup time is one measurement, not a fixed countdown. Geometric
agreement is not an independent measurement of navigation accuracy.

## Validation and operator acceptance

58 focused backend tests passed in 4.14 s: live orchestration, stationary prior,
recovery, causal replay, entry acquisition, project archive and registration.
New orchestration tests cover a long hardware-calibration period before the
first cloud, continued input during search, separate prior/current results,
three fresh confirmations, stale tracking, identity change and cancellation
during a worker. Existing Starlette/httpx deprecation warning remains.

Frontend architecture: 4 checks; full typecheck; 852 sequential unit tests;
production build. Added presentation coverage checks exact capture identity,
calibration/stop/cleanup precedence, no one-candidate success, stale instruction
removal, recorded/end-state isolation. No new visual primitive, color, CSS rule,
native control or page composition was introduced. Ruff on the three changed
Python implementation/qualification files and `git diff --check` pass.

In-app browser on canonical 8000: saved A/B result renders; normal and expanded
application panels retain the cloud; new project opens the existing inspector;
new/recorded pass selection changes the appropriate fields and disabled action;
Escape closes the inspector and resets its toolbar toggle. Live phase rendering
is covered by component tests, not claimed as a physical K1 browser test.
The application panel's expansion is toggled by its button; Escape acceptance
here refers to the inspector.

All tests, replay, builds and browser QA run sequentially on Darwin arm64. No
Docker VM or second backend is started. Before restart, K1 is idle, with no
active acquisition, and the old live study is terminal. The canonical LaunchAgent
is restarted to load the handler; backend PID changes from 60284 to 68323.
Port 8765 remains unused. Raw geometry and RRD evidence stay outside Git.

Next physical check: create a LAB project with A's first 30 m, select «Новый
проход», use a new K1 project name, start near that section's entry, keep the
scanner stationary through both hardware preparation and reference confirmation,
then walk 20–30 m slowly after «Сопровождение». Finish with the existing K1
device/recording stop control. If confirmation fails or tracking is lost, stop
the walk and retain the recording for diagnosis. Arbitrary starts, measured
position accuracy, actual onboard compute and autonomous motion remain unaccepted.