Sentry connector setup

Sentry does not fit the "bring your own OAuth app" shape every other page beside this one describes. There is no client id, no client secret, no authorization-code redirect and therefore no docs/connectors/README.md botseon oauth-app set step for it. Instead, a Sentry organization member creates a personal or org-level auth token directly in Sentry's own settings and that token is what this connector's calls carry as a bearer token.

1. Create the auth token in Sentry

1. In Sentry, go to Settings -> Auth Tokens (organization-level, not a personal API key) and create a new token.
2. Grant it the scopes this connector's tools need (F-PLUG-1):
   • org:read, project:read, event:read — list projects, list issues, read one issue, read its events, and read organization stats. This is CONNECTOR_SCOPE_SETS.sentry.read (packages/core/src/connector-catalog.ts). This connector ships no write tool yet — see §4 — so there is no write scope to grant.
3. Copy the token. Sentry shows it once.

2. The organization slug

Every list and read tool is scoped to one Sentry organization, named by its slug — the part of the Sentry URL after /organizations/. This is a per-installation plugin variable (PLUGIN_VARIABLES.sentry, kind string), the same mechanism Zendesk's subdomain uses: the driver reads it off call.variables.organizationSlug, resolved by the run loop immediately before the call, and every call refuses with a named-variable error until it is set.

3. What each tool does

This connector is read-only today. There is no sentry.update_issue_status (or any other write) tool yet — see §4 for why, and what it is waiting for.

4. The gap this page cannot close, and why this connector installs available: false

This connector's catalogue row (packages/db/seed/catalogue.json) ships available: false: a member cannot install it yet. That is D512's auth half (connector kit spec §0), applied here, and it becomes installable in one later commit — a seed edit and a hash — once the API-key account path lands (the connector kit spec's §8). Here is the gap that path closes:

Every other connector's account gets its credentials.accessToken from the OAuth token/refresh framework in packages/connectors/src/tokens.ts and oauth.ts, fed by botseon oauth-app set and the plugin sheet's Authorise redirect. Sentry's auth token has no such exchange to plug into — it is issued once, directly, and does not refresh — so there is currently no in-repo path by which a member's pasted Sentry token becomes an accounts row with a decryptable token this driver's TokenStore can hand to execute.

Closing that gap means a "paste a token" connection path beside the existing "Authorise" redirect one: touching packages/connectors/src/oauth.ts and tokens.ts (or a sibling module) for the storage side, apps/cli's oauth-app command family or a new one for the operator side, and the plugin sheet under apps/web for the member-facing form. None of those files belong to this connector's own task, so this page stops here rather than improvising one: until that lands, an operator who wants to exercise this connector against a real organization has to provision an accounts row for it by hand, with the auth token in place of a refreshable OAuth grant, through whatever privileged path the deployment already has for that.

The driver itself does not care how credentials.accessToken arrived — every request sends it as Authorization: Bearer <token>, exactly like every other connector in this package — so nothing above changes once the connection path exists.