Problem
Most `captureError`/`captureReviewFailure` call sites in `src/selfhost/sentry.ts` (used across the queue backends, the AI-review pipeline, and the agent action executor) pass the raw caught/constructed error straight to `Sentry.captureException`. Sentry derives an issue's title from the error's own `.name` + `.message`, so every one of these becomes a generic "Error: ..." title, or — for a genuinely caught library exception like an Octokit request failure — "HttpError: ...", regardless of what actually went wrong (a dead-lettered job, a blocked merge, an inconclusive AI review, an unreachable relay, etc).
This makes the Sentry issue list nearly useless for triage: dozens of unrelated failure modes all collapse into a handful of "Error"/"HttpError" buckets, and distinguishing them requires opening every issue and reading the message/context by hand.
Contrast with `forwardStructuredLogToSentry` in the same file, which already sets `errorEvent.name = event ?? "GittensoryLog"` for structured `console.error(JSON.stringify({event, ...}))` logs — those get descriptive titles today. The direct `captureError`/`captureReviewFailure` call sites never got the same treatment.
Fix
Give `captureError`/`captureReviewFailure` an optional third `eventName` parameter that renames the captured error before it reaches Sentry — mirroring `forwardStructuredLogToSentry`'s existing discipline. Thread a descriptive slug (e.g. `processing_timeout`, `agent_merge_blocked`, `ai_review_inconclusive`) through every call site that constructs its own `new Error(...)` to report a known condition, and through call sites capturing a genuinely caught exception where a stable category name is more useful for grouping than the exception's own class (e.g. an Octokit `HttpError` from a blocked merge, which should group as "agent_merge_blocked" regardless of which HTTP status caused it — the status/reason stays in the message and context either way).
Problem
Most `captureError`/`captureReviewFailure` call sites in `src/selfhost/sentry.ts` (used across the queue backends, the AI-review pipeline, and the agent action executor) pass the raw caught/constructed error straight to `Sentry.captureException`. Sentry derives an issue's title from the error's own `.name` + `.message`, so every one of these becomes a generic "Error: ..." title, or — for a genuinely caught library exception like an Octokit request failure — "HttpError: ...", regardless of what actually went wrong (a dead-lettered job, a blocked merge, an inconclusive AI review, an unreachable relay, etc).
This makes the Sentry issue list nearly useless for triage: dozens of unrelated failure modes all collapse into a handful of "Error"/"HttpError" buckets, and distinguishing them requires opening every issue and reading the message/context by hand.
Contrast with `forwardStructuredLogToSentry` in the same file, which already sets `errorEvent.name = event ?? "GittensoryLog"` for structured `console.error(JSON.stringify({event, ...}))` logs — those get descriptive titles today. The direct `captureError`/`captureReviewFailure` call sites never got the same treatment.
Fix
Give `captureError`/`captureReviewFailure` an optional third `eventName` parameter that renames the captured error before it reaches Sentry — mirroring `forwardStructuredLogToSentry`'s existing discipline. Thread a descriptive slug (e.g. `processing_timeout`, `agent_merge_blocked`, `ai_review_inconclusive`) through every call site that constructs its own `new Error(...)` to report a known condition, and through call sites capturing a genuinely caught exception where a stable category name is more useful for grouping than the exception's own class (e.g. an Octokit `HttpError` from a blocked merge, which should group as "agent_merge_blocked" regardless of which HTTP status caused it — the status/reason stays in the message and context either way).