# 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.