Diagnose: minified stack traces with no source context

# Diagnose: minified stack traces with no source context

## Step 1: does the deployed bundle have Debug IDs?

Sentry links maps by Debug IDs injected into build output. Fetch your production bundle and search for a debug ID comment. Absent means the build never injected them: run `npx @sentry/wizard@latest -i sourcemaps` and confirm you ship a production build (dev builds typically skip map generation).

## Step 2: did the upload land before the error?

Artifacts uploaded after the error cannot symbolicate it. Check the upload step's timestamp against the first-seen time of the issue. Also check the upload actually succeeded: `SENTRY_ALLOW_FAILURE` lets a failed upload pass CI silently, which hides breakage for weeks.

## Step 3: does the release match?

The upload's release (and dist, if you use it) must equal the release the running code reports. Compare the CLI `--release` value with the SDK `release` or `SENTRY_RELEASE`. A `v` prefix in one and not the other is enough to break the link.

## Step 4: is the artifact in the project?

Open the issue, take the debug ID from a frame, and search Project Settings > Source Maps / Debug Files for it. ID on the event but no artifact means the upload went to the wrong org or project (check SENTRY_ORG/SENTRY_PROJECT). No ID on the event means step 1 failed.

## Verify

Trigger a fresh error after the fix and confirm frames resolve to real file names and line numbers. Old issues will not re-symbolicate retroactively for already-stored events; only new events prove the pipeline.