feature: Debug mode to help investigate backend access failures

[shazow]

Would be nice if we had a way to dump a bunch of debug info to help figure out problems like #171

Perhaps an unlisted wifitui debug command? Or something else.

We may need to add something like Debug(w io.Writer) error to wifi.Backend which writes all the relevant state to w and returns an error whether the backend is functional (nil) or not.

Is there a better thing to call this than Debug? Perhaps diagnose or health?

[r1w1s1]

My two cents :)

I’d lean towards introducing a status command rather than a dedicated debug one.

Something like:

wifitui status
wifitui status --verbose
wifitui status --json

This keeps things consistent with the existing CLI (e.g. list --json, show --json) and follows a more Unix-style approach where status is the canonical way to inspect current state, and --verbose exposes deeper diagnostic details when needed.

From an interface perspective, this avoids adding a special “debug-only” command and instead makes diagnostics a natural extension of normal usage.

Internally, this could still map to something like a Debug(w io.Writer) method on the backend, but exposed to users as status --verbose.

I think this gives the best balance between usability and keeping the tool simple and consistent.

[shazow]

@r1w1s1 What are some things you'd expect to see from the status subcommand?

[r1w1s1]

After looking at the current commands and backend, I think a status subcommand would fit better than introducing a dedicated debug command.

Something like:

wifitui status
wifitui status --verbose
wifitui status --json

I'd expect status to provide a simple, read-only view of the current state, without duplicating list or show.
wifitui status - quick "what is my current situation right now?" view:

• Radio: on/off (at-a-glance, without needing a separate radio call)
• Connected: yes/no
• Current SSID
• Signal strength
• Security

wifitui status --verbose - diagnostic/backend details:

• Backend in use
• Interface (if available)
• Last connected time
• Last scan timestamp
• Any backend errors

wifitui status --json - same data structured for scripting, consistent with list --json and show --json

So the command roles stay clean:

• list → all networks
• show → one network's details
• status → current connection state

[shazow]

I like this, thanks for the brainstorming!

I would lean toward just including the verbose stuff by default too, unless there are performance implications for some of the status queries then we can gate them behind a flag.

Also related is the proposal for a wifitui devices command: #157