Group onboard wireless steps and trace journalled Bluetooth failures

docs/audits/2026-09-07-k1-wireless-flow-r5.md

@@ -79,9 +79,11 @@ The release is retained in `private/releases/mission-core-node-20260907-r5`.
 Owner screenshots, redacted UTC/monotonic manifest and validation logs are
 hashed under `private/acceptance/k1-node083-20260907-core-ui`.
 
-One Ubuntu GUI installer is open and awaiting owner sudo authentication.
-The latest observed installed versions are still Node 0.8.2 and K1
-0.1.2+private.1, both active. Installation and new UI hardware acceptance must
-not be inferred from the package build. Git publication remains pending the
+The owner completed Ubuntu authentication; the installer exited with code 0.
+Readback confirmed Node 0.8.3 and K1 0.1.2+private.1, both active with zero
+restarts, started at 13:08:15 MSK. This confirms the Node-only upgrade restored
+the existing plugin. The next owner UI attempt found K1 but failed at Bluetooth
+connect before Wi-Fi dispatch; see the R6 report. Fresh-cache Bridge/live
+acceptance remains open. Git publication remains pending the
 explicit owner reply to the prior automatic approval rejection of deployment
 reports; no push workaround was used.

docs/audits/2026-09-07-k1-wireless-steps-r6.md

@@ -0,0 +1,66 @@
+# 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.