Spike: finish the Sentry setup — alerts, server-side capture, releases, and MCP scoping

[danworkman1]

Sentry was wired up in #17: @sentry/browser dynamic-imported in Layout.astro behind the production-hostname gate, environment: 'production', and source maps uploaded via @sentry/vite-plugin (daniel-workmsn / danielworkmandev) with sourcemap: 'hidden'.

That covers sending errors. Everything after "errors are arriving" is still missing. Timebox: half a day.

---

P0 — Fix the org slug first

The org slug is daniel-workmsn; it should be daniel-workman. Decision made: rename it. This goes first because the MCP task below bakes the slug into a path-constrained URL, and Sentry doesn't reserve released slugs — the old one becomes claimable by anyone once it's freed.

• Organization Settings → organization slug → daniel-workman
• Update org: in sentryVitePlugin (astro.config.mjs)
• If SENTRY_AUTH_TOKEN is an org auth token, regenerate it — org tokens embed the old slug, are not auto-revoked, and fail with a misleading A release slug is required error rather than an auth error. A user auth token is unaffected.
• Verify a deploy still uploads maps before moving on

DSNs are not derived from the org slug, so ingestion keeps working throughout and Layout.astro needs no change.

P0 — No alert rules exist

Errors are accumulating with nothing to surface them. This is the gap Sentry's own onboarding leads with, and it's the cheapest thing on this list.

• Create one issue alert on danielworkmandev: new issue → email
• Low-traffic personal site, so skip thresholds/escalation — a plain "new issue" rule is enough

P1 — Server-side errors are not captured at all

output: 'server' with the Cloudflare adapter, plus src/middleware.ts. Anything thrown in the Worker never reaches Sentry, because only the browser SDK is installed. Right now a 500 on SSR is invisible.

• Evaluate @sentry/cloudflare for the Worker side
• Decide explicitly: wire it up, or accept browser-only for a portfolio site and record the decision here

P1 — Source map upload fails silently

disable: !process.env.SENTRY_AUTH_TOKEN means a deploy from a machine without the token produces a green build, no upload, and no warning. Deploys are local (pnpm deploy); CI only runs wrangler deploy --dry-run. With two machines in play this will bite eventually — and it bites later, when a stack trace turns out to be minified.

• Decide where SENTRY_AUTH_TOKEN lives
• Either fail loudly when a production deploy has no token, or move deploys to CI with the token as a repo secret

P2 — No release set

Sentry.init() sets environment but no release. Debug IDs mean source maps still resolve, so traces stay readable — what's lost is regression detection and "first seen in release".

• Set a release (git SHA) in both sentryVitePlugin and init()

P2 — Sentry MCP, scoped to the personal machine

Personal and work Sentry accounts need to stay apart. The remote MCP supports path constraints (/mcp/:org, /mcp/:org/:project) and mints a token that only works for that scoped URL — it can't be replayed against a broader path, and refresh doesn't widen access. That's the mechanism doing the work here, not the machine boundary.

Blocked on the slug rename above — authorising against the old slug means redoing the OAuth flow.

• Personal machine only: add https://mcp.sentry.dev/mcp/daniel-workman at --scope user, named sentry-personal
• Complete the OAuth flow (browser-based, one-off per machine)
• Leave the work org for the work machine later, as sentry-work
• Acceptance: /mcp lists only sentry-personal; it can read danielworkmandev issues and cannot see the work org

Docs: https://mcp.sentry.dev/ · https://github.com/getsentry/sentry-mcp