[ehsan6sha]

What

ConnectToBlox asked three technical questions at once — Bluetooth, hotspot, local network access — before the user had answered any of them. It now asks one at a time, in the order that needs least from the user:

stage	what it needs	when
bluetooth	nothing — just Chrome's device chooser	on arrival
lan	the Blox on the network and its address	only after Bluetooth failed
hotspot	the user gives up their internet for a minute	only after "I don't know the address"

The LAN step is the new one, and it is a last resort rather than the default: it is offered, not assumed, and "I don't know the address" moves straight on.

Safety

The typed address is checked against the private ranges (bloxLanUrl → ipIsPrivateLan) before any request is made. Setup traffic includes /peer/exchange, the call that claims the box, so a typo or a pasted public address must never leave the local network.

Behaviour worth calling out

• Silence is not an error. An address that does not answer renders a quiet "No Blox answered at that address" line, not the red error card. No answer is the expected outcome on firmware that predates the LAN setup listener (wap: keep the unowned-box LAN setup listeners in step with the interfaces go-fula#248) and on a Blox that is simply not on this network. Only a browser-level failure — local network access denied, or CORS — earns the error card.
• Nothing is probed on entering the LAN step. The Bluetooth chooser that ran just before may have consumed the user activation Chrome's local-network prompt needs, so the probe waits for its own button press. Same reason the hotspot check was never auto-fired after a Bluetooth failure.
• The hint under the tower follows the stage: it names what to pick in the device chooser while that is the question, and only mentions local network access once something is actually about to make a LAN request. That explainer used to greet every user on first paint, describing a permission nothing was about to ask for.
• The LAN path skips the Wi-Fi step. A Blox already on the home network has no Wi-Fi left to join, and every Wi-Fi/hotspot endpoint is served only at 10.42.0.1 — routing it through ConnectToWifi would hand the user a step that cannot answer, and CheckConnection would tell them to leave a hotspot they never joined. This was already SetBloxAuthorizer's behaviour for isLanSetup; it is now covered by a test rather than by inspection.

Tests

ConnectToBlox.test.tsx 13/13 and a second flow test in setupFlow.test.tsx that walks the LAN entry point end to end: the typed address reaches only the ip-scoped API calls, never the hotspot ones, and the flow lands on Setup complete with getWifiList untouched. The hotspot tests now reach their stage the way a user does (Bluetooth fails → "I don't know the address"). Full suite, tsc --noEmit and eslint are green.

Requires

functionland/go-fula#248 for a Blox that acquired its LAN address after boot to be listening at all — and that needs a go-fula release, not just a merge. Until then this step degrades to "no Blox answered" and the user falls through to the hotspot exactly as today.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01YJyqpFReP1wbz86nsqsoXq