106 lines
5.9 KiB
Markdown
106 lines
5.9 KiB
Markdown
# 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.
|