# 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.