5.9 KiB
Node K1 operation identity R4
The owner's next Core Fleet UI attempt at 12:19 MSK failed on installed Node
0.8.1 / K1 0.1.1+private.1. The newly added journal diagnostic recorded
action=scan exception=ValueError. The board still had discovery generation
zero. Its BlueZ controller was powered and not rfkill-blocked. This was an
execution failure before discovery, not evidence that K1 was absent.
Reproduced cause
The Node protocol requires op_ followed by 32 lowercase hexadecimal digits.
The K1 OperationJournal accepts a UUID, optionally prefixed by op-. Passing
the Node ID unchanged fails in device_lifecycle._identifier before any BLE
call. R3 corrected the missing runtime fence but its service stub hid this
second boundary mismatch. The new regression reproduced the exact ValueError
with the real NodeBridge, facade, compatibility service and operation journal.
NodeBridge now translates the host ID into the plugin UUID format. The mapping is deterministic and preserves all 128 bits. Host IDs remain unchanged in the Go broker, durable Node journals and HTTP responses. The plugin's validators, LAB callers and lifecycle authority are unchanged. Connection attempt and recovery IDs are projected back to host IDs so continued UI observation can still match the exact request after the Wi-Fi acknowledgement.
The same conversion covers scan, provision, verify, START and STOP. The
acquisition prepare child uses a deterministic UUID derived from the host
intent, distinct from its START operation. It no longer appends an invalid
_prepare suffix to an operation ID. Repeated intent IDs reach the same journal
row; no random replacement IDs, automatic provisioning replay or migration of
old unknown operations were introduced.
Error evidence and UI
An invocation failure reads only its exact existing plugin journal row. A recorded scan failure reaches the caller as failed; an exception before any row exists remains an unconfirmed execution. Neither is a successful empty search. Both produce a Bluetooth search error in the shared enrollment UI, while a confirmed zero-candidate result still displays K1 not found. Search failures do not display the Wi-Fi connection notice.
Unexpected worker failures log admitted action, exception class and source function/line locations only. Exception text, source text, local variables, request payloads and credentials are excluded.
Validation and limits
The scan regression keeps the actual service, journal, BLE arbiter and scanner logic, replacing only BleakScanner's OS radio endpoint. It verifies successful discovery and a failed radio start, correct host result correlation, and one radio invocation when the exact command is repeated. Acquisition IDs are checked against the actual OperationJournal. Projection does not mutate the plugin's native state. Frontend tests distinguish failed, rejected, unknown and confirmed empty scans and retain network/bootstrap/recovery regressions.
Focused Python bridge, installer, Fleet enrollment, BLE scanner and operation journal suite: 73 passed. Core frontend suite: 789 passed, no failures or skips. Build and installation acceptance is recorded below.
Release versions are Node 0.8.2 and optional K1 0.1.2+private.1. Existing private release bytes and application material are retained. This is a Node adapter correction; no Rerun profile, protocol frame, MQTT recovery state machine or shared lifecycle validator was modified. Physical Bluetooth discovery, Bridge, live camera/LiDAR and interruption recovery still require fresh-cache UI acceptance. No agent CLI hardware command is part of this test.
Release preparation
Both packages use source d2dbfc9c85a8375205626914232d7355ce24f30b.
Core and Node TypeScript/production builds passed; Node UI boundary test passed;
Go package tests passed (cached). The canonical Core on 8000 is operational and
serves the exact new index, SHA256
77e0ab03a271e3213d4aa12d3d7b91f75ad8d2d6b5dc8294263a47e91ab7cfc1.
| Package | Bytes | SHA-256 |
|---|---|---|
mission-core-node_0.8.2_amd64.deb |
109813510 | 1318a2ff45171d20b3aad677d7fec0e3866b5367672b0a254800e50aad468a19 |
mission-core-xgrids-k1_0.1.2+private.1_amd64.deb |
318107248 | 3a883b1398718ea04b9d81e9632eaa64f37459dca19d262e4a362f29383c80d5 |
Provenance, the packaged adapter source and root:0600 private profile member
were verified. Transferred hashes match. APT simulation selected two upgrades
and zero removals. The private release is in
private/releases/mission-core-node-k1-20260907-r4; the redacted UTC/monotonic
acceptance manifest and hashed validation logs are in
private/acceptance/k1-node082-20260907-core-ui.
The owner entered sudo authentication in the one launched GUI installer. It exited with code zero. Installed Node 0.8.2 and K1 0.1.2+private.1 both report source d2dbfc9; the installed adapter contains the operation-ID conversion. Node and K1 became active/running at 12:41:26 and 12:41:34 MSK respectively, both with NRestarts=0. Core Fleet receives the new runtime through the retained binding; it reports fresh/available/idle and permits scan-ble. No hardware discovery is inferred from these readiness facts. The owner was asked to clear Chrome cache again and repeat Find K1 through the Core Fleet modal.
The subsequent real onboard scan completed: Fleet reported discovery generation 1, one K1 candidate and RSSI -62 dBm, with the new runtime still available. The agent issued no hardware command; this was observed after asking the owner to use the UI. This confirms actual onboard Bluetooth discovery. Separate explicit confirmation of the fresh-cache procedure, Wi-Fi provisioning, camera/LiDAR and recovery acceptance remains open. Raw device identifiers stay in the private acceptance material.
Git publication remains pending explicit owner authorization after automatic
approval review rejected the preceding installation report 2fdf1d3 due to
internal deployment metadata and its destination. No push workaround was used.