NODEDC_MISSION_CORE/docs/audits/2026-09-19-stationary-entry-fix.md

Bounded initial-search repair and fresh confirmation

The owner requested a repair after the stationary physical start failed before tracking. The failed input and report remain immutable; see 2026-09-19-physical-start-diagnosis.md.

Changes

PreparedReference builds the invariant reference voxel cloud, covariances and search tree once per entry-search worker. Each hypothesis retains its original seed-dependent query voxelization and patch-centre correction calculation. Single registration still prepares its own target. No point budget, resolution, correspondence distance, overlap/RMSE threshold or correction bound was relaxed.

entry-multistart/v2 and stationary-entry/v2 visit central translations and nearby headings first, retaining stable seed identities and the complete set of 108 stationary hypotheses. All hypotheses, cluster support, multiple translation seeds and ambiguity checks remain mandatory; the deadline remains 25 seconds inside a 30-second isolated worker. An incomplete search still fails closed.

stationary-fresh-bootstrap/v2 accounts for an existing receipt gap straddling worker completion. Before the first fresh query cloud and before the single prior trial is consumed, at most one segment boundary relative to the initial prefix can begin the fresh window. The ready timestamp, ten-second prior lifetime and strict post-ready receipt fence do not move. A second boundary, any gap after a fresh query cloud or pending fit, expiry, stale result or loss of identity still invalidates the prior/tracking. Three disjoint, consistent fresh windows remain necessary for tracking.

This boundary was discovered by retaining a failed intermediate positive control: the faster worker finished just before the recorded ten-second gap ended. Treating that as loss of already established tracking was incorrect. The failed control remains in 20260919-entry-fix-positive-001.

The shared presentation now records whether tracking was ever established. An initial failure reads «Привязка не выполнена»; actual loss after tracking reads «Привязка потеряна». Incomplete initial search has specific operator copy. Fresh results and phase copy are committed atomically, removing a transient «Кандидат совмещения» detail during confirmation/tracking. No new control, layout, styling, navigation or device command was added.

Qualification

The extended check_planning_live_bootstrap.py and private ReceiptQueueArchiveSource run the actual PlanningLiveTests service against immutable raw captures at original 1x receipt intervals. Each probe has its own production LivePerceptionIngress and K1PlanningLiveSource; it never attaches to the live scanner or canonical backend. Original timestamps, rebased receipt mapping, source hashes, exact executed source and decision files are retained. The production RRD scene method runs every two seconds, matching UI polling. One numerical worker and one bounded probe run at a time.

Three final probes passed all source/code integrity, fresh-window disjointness, complete-search, authority-removal and lease-release checks:

Private evidence directory	Full search	First tracking	Fresh fits	Result
20260919-physical-fix-live-002	10.683 s	33.981 s	9	Last physical stationary capture, original reference and section
20260919-entry-fix-positive-002	18.153 s	44.034 s	6	Previous independent pass with its original receipt gap
20260919-entry-fix-negative-001	13.191 s	none	0	Wrong reference region, no admissible entry

Directories are under data_dir/missions/causal-replays. The physical replay ran 2026-09-19 14:03:47.770–14:04:52.857 UTC. All 108 hypotheses completed in each final probe. Physical-replay fresh fits took 0.252–0.412 seconds; accepted source ages were 0.269–0.648 seconds. Initial surface overlap was 96.770% and inlier RMSE 0.166 m, not independent localization accuracy.

LiDAR and pose overflow counts were zero in all three private queues. Maximum publisher delays were 0.0246, 0.0694 and 0.0625 seconds respectively. No browser video decoding, camera producer or concurrent physical recording was replayed; these checks do not prove absence of overflow under every live workload.

Verified seals contain 88, 73 and 42 files respectively. Summary SHA-256:

• Physical: 277da5a0fd3ed9579fb011503de0b28d2b75b17906bb47b53afd994064699306.
• Positive: 7848e43a2f396d640c8f8e05efa3432e91447552efa5f3743abc2808ceab690b.
• Negative: 24a48c089ea5287ecd47c3f7c17479cfd970e111c49775e2e20f8f984b8226f7.

65 focused backend tests passed, including target-reuse equivalence/isolation, known-transform recovery, complete seed coverage, partial/ambiguous rejection, fresh receipts, gaps, expiry, identity changes and cancellation. The strengthened 16-test stationary subset passed again after refining the gap test.

Frontend acceptance passed sequentially: four architecture tests, full typecheck, all 853 frontend tests and the production build. The new bundle is app-CMB8f3eT.js. Ruff and git diff --check passed. Browser QA on the canonical 8000 endpoint reloaded that build and opened the existing saved A/B project; the inspector opened, expanded and closed with Escape, leaving the real cloud visible. New initial-failure versus actual-loss copy is covered by presentation tests; no new live scanner session was started for UI QA.

Runtime handoff

The frontend build is available on 8000, but the existing backend has not yet been restarted to load this numerical repair. A fresh /api/state still reports awaiting_external_stop, acquisition.stop.device_stopping and reconnecting for the preceding physical acquisition. Its recovery checkpoint remains active. The owner has been asked whether the scanner is off/stopped or still recording; that answer is pending. No device command, force-finish, checkpoint reset or backend interruption was performed. Keep the existing canonical service running, confirm the physical stop, then replace that same service and verify 8000 before inviting another walk. Code/replay qualification is not a claim that the running backend has already changed.

The owner subsequently confirmed twice that K1 had been switched off after the failed scan. The existing local-only force-finish action was attempted with exact acquisition/revision/runtime/generation fences. It failed before side effects with acquisition-force-finish-not-recovering: public recovery state was reconnecting/allowed, but its acquisition lineage was absent. Re-reading the same idempotency key returned that failed operation, not a new attempt. This separate recovery-presentation inconsistency is retained for follow-up.

The canonical LaunchAgent was then replaced: backend PID 68323 → 75869. Health is operational, port 8765 has no listener, and 8000 serves app-CMB8f3eT.js. The 29 implementation hashes in the final physical replay manifest match the current source. The new process is idle with no acquisition; the durable recovery checkpoint remains unchanged at active/revision 242 with no automatic restart authority. No checkpoint, raw input or command ledger was deleted or rewritten to manufacture a confirmed physical stop.

Browser preparation created «JA-SADOVAYA · повторная проверка старта», using JA-SADOVAYA-002 / 30.050 m and a new live pass. Run 82ff69a7-ac67-4658-8d98-cb5944101d4c is waiting, with query session absent, tracking false, stationary-entry/v2 and stationary-fresh-bootstrap/v2 returned by the actual 8000 API. The standard connection modal is left open, Quick Connect selected, at «Найти по Bluetooth». Selecting that mode completed the existing local connection reset. No discovery, provisioning, physical start or stop command was invoked. Previous physical-command uncertainty stays in its ledger for normal read-only verification when the scanner is reconnected.

Private before/after states, the local-close request and failed result, health and prepared-run evidence are under data_dir/missions/diagnostics/20260919-entry-fix-runtime-001. The only live planning owner is the deliberately prepared operator test, waiting for a new capture. Field acceptance remains pending.

Decision

The saved failure is repaired under the bounded archived scenarios. A new physical trial is still required; no navigation, vehicle control, arbitrary start or independent accuracy qualification is claimed. Use the same reference and section as the failed start, a new query project, and wait without movement through scanner preparation and reference confirmation until «Сопровождение». Then perform the agreed short hand-carried walk. Measured replay time is not a fixed readiness timer.