105 lines
6.1 KiB
Markdown
105 lines
6.1 KiB
Markdown
# 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 to `acquisition.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.
|
||
|
||
## Built and staged R14
|
||
|
||
Source commit: `eed53dbc0b5a47061b51a46cd7905cc6137e0738`.
|
||
Both production/typecheck builds passed. Package inspection found 94 Node and
|
||
184 K1 members, no links or private application-key member, matching source
|
||
provenance, and `application_material_included=false` for K1.
|
||
|
||
- `mission-core-node_0.8.11_amd64.deb`: 109837510 bytes; SHA-256 `304adb734ada587256a444e54fef2ebf584738c72bd8f431cf63d82886d629bc`.
|
||
- `mission-core-xgrids-k1_0.1.11_amd64.deb`: 318114552 bytes; SHA-256 `f2d69dd6616167850e9a4d211fb7692127c1f65039d062ff24fd0614fde813cc`.
|
||
|
||
The unique R14 directory was staged on the authorized onboard computer. Both
|
||
remote checksums passed. Apt simulation selects exactly these two upgrades from
|
||
Node 0.8.10 and K1 0.1.10, with no additions/removals. The existing installer
|
||
safe-state guards remain in place.
|
||
|
||
Before installation, Fleet reported the board online and acquisitions idle.
|
||
Mission Core returned HTTP 200; the updated home page rendered in the in-app
|
||
browser. The single canonical process remains on 8000, with no listener on 8765.
|
||
The native “Mission Core · K1 R14” installation window is open for owner-entered
|
||
sudo. Installation exit status and clean-cache physical acceptance are pending.
|
||
|
||
## Subsequent installation and failed acceptance
|
||
|
||
On 2026-09-07 the board reported installed Node 0.8.11 and K1 0.1.11.
|
||
The K1 service entered active state at 19:06:33 MSK with NRestarts=0.
|
||
Owner testing at 19:08–19:11 failed enrollment. R14 is therefore installed but
|
||
not accepted. Its synthetic scanner test permitted nested discovery sessions
|
||
that the actual Bleak/BlueZ client does not support. See the R15 connection
|
||
audit for the exact sequence, reproduction and replacement of that mechanism.
|