Files
NODEDC_MISSION_CORE/docs/audits/2026-09-07-k1-wifi-refusal-ui.md
T

3.3 KiB
Raw Blame History

K1 Wi-Fi refusal: operator diagnosis and UI correction

The owner confirmed that the previously entered Wi-Fi network name was wrong and that connection succeeded after correcting it. The canonical Core journal independently records a successful Bridge attempt on 2026-09-07, from 07:01:10.203 UTC to 07:01:18.501 UTC: network_applied, device-info-confirmed, control ready (8.298 seconds).

The earlier ATT 4 response is therefore consistent with the exact reviewed FW 3.0.2 station callback's network-not-found branch. The response establishes the device's reported failure, not independently which character the operator typed incorrectly. ATT 6 remains the separate credentials-required branch; neither is inferred from a generic timeout or lost response.

Implementation

The existing plugin-owned networkFailurePresentation.ts keeps distinct public codes and specific reasons, while both messages now explicitly ask the operator to check the network name and password. K1OperatorError.tsx gives those exact station refusals the title “Не удалось подключить K1 к WiFi”. Existing LAB and onboard enrollment consumers share the text. Unclassified Bluetooth errors, timeouts and unknown outcomes keep their separate presentation.

This increment changes presentation only. No BLE frame, station callback classification, ledger, retry authorization, acquisition command, connection recovery or Rerun setting was changed. The historical failed attempt remains failed/unconfirmed; the later successful attempt supplies its own authority.

Validation and delivery

  • Existing rendered recovery, provisioning and onboard enrollment assertions were updated for the explicit Wi-Fi cause and credential guidance.
  • Architecture checks passed (4 cases); the full frontend suite passed (786 cases), including the existing no-resubmit and unknown-outcome coverage.
  • Control Station and Node UI TypeScript checks and production builds passed. Builds/tests were sequential; no Docker or extra backend was started.
  • The Core UI was built in a temporary directory, then published with HTML last and prior hashed assets retained for already open tabs. HTTP verification of /assets/app-B5NeGPU1.js confirmed both the new title and guidance; the HTML response has Cache-Control: no-store.
  • Core 8000 remained alive with the same runtime identity and the K1 control session ready. The backend was not restarted. No backend listens on 8765.
  • The Node UI was built locally; this increment was not installed on Ubuntu. No new device failure or browser hardware attempt was induced. Browser cache clearing was not performed by the agent and no fresh-cache visual acceptance is claimed. The user's successful attempt and rendered tests are distinct evidence sources. Stream, power-loss and Ubuntu acceptance are not established by this connection-only success.

Sanitized success evidence, owner notes, UTC/monotonic observation timestamps and SHA-256 artifact metadata are retained outside Git in the ignored .runtime/k1-connect-incident-20260906/success-20260907/ directory. No Wi-Fi password or submitted network name was retained.

The direct Ops tools are absent from this turn's tool inventory, and no tool discovery endpoint is exposed. This report is prepared for card #3; it has not been written to Ops. Legacy Ops widgets and raw API workarounds were not used.