4.4 KiB
K1 R14: enrollment failure, recheck and launch controls
Observed failures
The owner exercised installed R13 through the UI. Camera, cloud and a 2.47 m trajectory were visible, and STOP was accepted. This supports that bounded run; it is not acceptance of arbitrary network outages or long acquisitions.
The first provisioning failure at 18:03:32 MSK terminated in the installed
Bleak BlueZ manager _check_device, line 217, called by add_device_watcher
while BleakClient.connect was opening its D-Bus connection. The exact selected
device path was absent from the manager. The installed code was inspected to
confirm the branch. This precedes the physical Connect request, GATT baseline
and Wi-Fi write; an incorrect Wi-Fi password did not cause this failure.
The preflight cache check and client entry had an asynchronous gap. Discovery was already stopped, so the checked path could disappear in that gap. BlueZ cache cleanup is the implementation mechanism addressed here; the bounded daemon journal did not record a reason for removing this particular path. The second owner search/provisioning succeeded. No password, raw payload or private device evidence is included in this report.
At 18:09:40 MSK, post-STOP Verify failed in ensure_device_for_gatt while
requiring rediscovery of the exact selected Bluetooth transport. At 18:09:52,
the next Verify had no exact BLE device available. These are discovery failures,
not a rejected Wi-Fi password. The Node detail adapter used legacy server-target
resolution, which prioritizes fresh/retained BLE even when an admitted durable
network target is available.
Changes
- Hold one BlueZ discovery reference from the selected-path preflight until the one Bleak client connection completes. Release it before characteristic reads/writes, including failure and cancellation. The existing exact address, adapter, capture, owner and GATT checks remain. No Connect or Wi-Fi-write retry is introduced. The CoreBluetooth path is unchanged.
- Node Verify requests the exact persisted Bridge target only when the existing server policy admits it without mandatory live GATT validation. The facade continues to verify ledger lineage, route, DeviceInfo, and physical recovery requirements. All other cases retain the existing verification path.
- Failed verification has a direct action to reopen wireless enrollment. The separate Status card is removed; actionable failure stays in the device card.
- Enrollment pending feedback stays in its button. The full-width primary configuration button now also has a full-width footer action container.
- The camera notice is bounded by a relative media-content container. It no longer covers the shared floating window's draggable header and actions.
- Direct and onboard launch consume shared
K1AcquisitionFields: existing installation/GNSS options and project validation. Empty/invalid names disable START. Node validates all three values before workspace/project commands and passes the operator name toacquisition.prepare; a mismatched prepared project cannot be started. Admitted options remain handheld and no RTK.
Validation and delivery boundary
Control Station tests: 805/805 passed, including architecture and direct K1 recovery regressions. Native/Node/Wi-Fi/installer tests: 93/93 passed; the final START subset passed 29/29. They cover the BlueZ cache gap, exact target/adapter, cancellation cleanup, at most one GATT connection/write, persisted verification admission, invalid launch drafts and propagation of the operator project name. Ruff and whitespace checks passed. The final Control Station production build (including typecheck) and Node UI boundary test passed. Tests use synthetic fixtures, without commands to the physical scanner.
The canonical endpoint remains 8000. CUA exposes no documented click/cache controls; no clean-cache hardware acceptance is claimed from source checks or an in-app page load. Owner acceptance must confirm first-attempt enrollment, post-STOP Verify, full-width configuration, draggable camera while waiting/live, and a named acquisition through the existing UI.
R14 is a public matched update: Node 0.8.11 and K1 0.1.11. It uses the existing encrypted onboard credential. No Keychain export, new secret package, physical CLI probe, Git push or Ops retry is part of this change. Production build, artifact identity and installation outcomes are recorded when completed.