Idea
Add a `bambox doctor` subcommand that prints a single self-contained diagnostic blob users can paste into a bug report. It should answer: what's installed, what's configured, what's reachable, and what recently went wrong — without making the user learn `RUST_LOG` or hunt through `~/.config`.
Suggested output
Scope-out
- No automatic upload anywhere — output is local stdout, user controls what to share
- No secret material in the output (mask access tokens, device serials optional)
- No fix-it actions — diagnosis only, this is not `bambox repair`
Priority
Post v0.5. Soft-launch readiness is being handled via README updates, known-limitations docs, the e2e walkthrough, and the release workflow fix. `doctor` is the next layer of support polish — valuable once real users start filing bugs, not blocking on day one.
Why it pays off
Once strangers start filing bugs, the first round-trip on every issue is "what version, what OS, native or Docker, can you paste the bridge log" — `bambox doctor` collapses that into a single command and dramatically shortens the support loop.
Idea
Add a `bambox doctor` subcommand that prints a single self-contained diagnostic blob users can paste into a bug report. It should answer: what's installed, what's configured, what's reachable, and what recently went wrong — without making the user learn `RUST_LOG` or hunt through `~/.config`.
Suggested output
Scope-out
Priority
Post v0.5. Soft-launch readiness is being handled via README updates, known-limitations docs, the e2e walkthrough, and the release workflow fix. `doctor` is the next layer of support polish — valuable once real users start filing bugs, not blocking on day one.
Why it pays off
Once strangers start filing bugs, the first round-trip on every issue is "what version, what OS, native or Docker, can you paste the bridge log" — `bambox doctor` collapses that into a single command and dramatically shortens the support loop.