Refresh selected BlueZ path before K1 GATT operations

This commit is contained in:
DCCONSTRUCTIONS
2026-09-07 15:50:06 +03:00
parent 7ce09eabcd
commit ad24518b71
8 changed files with 303 additions and 55 deletions
@@ -0,0 +1,62 @@
# 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](https://bleak.readthedocs.io/en/stable/_modules/bleak/backends/bluezdbus/client.html)
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.
Release hashes and installed readback follow when available. 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.
@@ -116,3 +116,12 @@ acceptance directory was rejected as well; that journal was not copied.
The owner was asked for explicit permission for an additive report and that
bounded private journal copy. Existing private Fleet/screenshots are retained;
no publication, permission workaround or alternative remote destination was used.
## Installation readback and provisioning follow-up
After the owner's next screenshot, read-only dpkg confirms Node 0.8.8 and
optional K1 0.1.7+private.1 installed. This closes the installation gate only.
The new failure is in network.provision before the first GATT connection:
Bleak's add_device_watcher calls the manager's missing-device check. R10's
status-read-only refresh did not cover this path. The shared native-object
preflight and its remaining physical acceptance are recorded in the R11 audit.