4.4 KiB
K1 BlueZ selection R11
Observed failure
The owner reported another Bluetooth failure after installing R10. Read-only dpkg verification confirms Node 0.8.8 and K1 0.1.7+private.1. The bounded service-journal error identifies network.provision, _provision_wifi_impl, BleakClient.connect, add_device_watcher and BlueZManager._check_device. The failure occurs before GATT contract validation or the Wi-Fi write. The screenshot's statement that Wi-Fi was not sent is consistent with this trace. A new screenshot alone does not prove cache clearing or preview acceptance.
Bleak's Linux client implementation retains the D-Bus path of a supplied BLEDevice and skips discovery when that path is already set. A Python object retained through the enrollment form does not keep the BlueZ object alive. R10 addressed only status reads, leaving provisioning with the same stale-path failure.
Change and boundaries
One plugin-local ensure_device_for_gatt preflight now serves both status reads and provisioning. On Linux it first checks the exact selected BlueZ path. When absent, it observes the same address on the same adapter once, for at most eight seconds. It requires that exact native path to exist again before allowing the original BLEDevice into the single GATT connection. Neither device selection nor capture identity is replaced. This also preserves the validated capture handed to the facade's existing session admission.
The preflight requires an active status-read or wifi-provision arbiter owner and checks that owner after each await. Invalidated captures are rejected again immediately before GATT. Public discovery generations are unchanged. Wrong address, different adapter, missing object and owner loss fail before the baseline read or write. There is no retry after a failed connection or write, no pairing, notification subscription, alternate device, fallback network scan or new credential source. The existing durable write-dispatch fence, reviewed GATT contract, baseline read and frame zeroing remain intact. CoreBluetooth behavior is unchanged.
The optional K1 package advances to 0.1.8+private.1. Node stays on the installed 0.8.8; its binary and UI need no rebuild. Rerun live acquisition, recorded review and LAB profiles, preview framing and UI are unchanged by R11.
Validation
131 focused checks pass across Bluetooth selection, provisioning, scanner, runtime arbitration, Node bridge and package lifecycle. The 22 native-cache cases exercise both read and provision with a present/vanished/missing path, wrong address or adapter, a second disappearance, owner/capture invalidation, connect failure, write failure and unchanged macOS behavior. They verify at most one connect and one write, dispatch fencing, original capture handoff and unchanged public generation.
Eight media tests pass separately with UDP loopback permission. The first sandboxed combined run timed out in the native WebRTC loopback test; the same media code passes with the required local socket access. Scoped Ruff and git diff --check pass. No agent-issued physical K1 commands or Bluetooth scans were used. Hardware connection and R10 live-preview acceptance remain pending an owner UI run after clearing the browser cache.
The prior Ops publication and remote full-journal-copy approval blocks remain unresolved; this report is local and contains no raw device identifiers or credentials.
Release staged
Source: ad24518b71. The private immutable artifact
mission-core-xgrids-k1_0.1.8+private.1_amd64.deb is 318109768 bytes with SHA-256
7fb0a5491140a358c815b2897214156f3e2bb10b87177f1851c9e82f142e1e00.
The remote artifact, installer and release manifest hashes match. Apt simulation
selects one K1 upgrade, zero new packages and zero removals.
The owner completed the GUI installation. Subsequent read-only dpkg and provenance checks confirm K1 0.1.8+private.1 from the source commit above and unchanged Node 0.8.8. Both services are active/running with NRestarts=0; the K1 service started at 15:54:46 MSK. Fleet reports application_authority_available true and the canonical Core health endpoint on port 8000 reports ok. No new matching error entries were observed in the K1 journal after that start. Enrollment is idle and disconnected, allowing a new owner scan; this is not physical connection acceptance. The fresh-cache UI attempt remains pending.