Files
NODEDC_MISSION_CORE/docs/audits/2026-09-07-k1-between-scans-r16.md
T

134 lines
7.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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:1720: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-256 `d5571c956f305ee658a9119d7afeecfb47c99a2aa9dffad37ad2ba9b5e25e592`; 71 regular payload files.
- `mission-core-xgrids-k1_0.1.13_amd64.deb`: 318115794 bytes; SHA-256 `0cb5826f6c452189c19d69291552492da56bb88b08715fddff8c31eb587a7429`; 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.