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

This PR adds a surge bug-report CLI command and a ? TUI keybinding that each open a pre-filled GitHub issue URL containing OS, architecture, version, and commit metadata. The implementation is clean: a new internal/bugreport package builds the URL, utils.OpenBrowser handles launching the browser, and browser failures gracefully print the raw URL as a fallback.

There are no blocking issues. Two minor style observations are noted below.

Confidence Score: 5/5

Safe to merge — no blocking issues found; prior review concerns have been addressed.

All findings are P2 style observations. The URL-building logic is correct, error handling is graceful, the variadic signature change is backward-compatible with existing tests, and the ldflag wiring matches the build system. The two P2 notes (unreachable guard and TUI code-path inconsistency) are non-blocking cleanup items.

No files require special attention.

Important Files Changed

Filename	Overview
cmd/bugreport.go	New CLI subcommand that builds the issue URL, prints intent, opens the browser, and falls back gracefully on error. Logic is correct.
internal/bugreport/bugreport.go	Builds a pre-filled GitHub issue URL with OS, arch, version, and commit. URL encoding is handled correctly via url.Values; empty inputs normalise to "unknown".
internal/bugreport/bugreport_test.go	Good coverage of expected fields, special-character round-tripping, and empty/whitespace normalisation.
internal/utils/open.go	Added OpenBrowser (validates non-empty URL, delegates to openWithSystem). Duplicate OpenURL removed as per prior review feedback.
internal/utils/open_test.go	Tests empty and whitespace URL rejection for OpenBrowser. Coverage is adequate for validation logic.
internal/tui/update_dashboard.go	Adds ? key handler for bug reporting. Log entry is emitted before OpenBrowser is called; fallback URL is shown on failure.
internal/tui/keys.go	Added ReportBug binding to ? and included it in FullHelp(). Struct definition and key map initialisation are consistent.
internal/tui/model.go	Added CurrentCommit field and wired the variadic currentCommit parameter into InitialRootModel, maintaining backward compat with existing tests.
cmd/root.go	Wired Commit build-var with debug.ReadBuildInfo fallback and passes it through to InitialRootModel. Logic is correct and idiomatic.
cmd/connect.go	Updated newRemoteRootModel to pass Commit to InitialRootModel. Minimal, correct change.
.goreleaser.yaml	Adds -X cmd.Commit and -X cmd.BuildTime ldflags so release builds inject the correct values. No issues.
docs/USAGE.md	Added surge bug-report row to the command table with a concise description and fallback note. Consistent with existing table style.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A([User triggers bug report]) --> B{Entry point}
    B -- "surge bug-report (CLI)" --> C[cmd/bugreport.go]
    B -- "Press ? in TUI dashboard" --> D[update_dashboard.go ReportBug handler]

    C --> E[bugreport.BugReportURL\nversion, commit]
    D --> E

    E --> F{URL empty?}
    F -- "No (always)" --> G[utils.OpenBrowser URL]
    F -- "Yes (unreachable)" --> H1[CLI: return error / TUI: log error entry]

    G --> I{Browser opened?}
    I -- Success --> J[Done]
    I -- Failure --> K1[CLI: print raw URL to stdout]
    I -- Failure --> K2[TUI: log raw URL as fallback]

    subgraph bugreport.BugReportURL
        L[url.Parse hardcoded GitHub URL]
        L --> M[fmt.Sprintf body OS / arch / version / commit]
        M --> N[url.Values.Encode params]
        N --> O[Return full issue URL]
    end

Loading

Prompt To Fix All With AI

This is a comment left during a code review.
Path: internal/tui/update_dashboard.go
Line: 221-224

Comment:
**Inconsistent URL-opening pattern within the TUI package**

The new bug-report handler calls `utils.OpenBrowser`, but the existing URL-opening call in `update_modals.go` (line 152 — opening the GitHub release page) still calls the TUI-local `openWithSystem` directly. The two local `openWithSystem` implementations (in `internal/tui/commands.go` and `internal/utils/open.go`) are functionally identical, so there are now two code paths for the same operation within the same package.

For consistency with the pattern introduced here, `update_modals.go:152` could also be migrated to `utils.OpenBrowser`, and the TUI-local `openWithSystem` could be removed entirely in favour of the shared utility.

**Rule Used:** What: Eliminate duplicate logic, functions, or cod... ([source](https://app.greptile.com/review/custom-context?memory=f0a796a9-684f-4dfb-a5cf-8c99c16b63a1))

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

---

This is a comment left during a code review.
Path: cmd/bugreport.go
Line: 18-21

Comment:
**Unreachable empty-URL guard**

`BugReportURL` only returns `""` if `url.Parse(newIssueURL)` fails, but `newIssueURL` is the hardcoded constant `"https://github.com/SurgeDM/Surge/issues/new"` — a string that `url.Parse` will never reject. The same guard in `update_dashboard.go` (line 215) is equally unreachable.

This isn't harmful, but it adds misleading dead-code branches. If the intent is to make the zero-value signal meaningful for future callers, consider documenting that invariant in a comment on `BugReportURL` instead.

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

_{Reviews (4): Last reviewed commit: "fix: log bug-report browser intent befor..." | Re-trigger Greptile}

[github-actions]

Binary Size Analysis

⚠️ Size Increased

Version	Human Readable	Raw Bytes
Main	18.98 MB	19898660
PR	18.98 MB	19906852
Difference	8.00 KB	8192

[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?