3.3 KiB
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 к Wi‑Fi”. 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.jsconfirmed both the new title and guidance; the HTML response hasCache-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.