Repository navigation
setup: stop offering, on the existing-Blox screen, the two things that cannot work there - #12
Merged
Merged
Conversation
…t cannot work there connect-existing adds a Blox you ALREADY own. Such a Blox stops serving the setup API the moment it has an owner, so it answers nothing on the network. The screen was built around that fact being false. It auto-fired a network search on arrival. That search structurally cannot find the one thing this screen is for, yet it ran ~15 s (the hotspot probe alone waits that long) before the user could do anything, then reported "No devices found. Make sure your Blox is powered on and connected to the same network" -- advice that could not have helped, because being on the same network is exactly what does not matter here. The search is now an explicit button, and it says what it is actually for: a Blox that has NOT been set up yet, or one you are joined to over its own Wi-Fi. "Nothing found" only appears once something has looked. Bluetooth leads, because it is the one route that does reach an already-owned Blox. The manual card also offered "Set up a new Blox by its address". Claiming a not-yet-set-up Blox by address is a different job and belongs to the LAN step in ConnectToBlox; on this screen it was a field that could only ever fail. Gone, along with its now-orphaned strings. Manual entry here asks for the peer id, and only the peer id. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YJyqpFReP1wbz86nsqsoXq
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two things on
/setup/connect-existingthat could not work there, both flagged by the user.This screen adds a Blox you already own. Such a Blox stops serving the setup API the moment it has an owner, so it answers nothing on the network. The screen was built around that fact being false.
The network search auto-fired on arrival
It structurally cannot find the one thing this screen is for, yet it ran for ~15 s (the hotspot probe alone waits that long) before the user could do anything — and then said "No devices found. Make sure your Blox is powered on and connected to the same network." Advice that could not have helped, because being on the same network is exactly what does not matter here.
Now: no auto-scan. The search is an explicit button that says what it is actually for — a Blox that has not been set up yet, or one you are joined to over its own Wi-Fi. "Nothing found" only appears once something has looked (it would otherwise greet everyone on arrival). Bluetooth leads, because it is the one route that does reach an already-owned Blox.
The manual card offered "Set up a new Blox by its address"
On the existing-Blox screen. Claiming a not-yet-set-up Blox by address is a different job and belongs to the LAN step in
ConnectToBlox(added in #4); here it was a field that could only ever fail. Removed, along with its now-orphaned strings in both locales. Manual entry on this screen asks for the peer id, and only the peer id.Tests
The suite leaned on the auto-scan, so a
renderAndScan()helper now asks for the search explicitly the way a user does. New assertion that the address field is absent here.824/824,
tsc --noEmitandeslintgreen.🤖 Generated with Claude Code
https://claude.ai/code/session_01YJyqpFReP1wbz86nsqsoXq