DCCONSTRUCTIONS
e515ab1b8c
Preserve the completed teach-and-repeat laboratory stage: reference preparation, cascaded acquisition, local tracking and recovery, recording lifecycle, replay qualification, and persistent Rerun scene controls. Document the open grid-picking regression and Rerun upgrade contract. No autonomous driving or loop-closure optimization is claimed.
146 lines
8.7 KiB
Markdown
146 lines
8.7 KiB
Markdown
# 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.
|