NODEDC_MISSION_CORE/docs/audits/2026-09-07-k1-node-bridge-lab-checkpoint-r16.md

Mission Core → onboard Node → K1 Bridge: laboratory checkpoint R16

Decision and evidence boundary

On 2026-09-07, after installing R16, the owner confirms that the repeated normal workflow works in the current controlled laboratory setup. They additionally closed the browser tab, opened the same Mission Core address in a new tab and found K1 still connected. Through Mission Core, the owner can connect K1 to the onboard computer in Bridge mode, configure a named acquisition, start/observe and stop it, then return without the previous mandatory manual reconnection. Earlier owner runs in this conversation showed actual camera, point cloud and trajectory, as well as successful physical START and STOP.

Acceptance level: working laboratory scenario, broader robustness unproven. This is owner-reported physical/UI evidence, separate from automated regressions and package/service readback. No new agent-controlled physical experiment was performed, and no raw capture, secret, network credential or device identifier is included here. The exact count and duration of repeated scans were not measured. The general confirmation does not independently certify every visual detail.

The owner explicitly states that critical scenarios were not exercised. Do not mark the complete Mission Core/Node/K1 connection contour or Node architecture finished. Do not generalize this result to other networks, devices, firmware, Quick Connect, GNSS/RTK modes or autonomous mission operation. The next work assignment will come from the owner; the matrix below is an open gate, not an instruction to begin physical fault injection.

Architecture represented by this result

Operator intent travels from Control Station through Core Fleet and the paired Node broker to the isolated K1 plugin. Node remains responsible for local device access and recording; Core/browser provide operator control and viewing. Preview recovery does not own physical START/STOP or Wi-Fi provisioning. Enrollment, connectivity, acquisition, recording and preview are separate states. Direct K1 and onboard views consume shared product components while retaining their transport, profile and authority boundaries.

This checkpoint does not amend the frozen architecture baseline in MISSIONCOR-76. Implementation progress belongs in that card's comments; current integration details belong in MISSIONCOR-3, and the project summary in MISSIONCOR-2. The older direct-Mac acceptance remains distinct from this Linux onboard laboratory result.

Work consolidated from the conversation

Area	Implemented result and causal evidence
Linux installation and control authority	Separate Node/K1 packages, supplied runtime and services; systemd credential delivery accepted without exporting the existing encrypted credential into R12–R16 updates. Linux route contract and Node/plugin operation identity translation corrected in earlier stages. Installed R9 physically enabled START/STOP.
RRD transport, R10	SCTP fragmentation previously fed partial RRD fragments directly into the decoder. A bounded versioned envelope now reassembles complete native payloads before decoding; malformed, partial and oversized input is rejected. FFmpeg path and delayed camera producer admission corrected.
Idle preview and shared scene, R12	An empty native sink read returned None and incorrectly killed the peer. Idle reads now preserve channels; freshness comes from source metadata. Direct and onboard views share the established scene, controls and camera composition. Camera delivery waits for the actual recording producer/committed media and cannot start a producer after STOP.
Accumulation and route continuity, R13	Outbox/backpressure previously replaced the recording and erased history. Protocol v3 preserves recording identity and batch/ACK cursor across disposable peer recovery, with bounded queues, deduplication and explicit expired-resume rejection. Preview never blocks the archive or repeats device commands. Source freshness remains separate from retained history.
Operator flow, R13–R15	Shared spatial scene and K1 phase/timing/route/speed capsule; engine/layer/display controls, accumulation and floating camera. Removed redundant status/loading panels and unused LAB/AI chrome. Full-width configuration action; camera waiting overlay no longer covers its draggable header. Shared installation/GNSS/project fields gate START on a valid name; current admitted modes remain handheld/no RTK. Shared password visibility control and precise connection failure presentation.
Bluetooth and verification, R14–R15	18:03 failure was a missing BlueZ object before Connect/GATT/Wi-Fi write. R14's nested discovery introduced another failure; the native historical error code was not retained, while the installed-client synthetic reproduction produced InProgress. R15 uses one selected-device discovery context held through Connect, removes premature capture revocation and shares policy-bound verification for enrollment/detail. These failures were before password delivery, not evidence of a wrong Wi-Fi password.
Between scans, R16	Completed STOP/READY previously closed the control socket and projected connection loss. The idle socket now remains serviced. The next explicit START opens a fresh one-shot command dialogue for the same bound device/network without another BLE/provisioning step. Generation/CAS and physical ledger guards remain; actual loss still requires proof/recovery. The adapter also no longer mistakes its own just-admitted pending START for a separate unresolved command.
Connection and field presentation, R16	Inventory reports communication separately from acquisition completion. Canonical Design Guideline Field owns neutral autofill colors. Shared spatial viewport has one rounded compositing clip. Actual GPU corner/autofill detail acceptance is not inferred from the broad functional confirmation.

R12 stability and R14 enrollment were failed intermediate acceptance attempts; their installation success and synthetic tests were not treated as physical success. The final implementation supersedes those intermediate mechanisms.

Source and delivery

Key source commits: R10 92b60de, R11 ad24518, R12 fa8ac76 + 9e03404, R13 9bba44f, R14 eed53db, R15 762d77e, R16 c6693d6f442e0d2bb4ea3c5710db7af44d41b667. Installation verification is ee5d760. Design Guideline autofill commit/pin: 26a1bf72a2a32b002e51f910e8faa300333bb6c3.

Installed R16: Node 0.8.13, K1 0.1.13, both install-ok and active/running, NRestarts=0 at post-install readback. Service starts: 21:22:04/21:22:13 MSK; bounded warning-or-higher journal since startup was empty. Core health was HTTP 200, ok=true, and Fleet reported the board online. These observations precede the owner's final confirmation; they are not continuous monitoring.

• Node DEB SHA-256: d5571c956f305ee658a9119d7afeecfb47c99a2aa9dffad37ad2ba9b5e25e592.
• K1 DEB SHA-256: 0cb5826f6c452189c19d69291552492da56bb88b08715fddff8c31eb587a7429.

Archive members/provenance and remote hashes were checked. R16 contains no private application key. Owner entered sudo in the Ubuntu GUI; installed state was verified independently. Source changes are committed locally. This report does not claim a Git push or remote branch synchronization.

Principal implementation files: src/k1link/viewer/node_media.py, node_rerun.py; K1 ble/scanner.py, ble/wifi_provisioning.py, ble/ap_activation.py, node_bridge.py, node_sensor.py, facade.py, camera.py, protocol/application_session.py, application_acceptance.py; packages/spatial-ui/src/SpatialScene.tsx, FloatingMediaWindow.tsx, spatial.css; K1 frontend K1AcquisitionFields.tsx, K1SpatialSession.tsx, K1WifiPasswordField.tsx, sensor preview/enrollment/presentation adapters; Node/K1 package builders and service definition; DG packages/ui-core/styles.css with registry/docs/catalog updates. Exact paths and individual changes are in the commits and dated R10–R16 audits.

Validation performed

R16: 167 control/protocol/Node/supervisor/coordinator checks, final affected subset 89; full acquisition lifecycle 631; installer/package 14; Control Station 809; TypeScript/production builds, DG registry/build, Node UI/Go/package build, K1 package inspection, Ruff and whitespace checks passed. Counts overlap where subsets were rerun and must not be summed as unique tests.

R13 included real bounded loopback WebRTC with native RRD fragmentation, backpressure beyond the old timeouts, ACK loss/resume and camera idle/resume. R15 included the real pinned Bleak manager/scanner against a synthetic D-Bus wire, without hardware access. These regressions protect implementation contracts; they do not establish field reliability or a long-running rate.

Acceptance retained and still required

• R16 package installation and service health verified.
• Owner confirms normal repeated Bridge workflow in the current laboratory.
• Owner confirms K1 connection survives closing/reopening the browser tab.
• Camera/cloud/trajectory and UI START/STOP observed in this conversation.
• Measured 10/20/30 scan cycles, long idle intervals and long acquisition.
• Browser/Core/Node/plugin failures separately while idle, capturing and finalizing.
• K1 sleep, power interruption, wake/reboot and recovery after each stage.
• Network outage/degradation, changed DHCP address, router restart and changed network settings.
• Lost/delayed/duplicated command replies with proof of no repeated physical START/STOP/write.
• Preview congestion/recovery under varied load without false live status or hidden history reset.
• Storage pressure, interrupted finalization and durable archive integrity/recovery.
• Concurrent tabs/operators, stale generations and mismatched device identity.
• Other host/device/firmware/topology profiles and full UI visual matrix.

Decision: retain the working checkpoint and keep broader onboard connection acceptance open. No claim of production reliability, autonomous mission readiness, complete Node requirements, or multi-device generalization is made.

Ops publication verified

On the owner's explicit request to publish the complete current work set, the official NODE.DC Ops MCP applied and read back these updates on 2026-09-07:

• MISSIONCOR-76, issue e48dc205-e73b-42c9-8b5c-b8d52f70267a: full consolidated engineering report and open acceptance matrix in comment 637e7d39-5c39-4c25-880f-888ea74ba981. All 26 architecture baseline blocks and the baseline description remain exactly unchanged. State remains In Progress.
• MISSIONCOR-3, issue 9b75d0cd-4c55-44a6-ada3-558587991be2: eight titled current-result/architecture/implementation/validation/delivery/checker blocks added ahead of the 71 unchanged historical blocks. Description distinguishes direct Mac acceptance from the onboard laboratory result. State is In Progress; the complete multi-scenario onboard acceptance item remains unchecked.
• MISSIONCOR-2, issue 3e4d7128-ca62-408c-bdf8-820435a79a89: one dated onboard laboratory result block and concise summary added; all nine prior blocks retained exactly. State remains In Progress.

Readback confirms the new block bodies/checker values exactly, the expected comment identity and the preserved baseline/history. No card or comment was deleted or archived. No new physical task, test campaign or automation was started. The earlier R10 Ops approval failure remains a historical fact; this publication succeeded under the owner's new explicit request.