96 lines
5.6 KiB
Markdown
96 lines
5.6 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.
|