7.9 KiB
K1 connection lifetime between recordings — R16
Observed behavior and cause
The owner reports two successful R15 connections and recordings, then a return to the device showing “Устройство остановлено” and requiring a separate connection check. R15 is Node 0.8.12 / K1 0.1.12. The services remained active with zero restarts through the reported 20:17–20:23 MSK interval. A later bounded Fleet read still showed the K1 acquisition idle, control phase completed, and online/verified false. This is current state, not proof of a historical Wi-Fi failure.
The implementation explains the transition deterministically: the interactive
control worker concluded the entire MQTT dialogue after correlated STOP and
fresh unbound READY, set completed, and closed its transport in finally.
The facade then reduced every completed control session to control loss. The
Node projection correctly withheld connection authority, but the UI further
hid that distinction by prioritizing “device stopped” over connectivity and
instructing the owner to check connection after every completed recording.
No service restart or actual Wi-Fi disconnect is needed to produce this path.
There is a real protocol constraint underneath the original single-scan implementation: MQTT operation keys and response-correlation ownership are one-shot within a dialogue. Reusing the old dialogue by clearing consumed keys would weaken replay/correlation protection. R16 does not reset these guards.
The bounded journal also records failures at 20:18:54 and 20:21:24 at the R15
Node adapter's Physical state requires explicit reconciliation check. That
check ran even immediately after the adapter's own admitted START, before its
pending physical edge had settled. R16 returns that owned starting/scanning
state without another dispatch; pre-existing ambiguous physical state still
blocks a new START.
Corrected lifetime
After confirmed STOP/READY, the completed recording is sealed by the existing acquisition lifecycle. The command worker retains its socket and services the existing subscriptions while idle. This wait sends no bootstrap, network configuration, START or STOP. Real socket failure, stale bound status, identity change and route/proof expiry keep their existing fail-closed checks.
A subsequent explicit named START releases the next workspace checkpoint. Only then does the owner retire the previous command socket and create a fresh canonical dialogue for the same bound device/network. It receives fresh DeviceInfo, enforces the identity/route and durable ledger checks, then follows the existing workspace/project/START stages. The control generation advances; old checkpoints cannot authorize the new cycle. BLE selection, GATT and Wi-Fi provisioning are not part of this path. No extra operator recovery action is needed for an uninterrupted connection. Actual loss retains the explicit verification/recovery path; no automatic network write or physical command retry was added.
The facade accepts completed control as live only when its socket is retained and the existing exact, fresh DeviceInfo/control proof satisfies the supervisor. Legacy completed/closed sockets remain disconnected. Explicit network changes may retire the retained idle socket through the existing local close boundary. Both direct and Node START orchestration accept this completed-but-connected checkpoint. Device inventory/detail badges now report connection; acquisition progress remains in the spatial session controls.
Presentation
- Canonical Design Guideline Field owns autofill styling. Browser autofill uses the existing field material, theme text/caret and keyboard focus indicator. No K1-only field override or new control was introduced. Registry, component documentation and the living catalog were updated.
- The shared spatial viewport uses one explicit rounded compositing clip and an isolated stacking context, including the native canvas/iframe and overlays. This addresses corner leakage without decorative strokes or changes to the scene grid, axes or camera resize handle. Confirmation against the owner's actual GPU-rendered screenshot remains part of visual acceptance.
Verification and delivery
Synthetic checks are not physical scanner acceptance. The final artifact and installation evidence are recorded below. No physical scanner command, BLE probe or credential extraction was performed from CLI. Existing onboard credentials and pre-install guards are retained. Builds run sequentially on the 18 GB Mac; Docker was not running. The canonical Core on port 8000 stays available.
Source checks: 167 control/protocol/Node/supervisor/coordinator tests; 22 selected acquisition lifecycle tests; 809 Control Station unit tests. Regressions cover retained idle connection, two explicit scans with distinct command dialogues, no idle commands/replay, stale CAS, completed connection versus actual loss, and admission of the owned pending START. Design Guideline production build and registry validation passed. Production Core build and packaging checks follow.
Full acquisition lifecycle regression then passed: 631 tests (includes the 22
focused tests above). Installer/package lifecycle: 14 passed. Core TypeScript
and production build passed (8.29 s). Ruff and whitespace checks passed.
Design Guideline pin: 26a1bf72a2a32b002e51f910e8faa300333bb6c3.
R16 package versions: Node 0.8.13 and K1 0.1.13.
Built and staged packages
Source commit: c6693d6f442e0d2bb4ea3c5710db7af44d41b667. Node production
build/typecheck passed. Both Debian archives were streamed and inspected:
regular files/directories only, no unsafe paths or private application key,
matching source provenance. All K1 per-file hashes matched its provenance;
application_material_included=false. Node provenance matches the pinned DG.
mission-core-node_0.8.13_amd64.deb: 109838014 bytes; SHA-256d5571c956f305ee658a9119d7afeecfb47c99a2aa9dffad37ad2ba9b5e25e592; 71 regular payload files.mission-core-xgrids-k1_0.1.13_amd64.deb: 318115794 bytes; SHA-2560cb5826f6c452189c19d69291552492da56bb88b08715fddff8c31eb587a7429; 150 regular payload files.
The immutable R16 directory is staged at
/home/dcsudo/Загрузки/NDC/mission-core-node-k1-20260907-r16/ on the authorized
Ubuntu board. Both remote checksums passed. Apt simulation upgrades exactly
Node 0.8.12 → 0.8.13 and K1 0.1.12 → 0.1.13, with zero additions/removals.
The existing safe-state pre-install guards remain unchanged. Fleet was online
with idle acquisition before staging; unrelated inventory entries were retained.
The owner entered sudo in the native “Mission Core · K1 R16” installer.
Post-install read-only verification confirms both packages are install ok installed: Node 0.8.13 and K1 0.1.13. The Node service entered active/running
at 21:22:04 MSK on 2026-09-07; K1 entered active/running at 21:22:13 MSK.
Both report NRestarts=0. The bounded warning-or-higher journal since 21:22:00
contains no entries. This verifies installed state independently of an installer
exit code, which the owner has not reported.
After installation, canonical Core health remains HTTP 200, ok=true; Fleet reports ndc-rover-006 online. Its K1 inventory projection is currently online=false, verified=false after the service restart. This is not physical connection acceptance. Clear Chrome cache and test through the normal UI: connect initially, named scan, STOP through confirmed completion, navigate away and return, then start another named scan without a separate recovery action. Also inspect autofill colors and the live scene corners. Physical and browser/GPU visual acceptance remain pending; no such acceptance is claimed from build/tests.
Final canonical Core health: HTTP 200, ok=true. Port 8000 remains on the original PID 88424 at the pre-install check; no backend on 8765. No Docker service or temporary application server was started. The installer was the only new owner-facing process.