95 lines
5.5 KiB
Markdown
95 lines
5.5 KiB
Markdown
# Wireless workflow groups and failure observability R6
|
|
|
|
The owner requested separate Bluetooth and Wi-Fi steps and automatic reveal of
|
|
new content in the bounded wireless-enrollment modal. This is a composition of
|
|
existing SettingsCard, ResourceList, ResourceRow, Button and field primitives,
|
|
with no new Design Guideline entity, surface decoration or navigation change.
|
|
Both Core and Node consume the same plugin-owned form.
|
|
|
|
Bluetooth discovery and selectable candidates belong to step 01. Step 02 appears
|
|
after explicit selection and groups the K1 Wi-Fi network, credentials, connection
|
|
check and its result. The check description is fully visible in the card header;
|
|
the action is below the fields. The final Connect action still requires the
|
|
current successful proof and sends no second physical command.
|
|
|
|
Explicit discovery results, selected-device Wi-Fi, network choices and changed
|
|
connection results reveal themselves inside the existing nearest scrollable
|
|
surface. Poll revisions and typing do not trigger scrolling. Fully visible
|
|
content does not move, tall steps reveal their heading, reduced-motion uses an
|
|
instant move, and keyboard focus stays with the operator. The page behind the
|
|
modal is never scrolled. A completed rescan dismisses the preceding attempt's
|
|
message without suppressing a later outage or new result.
|
|
|
|
## Actual failed attempt
|
|
|
|
The owner UI attempt at 10:09:50.958 UTC completed at 10:09:51.021 UTC with
|
|
BleakError, stage connect-failed, phase network_not_applied and side-effect
|
|
status none. Wi-Fi settings were not sent. Installed BlueZ is 5.72; both Node
|
|
0.8.3 and optional K1 0.1.2 services were active without restarts. This is not
|
|
evidence of a wrong network name/password or an Ethernet routing fault.
|
|
|
|
The exact Bluetooth exception origin is not recoverable from this deployment's
|
|
public projection or system journal. The facade records structured fields, but
|
|
the default service logger prints only the fixed message; Node's outer HTTP
|
|
exception handler never sees journalled failures returned as normal results.
|
|
R6 logs a validated operation ID, internal action, exception class and source
|
|
file/function/line locations at that existing catch boundary. It never logs
|
|
exception text, source lines, local values, credentials or payloads. The
|
|
invocation still runs once and then reads only its exact journal result.
|
|
|
|
An explicit pre-dispatch Bluetooth connection failure is now shown in step 01,
|
|
says Wi-Fi settings were not sent and requests a fresh scan. Its failed native
|
|
selection cannot be reused in the dialog. Unknown write outcomes retain their
|
|
existing read-only reconciliation path and are never described as unsent.
|
|
The next clean-cache owner UI attempt is needed to identify the precise
|
|
Bluetooth backend failure; this increment does not claim that physical
|
|
connection failure is fixed.
|
|
|
|
## Scope and validation
|
|
|
|
No BLE framing, mutation/retry policy, runtime fences, MQTT supervisor, host
|
|
network switching, LAB connection flow or Rerun profile changes. The board may
|
|
remain on Ethernet while K1 joins the router's Wi-Fi. The optional backend change
|
|
is confined to NodeBridge diagnostics; the local LAB facade is unchanged.
|
|
|
|
Focused architecture/enrollment checks: 22 passed. Full Core frontend suite:
|
|
793 passed. Focused NodeBridge and real package-maintainer lifecycle tests:
|
|
16 passed, including secret-free failure logging without a second invocation.
|
|
Core TypeScript and production build passed. Changed backend files pass Ruff;
|
|
the Node package builder has 17 pre-existing lint violations outside the
|
|
version-only edit. Repository-wide lint success is not claimed.
|
|
|
|
Node 0.8.4 and optional K1 0.1.3 are reserved for this increment. Exact build,
|
|
installation and owner UI acceptance must be recorded separately. Private
|
|
screenshots, observations, UTC/monotonic manifest and hashes are retained under
|
|
private/acceptance/k1-node084-20260907-core-ui. Cache clearance is not yet
|
|
explicitly confirmed for the preceding owner observation.
|
|
|
|
## Delivered and installed
|
|
|
|
Source `d7986cb62f2fad01f4a37faab10d971eaf29f266` produced Node 0.8.4
|
|
(109814576 bytes, SHA256
|
|
`85b2ff1b101d02c55ac99a80aac706c317054884665decd38c6ff4f6d911c628`)
|
|
and private K1 0.1.3+private.1 (318107598 bytes, SHA256
|
|
`3893d8c28e4af8cf751861d7a307ee1e6a744f174083fe3ffffb777c33bc0c46`).
|
|
The private release is retained as mission-core-node-k1-20260907-r6. Transfer
|
|
hashes matched and APT simulation selected two upgrades without removals.
|
|
The owner entered sudo in the Ubuntu GUI; the installer exited with code 0.
|
|
Installed versions and both provenance base commits match this source. Node
|
|
and K1 are active/running with zero restarts, started at 13:31:04 and 13:31:12
|
|
MSK respectively. The old application credential and Fleet binding are retained.
|
|
|
|
Core on 8000 remains operational and serves the exact new index, SHA256
|
|
`f8e1241271f46192ec89385ee32e16d9b322b5445bc04e97eb70e186571abd46`;
|
|
there is no Mission Core listener on 8765. Node UI boundary test also passed.
|
|
The Ubuntu window is a separate ephemeral WebKit view; closing and reopening it
|
|
loads the new frontend without restarting the background services. An already
|
|
open window does not prevent updated service code from running.
|
|
|
|
The owner has been asked for a fresh-cache Chrome discovery/selection/connection
|
|
check so the new trace can establish the Bluetooth failure origin. That UI test,
|
|
successful Bridge, live camera/LiDAR and recovery are still pending. No agent
|
|
CLI BLE/MQTT experiment or in-app browser cache workaround was used. Both
|
|
implementation and this report are local commits; the earlier automatic review
|
|
block on Git publication of installation reports remains unresolved.
|