Root-cause with the evidence, not the guess

A Sentry issue is a claim about what broke. The job is to turn it into a claim
about why it broke, backed by the event data, before anyone edits code.

1. Get the real issue, not the search hit

A pasted URL or short ID (PROJECT-123) goes straight to get_issue_details.
A described error ("users can't check out") goes through search_issues first,
but treat the results as candidates: match on the error type and the affected
code path, not on title similarity. If two issues share a message but differ in
stack trace, they are two bugs.

2. Read the stack trace like a diff

Fetch the newest event's stack trace. The top frame is where it crashed, not
where it broke — walk down until you leave library code and hit the first
frame owned by this repo. That frame and its local variables are the starting
point. Cross-check the file against the working tree: production runs a
release, and the line numbers may belong to code that has since changed.
find_releases tells you which version the events come from.

3. Use the distribution before the theory

Before proposing a cause, check what the events have in common:

• Tags (get_issue_tag_values): one browser, one endpoint, one tenant, one
  release? A bug scoped to a dimension names its own trigger.
• Breadcrumbs: what the user did right before. A crash after a retry storm
  is a different bug than the same crash on first click.
• First seen / volume: an issue that started with a release points at that
  release's diff. One that grew slowly points at data or traffic.

Seer (analyze_issue_with_seer) is worth running for a second opinion, but
verify its suggested cause against the frames yourself before repeating it.

4. Report cause, scope, and blast radius

The finding is three sentences: what fails, why, and who it hits (volume,
affected users, releases). Link the issue. If the user asks for a fix, fix the
frame you identified — and only then consider update_issue to assign or
resolve, never as a way to make the dashboard quiet.

Anti-patterns

• Fixing the top frame. The top frame is often a library that faithfully
  threw on bad input from three frames below.
• Trusting the issue title. Sentry titles are the exception message; two
  different bugs can share one, and grouping is heuristic.
• Reading one event. One event is an anecdote; the tag distribution is the
  evidence.
• Resolving without a shipped fix. A resolved issue that regresses comes
  back as a new-looking issue and erases its history.