feat: add automatic bug reporting flow (closes #334)

[smazmi]

Summary

Adds a bug-report flow in both CLI and TUI that opens a pre-filled GitHub issue with environment details, reducing manual bug-report setup and improving report completeness.

What Changed

• Added a new CLI command: surge bug-report.
• Added shared helper package at internal/bugreport for:
  • Building the GitHub new-issue URL with prefilled title/body.
  • Opening the default browser with fallback support.
• Added TUI dashboard keybinding (?) to trigger the same bug-report flow.
• Wired commit metadata into runtime via build flags and build-info fallback.
• Reused/extended existing open utility with OpenURL for shared browser launch behavior.
• Added unit tests for bug-report URL generation and URL opener validation.
• Updated CLI usage docs with surge bug-report command.

Why

Issue #334 asks for automatic bug report preparation so users do not need to manually collect version/build/system details.

Implementation Notes

• URL query parameters are built with net/url and url.Values.
• Bug report body follows the existing bug template structure and auto-fills:
  • OS and architecture
  • Surge version
  • Commit hash
• Browser-open failures gracefully fall back to printing the raw issue URL.

How To Test

1. Run full tests:
   • go test ./...
2. Build:
   • go build ./...
3. CLI sanity check:
   • surge bug-report
   • Expected: opens browser to pre-filled GitHub issue.
4. Fallback sanity check (no opener available):
   • PATH='' ./surge bug-report
   • Expected: prints manual URL fallback.
5. TUI sanity check:
   • surge
   • Press ? on dashboard.
   • Expected: opens pre-filled bug report URL (or logs manual fallback URL on failure).

Checklist

• PR is focused and readable.
• Tests added/updated for behavior changes.
• go test ./... passes.
• CLI docs updated.

Greptile Summary

Adds a surge bug-report CLI command and a TUI ? keybinding that walk the user through building a pre-filled GitHub issue URL with optional OS details, version/commit, and latest debug log path. The implementation is well-structured, tested, and cleanly separated between internal/bugreport (URL building) and internal/utils (browser launch).

• The full absolute log path (containing the user's OS username) is embedded in the public issue body without the consent prompt making this explicit — consider tilde-collapsing the path or updating the prompt wording.
• TestCommit_DefaultValue checks Commit == \"\" but the default sentinel is \"unknown\", so the assertion can never fail and gives no real coverage.

Confidence Score: 5/5

Safe to merge; all remaining findings are P2 style/quality suggestions with no blocking defects.

The feature is well-implemented with solid test coverage across CLI and TUI paths. The two flagged items — a misleading test assertion and a privacy wording gap — are non-blocking and don't affect runtime correctness. Prior P1 concerns have been resolved in this revision.

internal/bugreport/bugreport.go (log path privacy wording), cmd/cmd_test.go (weak test assertion)

Security Review

• Path disclosure in public GitHub issue (internal/bugreport/bugreport.go): When IncludeLatestLogPath is true, the full absolute log path (e.g. /home/alice/.local/state/surge/logs/\u2026) is embedded in the issue body without warning the user that their OS username will be publicly visible.

Important Files Changed

Filename	Overview
cmd/bugreport.go	New CLI command with interactive prompts for core/extension bug reports; good EOF handling and browser-open fallback.
internal/bugreport/bugreport.go	URL builders and log-path helper are correct; log path may expose the user's home directory/username in a public GitHub issue without explicit warning.
internal/tui/update_modals.go	Adds three new modal update handlers (target, system details, log path); reuses QuitConfirm keybindings for yes/no flow cleanly; clipboard fallback on browser failure is a nice touch.
internal/tui/model.go	Adds three new UI states and CurrentCommit field; variadic currentCommit parameter masks what is now a de-facto required argument.
internal/utils/open.go	OpenBrowser now trims whitespace before the empty-check; previous OpenURL duplicate removed in favour of updating the existing function.
cmd/cmd_test.go	TestCommit_DefaultValue checks Commit != "" but Commit defaults to "unknown", so the assertion can never fail and provides no real coverage.
internal/tui/keys.go	New BugReportKeyMap and ReportBug dashboard binding (?) added; FullHelp updated to include BatchImport, OpenFile and ReportBug.
internal/tui/view.go	Three new modal views for bug report states rendered consistently with existing btop-style boxes.
cmd/root.go	Adds Commit variable with ldflags injection and vcs.revision fallback via debug.ReadBuildInfo; refactors init() cleanly.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: cmd/cmd_test.go
Line: 441-445

Comment:
**Test always passes — wrong sentinel value**

`Commit` is initialised to `"unknown"` (not `""`), so `Commit == ""` will never be true and this test can never fail. It provides no signal that commit detection is actually working. The simplest fix is to verify the sentinel explicitly so a regression (e.g., changing the default to `""`) would be caught.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: internal/bugreport/bugreport.go
Line: 678-681

Comment:
**Log path exposes home directory in a public GitHub issue**

When `IncludeLatestLogPath` is true and a log file is found, the full absolute path (e.g. `/home/alice/.local/state/surge/logs/debug-20260413-120000.log`) is embedded verbatim in the issue body. Because GitHub issues are public, this silently discloses the user's OS username. The yes/no prompt doesn't surface this consequence.

Consider either (a) stripping the home-directory prefix and showing a relative path like `~/.local/state/surge/logs/…`, or (b) making the prompt explicit: *"Include latest debug log path? (Note: the full path including your username will be visible in the public issue)"*.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: internal/tui/model.go
Line: 1511

Comment:
**Variadic `currentCommit` obscures a now-required parameter**

Both call sites (`cmd/root.go` and `cmd/connect.go`) already pass `Commit`, so the variadic signature only survives for callers that don't supply a commit — but the bug-report feature will silently fall back to `"unknown"` for those callers instead of surfacing a missing argument. A regular positional parameter would make the expectation explicit and let the compiler enforce it.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (7): Last reviewed commit: "feat: improve bug reporting workflow wit..." | Re-trigger Greptile}

[github-actions]

Binary Size Analysis

⚠️ Size Increased

Version	Human Readable	Raw Bytes
Main	19.22 MB	20148516
PR	19.36 MB	20300068
Difference	148.00 KB	151552

[SuperCoolPencil]

Hi @smazmi

I would like to know more about the UX for reporting a bug. I wanted it to be something like:

1. surge bug-report
2. Extension or Core?

Pick the right format of bug_report.md or extension_bug_report.md

3a. If Core:

• Do you wanna send system details?
• Do you wanna attach latest log file?
• Describe your issue...

Automatically get Surge version

3b. If Extension:

• Just open https://github.com/SurgeDM/Surge/issues/new?template=extension_bug_report.md

[SuperCoolPencil]

Also I feel like since this is opening something new, if triggered via CLI we need to have a confirmation modal asking:

Would you like to file a bug report?

[smazmi]

Hi @smazmi

I would like to know more about the UX for reporting a bug. I wanted it to be something like:

1. `surge bug-report`

2. Extension or Core?

Pick the right format of bug_report.md or extension_bug_report.md

3a. If Core:

* Do you wanna send system details?

* Do you wanna attach latest log file?

* Describe your issue...

Automatically get Surge version

3b. If Extension:

* Just open `https://github.com/SurgeDM/Surge/issues/new?template=extension_bug_report.md`

Thanks, this makes a lot of sense and I agree with the UX direction.
I’ll update surge bug-report to an interactive flow along these lines.
For now, I’ll draft this out and take a closer look at the implementation details.

[SuperCoolPencil]

Amazing. Thanks :)

[smazmi]

Hey @SuperCoolPencil! Sorry for the delay, been a bit tied up with college. I've updated the PR with the interactive flow you described. Here's how it works now:

CLI (surge bug-report):

1. Asks Core or Extension — this doubles as the confirmation you mentioned, since answering it means you clearly intend to file a report
2. If Core → asks if you want system details (OS, version, commit) included → asks if you want the latest debug log path included → asks if you want to open the browser now
3. If Extension → just asks if you want to open the browser now
4. If the browser fails or you say no to opening it, it prints the full URL with a blank line above it so it's easy to copy

TUI (? key):
Same Core/Extension choice, same system details and log path questions — but using the Yep/Nope modal style consistent with the quit confirmation. Since the TUI can't display a long URL readably in the activity log, if the browser fails it logs "Could not open browser. Try running surge bug-report from your terminal instead." and lets the CLI handle it from there.

One thing I wanted to ask — for the CLI flow, I kept it fully interactive for now, but I was also thinking it might be useful to support non-interactive usage via flags (something like --core, --no-system-details, --no-log-path, --yes) so it can be scripted or run in environments without a TTY. I held off on adding them since it felt like scope creep for this PR, but wanted to check if that's something you'd want included here or tracked as a separate issue. Happy to go either way on it.

Let me know what you think!

[SuperCoolPencil]

Hey @smazmi

Honestly I like the current approach but I was just wondering is there no way to attach directly?

What do you feel about just including the whole log file in a codeblock? I'm not sure about this too. Just wanna hear your thoughts

[SuperCoolPencil]

As for the TUI, how about we just put everything into the users clipboard?

I feel like that would be much more convient!

[sonarqubecloud]

Quality Gate failed

Failed conditions
6.0% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[smazmi]

Hey @smazmi

Honestly I like the current approach but I was just wondering is there no way to attach directly?

What do you feel about just including the whole log file in a codeblock? I'm not sure about this too. Just wanna hear your thoughts

@SuperCoolPencil
On the log file - yeah sadly GitHub URLs don't support direct file attachments so that's off the table. But I was thinking we could either paste the full log content into the issue body as a code block, or do something like a tail of the last 50 lines since that's usually what's relevant. Haven't fully decided yet, gonna experiment a bit and see what feels right. One thing that did make me cautious about the embedding approach early on is URL length; the empty template body when encoded already comes out to around ~1500 characters, and browsers/servers start getting unhappy past 2000. Adding even a partial log file on top of that would almost certainly blow past that limit. That's why I initially went with just adding the log file path instead.

On the clipboard idea for TUI - honestly I was thinking the exact same thing, especially for the fallback case. I initially looked into https://pkg.go.dev/golang.design/x/clipboard but their platform docs gave me pause as Wayland is explicitly unsupported and requires an XWayland bridge with DISPLAY set, which isn't something we can rely on for Surge's Linux users. I did some more digging though and came across github.com/tiagomelo/go-clipboard which from my testing seems to actually work on Wayland, so that might be the way to go, either use it as a dependency or just take a look at how it handles Wayland and replicate that approach for our use case. Will look into it more and see if it holds up across all the platforms we care about.

Also I wanted to circle back on the CLI flags - just wanna know what your thoughts are on adding non-interactive flag support (--core, --extension, --no-system-details, --no-log-path, --yes) for scripting and TTY-less environments. Would you want that included here or tracked separately after this merges?

[SuperCoolPencil]

We already use github.com/atotto/clipboard and there are util functions in internal/clipboard/utils.go

Let me know if you need any help

[SuperCoolPencil]

I think command line flags are not a priority for now...

[smazmi]

We already use github.com/atotto/clipboard and there are util functions in internal/clipboard/utils.go

Let me know if you need any help

Thanks for the pointer. Wired it up using internal/clipboard so when the browser fails in the TUI, it copies the URL to the clipboard and logs it, with a terminal hint as the final fallback if the clipboard also fails. Sounds good on the flags, too, we can always revisit that later. Marking it ready for review now!

[SuperCoolPencil]

Thank you so much for contributing! 🚀