Files
NODEDC_MISSION_CORE/docs/audits/2026-09-07-k1-lab-acceptance-and-node-continuation.md

6.6 KiB

K1 LAB acceptance and onboard continuation

Accepted local baseline

The owner confirmed a successful local LAB connection after correcting the network name. Core independently recorded network_applied and DeviceInfo / control ready in 8.298 seconds. In the next operator-run session the owner reported the usual approximately 20-second calibration, prompt point-cloud appearance, visible signal loss after disabling Wi-Fi and successful recovery after enabling it again (approximately 20 seconds of waiting). These recovery timings are operator observations, not newly instrumented latency measurements. They qualify that local run, not every outage duration, a Node reboot or Ubuntu.

The owner requested committing and pushing the working implementation and resuming K1 Bridge on the paired onboard computer. The backend connection read-model extraction, plugin-owned sensor UI, BLE discovery fixes, station error messages, camera evidence-root handling, Node enrollment and separate viewer-profile discriminators are included in this checkpoint. Earlier audit documents retain their original time-scoped validation and limitations.

Spatial scene placement

The owner explicitly moved the local test-device live scene from Control to LAB. Its operator job is inspection of the current local test stream; source selection, acquisition and live settings retain their existing ownership. Keeping it under Control would imply the future operational board view; a new root or duplicate viewer would add an unnecessary product surface. The existing workspace is therefore registered under LAB with its stable spatial-scene ID, renderer, settings and links intact. Existing sidebar, workspace shell and globe icon are reused; no new Design Guideline primitive is introduced.

Only obsolete Control quick links to that scene are retired on settings read. Custom page copy, media and unrelated links remain intact. Default Control shortcuts become cameras and map. Home and LAB links can still open the same scene. This is an owner-approved relocation, with no Rerun parameter change.

Validation and onboard candidate

  • Environment migration, Node bridge, connection read-model and Fleet enrollment tests passed: 36 cases. Ruff passed for the environment changes.
  • Go package tests passed with the built Node UI embedded and an isolated build cache. No system toolchain or package installation was needed.
  • Core architecture/type checks passed. Full frontend run: 784/786 passed; the two failures were old LAB workspace-list expectations. Those expectations were updated and both affected suites passed; no production change followed.
  • Node 0.7.1 is the next package version so the earlier 0.7.0 candidate is not silently replaced. Build provenance now covers the moved K1 frontend sources. The 51 K1 and 29 RealSense wheel hashes were verified before reuse.

The current paired board was resolved from authenticated Core Fleet data and its SSH host key matched the previously trusted Mini key. It runs Node 0.6.11. Administrative installation requires the owner's normal Ubuntu authentication; non-interactive sudo is unavailable. No password is requested in chat.

The exact package, installation result, source commit and final Core UI delivery are recorded in a subsequent release addendum after the build. Device preparation and real Bridge acquisition must still be accepted through both interfaces on that board. Operator and board WLANs remain independent; the board owns Bluetooth, network observation, K1 commands and raw data.

Ops direct tools are absent in this session. This local report is prepared for the K1 and Node cards; no Ops publication is claimed.

Release addendum: installation confirmed

The observations above describe the pre-build checkpoint. The final source commit is 63ea2bed672cd17251fc484560a58d0de2e1075c, published to origin/main; the local and remote branches were verified equal with a clean working tree. Core UI was built and published to canonical port 8000. The backend was replaced only after idle/completed acquisition and control, no pending cleanup and no running operation had been verified. The replacement reports operational=true; no alternate Mission Core backend was introduced.

Package mission-core-node_0.7.1_amd64.deb contains 429546210 bytes and has SHA-256 83ea1cdc9aea598e92fae519124279c9583be56b37cafca049e7029e22a92ee7. Its provenance binds the source checkpoint, including K1 frontend files. Package metadata, maintainer scripts, required runtime files and the transferred hash were verified before installation. The owner completed normal Ubuntu administrator authentication on the previously trusted Mini. At 2026-09-07T07:51Z, dpkg-query confirms 0.7.1; both mission-core-node and mission-core-k1 are active with no automatic restarts. Bluetooth and NetworkManager are active, and the Bluetooth adapter is powered on. The original Node identity and Core binding remain intact; Core receives the available idle Bridge runtime. RealSense remains registered and configured, but its hardware is currently absent from the board's USB inventory. Live RealSense acceptance after this update is not claimed.

The installed worker starts without an application credential, as designed; discovery is available while control authority remains to be prepared. Transfer of the existing macOS Keychain application key to the Mini's encrypted systemd credential store was rejected before execution by automatic approval review: explicit consent for that credential and destination is required. The owner has been asked for that consent. No key was read or transferred. The prepared import uses protected SSH stdin and an in-memory pipe, normal Ubuntu sudo authentication, the installed root-only import helper, and an idle worker restart. It does not transfer a Wi-Fi password or put secrets in command-line arguments, environment variables, source files or logs.

Direct Ops tools subsequently became available. Their startup rules, project context and current cards were read through the direct MCP. Five release and acceptance blocks were appended to K1 card #3, preserving all 29 existing blocks and its historical state. Node card #76 received progress comment 604aa523-b1a0-4e61-8452-35d5a0fcbf1f; its frozen 26-block architecture baseline was not changed. The prior successful-after-cache-clear checker, Ubuntu live acceptance, credential readiness and board recovery checkers remain open.

Next acceptance is one explicit Bridge workflow through the installed Node and Core interfaces, with cache cleared before every hardware test as requested by the owner. Camera/LiDAR output, the isolated live profile and board-side outage recovery are not yet proved by this installation check.