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

111 lines
6.6 KiB
Markdown

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