Add opt-in Sentry crash reporting

[GrillerGeek]

Summary

• Adds opt-in crash reporting (Rust panics + WebView/JS errors) via Sentry, gated behind a first-run consent banner and a Settings toggle.
• Consent is Rust-owned (a JSON file read synchronously, pre-tauri::Builder, since no AppHandle exists yet); changes take effect on next launch, never mid-session.
• Both SDKs scrub PII before send (no default PII, no automatic breadcrumbs, path/username redaction, no terminal/PTY/env/repo-path capture). The Sentry DSN is compiled in only at CI release build time — absent in dev builds and forks, so telemetry stays fully inert unless the maintainer provisions a DSN.

Plan reference

• Design spec: docs/superpowers/specs/2026-07-23-crash-reporting-design.md
• Quest plan (full review/fix history): docs/guildhall/plans/2026-07-23-crash-reporting.md

Test plan

• cargo test — 25/25 passing (includes 5 new scrubber-shape tests)
• npx vitest run — 96 passing (+7 pre-existing store.notes.test.ts failures, unrelated localStorage.clear environment issue reproducible on a clean checkout)
• npm run build and tsc --noEmit — clean
• @sentry/browser confirmed dynamically imported behind active_this_session (main bundle ~332KB → ~246KB)
• Manual, first release only: trigger a real Rust panic and a real JS error on a DSN-bearing build; confirm both arrive in Sentry scrubbed and with symbolicated (readable) stack traces

Reviewer notes

Six specialist reviewers plus the IDD tech-lead gate ran on this branch. Three HIGH findings surfaced after the first green build; all three were fixed in a scoped second round and re-verified CLOSED by the reviewers who originally raised them:

• Security — DOM click/nav breadcrumbs bypassed both scrubbers and could carry absolute paths/usernames/branch names into events. Fixed: the JS Breadcrumbs integration was dropped entirely, and Rust-side scrub_event now scrubs event.breadcrumbs as defense-in-depth.
• Observability — a failed consent write in the banner was silently swallowed (optimistic dismiss, unhandled rejection). Fixed: failures now revert to unset and surface a toast.
• Performance/Reliability — sentry::init on the pre-Builder path does blocking TLS-transport construction, and the default transport had no timeouts (panic-time flush could hang a dying process against a black-holed endpoint). A custom transport with connect/request timeouts was added. Lazy/deferred construction was evaluated and rejected as unverifiable against sentry 0.42's private worker/flush semantics. Accepted trade-off: a one-time bounded TLS-transport build (estimated ≤~20ms) remains on startup, but only for opted-in users on DSN-bearing builds.

Other accepted, by-design trade-offs (documented, not defects):

• Native crashes (SIGSEGV/abort) are not covered — only Rust panics and JS exceptions are captured; minidump collection is deliberately off.
• Events queued at normal process exit are not flushed (verified this does not hang shutdown).
• If Sentry is unreachable, events are dropped silently rather than retried (fail-closed by design).

Open items:

• Run cargo tree -e features -p sentry as a sanity check — Cargo.lock shows sentry-actix/actix-web entries that should not be compiled in (performance reviewer info-level flag, unconfirmed).
• The pre-existing src/state/store.notes.test.ts failure (7 tests, localStorage.clear not a function) is untouched by this branch and fails on a clean checkout too.

Runbook

Deploy plan

Before tagging a release: create the Sentry org/project (choose the US or EU data region), and enable the "do not store IP addresses" project setting so behavior matches the README's privacy claim. Add four repo secrets — SENTRY_AUTH_TOKEN, SENTRY_ORG, SENTRY_PROJECT, and AGENTPANEL_SENTRY_DSN — the DSN is injected into the tauri-action build environment in release.yml; if it's empty the build compiles telemetry-inert, and forks without the secret stay fail-closed automatically. Release version strings are aligned to agentpanel@<version> across the Rust SDK, the JS SDK, and the CI source-map upload step (previously mismatched, which would have prevented JS stack traces from ever symbolicating).

What to watch (first 48h)

Confirm the source-map upload step succeeds in the release workflow. Check that the first WebView-originated event in Sentry shows readable, symbolicated frames rather than minified ones. Watch Sentry's Stats/Usage view against the 5k-events/month free-tier ceiling, and watch the Issues-to-Events ratio specifically — there is no client-side sampling, so a single crash-looping install can burn the monthly quota on its own. Because updater uptake is slow, near-silence in the first hours is expected and not itself a signal of failure. Remember the GitHub release is created as a draft and must be manually published before the updater will surface it to existing installs.

Rollback plan

The updater is forward-only — there is no way to roll an already-updated install back to a prior version. To stop ingestion instead, revoke or regenerate the DSN's client key in the Sentry project; this halts ingestion for all shipped versions instantly, at the cost of needing a new DSN (and a follow-up release) to resume. Short of full revocation, per-key rate limits and Sentry's Spike Protection are the available throttles.

On-call notes

No Sentry alert rules exist yet, and there is no paging integration configured — set this up post-merge, before relying on Sentry for incident detection.

🤖 Generated with Claude Code