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