58 lines
3.3 KiB
Markdown
58 lines
3.3 KiB
Markdown
# 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.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.
|