Evaluate privacy-safe crash reporting for the Raycast extension

[altaywtf]

Outcome

Make and document an explicit decision about external crash reporting for the public Raycast extension. If approved, add minimal coverage that complements rather than duplicates Raycast's own diagnostics.

Context

An audit of main 6e7e5da found no Sentry or equivalent project-owned crash-reporting integration. The extension runs multiple commands for files, search, transfers, and history and stores an app-specific password in Raycast preferences.

Before adding another telemetry SDK, establish what Raycast already captures, what extension authors can access, and what Raycast Store policies/disclosures permit. The extension is public, and its commands can encounter private filenames, search queries, transfer links, magnet URIs, history data, and credentials.

Decisions to record

• Whether Raycast's platform diagnostics already provide sufficient actionable error visibility.
• Whether project-owned crash reporting is justified, and if so whether it is opt-in or enabled with disclosure.
• Provider/hosting, retention, ownership, source-map handling, and Raycast Store/privacy requirements.
• Which command/runtime boundaries require coverage without double-reporting handled API errors.

Acceptance criteria

• The repository records the decision and evidence about Raycast's built-in diagnostics and applicable Store policy.
• If external reporting is approved, unexpected command/render errors and unhandled rejections are captured exactly once with extension version and command name.
• Expected API/auth errors remain user-facing and are not promoted to unexpected crash issues.
• Payloads exclude the app-specific password, Authorization headers, API bodies, filenames, search text, transfer/download URLs, magnet URIs, history content, and user-entered arguments.
• No provider secret is bundled in the public extension; source-map publication/upload is explicit.
• If external reporting is declined, the issue records the support/debugging alternative and closeout rationale.

Non-goals

• Product analytics
• Session replay
• Capturing command inputs or account content
• Replacing Raycast's user-visible error handling

Verification

• Run pnpm run verify.
• If implemented, run pnpm run dev and trigger sanitized synthetic failures in representative view and action commands.
• Inspect built output and captured events for credentials and user/account content.
• Verify the behavior against the current Raycast extension publishing rules before release.

Risks and stop conditions

• Stop before implementation if Raycast already provides equivalent diagnostics or disallows the intended collection/disclosure model.
• Do not ship external telemetry without a settled privacy/consent posture.