chore(connectors): offer Airtable and Sentry on commonly.me

docs/plans/integration-readiness-matrix.md

@@ -57,7 +57,7 @@ The matrix below is the definition of "ready". A row is ready when every cell is
 | Linear (hosted MCP) | yes | **Fresh-account walk 2026-10-15 on `cfe91c21`, green** (connector-ops 77850 and 77962; the build is Deploy Dev's last run before the walk): a new commonly.me account and a new Linear workspace, neither connected before. **C1 green**: connected through the Connectors page. Linear's consent read "Read, Identity", the authorize request asked for `read openid`, and the token response granted `read openid` (`config.grantedScope`). **C3 green in an eligible pod**: a read grant of the 36 pinned tools, made through the grant panel, which offers only Read, in the account's own My Workspace. That pod is private and invite-only, with no bridge and Scout as its only agent, so it passes §12's pod rule in `hosted-mcp-connection-scope.md` (#2211). Scout listed the workspace's one team through the grant, the trail records the call ok, and Scout quoted #2206's untrusted-content marker ahead of the data. #2211 deployed after the walk, and the same call was ok again after it, at 16:22:37Z. The earlier C3 and C4 walks ran in the C4 run pod, which fails that rule: since `ff909fb3` the deployed rule returns `pod_joinable` for both of its grants. Partly walked live 2026-10-01 (the owner's account, Chrome). Before the fresh-account walk, C1 was open: the owner's operator-led connect succeeded on `cf9b6abf`, through CIMD with scope `read openid`, and the row records its client and the Linear subject. That didn't prove a stranger connects unaided, and no stranger had tried. **C2 green at 1440, the rest unwalked**: in the fresh-account walk the grant panel offered only Read. Earlier, on `cf9b6abf` the grant rendered as GitHub, because the catalogue projected 0 Linear tools. #2068 (`207c68d5`) fixed it, and on the deployed `e370fe9b` (its descendant) the row reads Linear, with its mark and the read eye, at 1200. 390, a failure reaching Activity, and revoke reachability are unwalked. Earlier, C3 was green in the C4 run pod: Scout listed the team and three issues through `grant_c6af31b8`; the trail showed the calls ok, with the owner as credential owner. **C4 refused by design** from #2211 (the C4 column), and c4-smoke is now offered no Linear tool. Before that it was green (2026-10-09): c4-smoke, a public local claude seat confined by Seatbelt, called `linear.list_teams` through its broker on `grant_e3a1507b` at 06:12:57Z, and the trail shows it ok. Its daemon started at 06:11:59Z, after global cli 0.1.84 (npm latest) was installed at 06:11:41Z, so it runs the current build. An earlier run on 2026-09-27 didn't count, because that daemon predated the cli it should have been running. The same spawn showed that TASK-228's headers helper works under the public Seatbelt profile. A by-name scan of the spawn's claude process found `COMMONLY_TOKEN_FILE` set and `COMMONLY_AGENT_TOKEN` absent. The rest of #2067's consumer proof is unmeasured: the child processes' environments, and a credential rotation followed by a 401 retry succeeding. **C8 open**: in a pod with no grant, Scout is offered no `linear.*` tools. That's confinement by projection. An attempted out-of-pod call, refused and recorded in the trail, hasn't been made. **C9 open**, now only for whether a revoke takes effect at Linear. Linear's revoke is page-only. The fresh-account walk reached the page: `https://linear.app/settings/account/security`, whose Authorized applications list shows the connection as "MCP · Read · Revoke". #2230 points the entry's page there. Before #2230 the entry named `https://linear.app/settings/security`, which is Linear's workspace admin page. Before that walk, every linear.app settings URL redirected to the old workspace's unfinished welcome flow, so the page had not been reached. C5, C6, C7 and C10 are unwalked |
 | Google Calendar (hosted MCP) | yes | **Built, live, not offered.** #2066 (`e370fe9b`) pins the 5 read tools from Google's unauthenticated `tools/list`, with a pre-registered client and `openid` for the account subject. "Not offered" is a **config fact, not a code fact**. The client values arrived on 2026-10-09 (#2111), and the tile was offered until 2026-10-14. OAuth worked, but every tool call failed Google's Developer Preview gate, which is **per Cloud project** (Google named the project in its error on the 2026-10-09 gate test). Since 2026-10-14 `hostedMcp.googleCalendar.enabled` is `false` in values-dev, so the instance holds no client values, the catalogue reports `available: false`, and the page shows "not enabled on this instance" with no Connect. Flip the flag once the project is enrolled and an enrolled `list_calendars` call succeeds. Waiting on the owner: a Workspace seat on the domain and Developer Preview enrollment for the connectors project. The OAuth client already exists in a project of its own (a revoke withdraws every scope a person granted the project) |
 | Atlassian (hosted MCP), writes in #2328 | yes (writes since #2328) | **Deployed, hidden on commonly.me since #2530.** The live build (`19de6035d`, 2026-10-24) carries every change below. `hostedMcp.hiddenEntries` in values-dev leaves the entry out of the catalogue and refuses every connect with `unknown_entry`, a reconnect included (`hostedMcpConnect.ts:251`). **C1 blocked on staging** (2026-10-23, `876870378`, #2536): the site's MCP-server-domain allowlist does not include the staging origin, and only a site admin can add it. The entry pins six Jira and Confluence reads. In a 2026-10-22 walk C3 was red: every call failed with "tools/list could not be verified", which TASK-263 attributed to our client never opening an MCP session. #2397 opens one for each list and call; the C3 re-check after its deploy belongs to TASK-263. #2328 adds five named writers: `update_confluence_content`, `create_jira_issue`, `edit_jira_issue`, `transition_jira_issue` and `add_or_edit_jira_issue_comment`, the last marked irreversible. Each is pinned `write`, so every write parks for the connection's owner with its exact arguments, and runs only under the definition it parked under (#2378). The entry now requests write scopes, so a row connected before #2328 holds a token that cannot write, and its owner must reconnect, which the hide refuses until it is lifted. **C4 refused by design** (the C4 column). The walk's checks are below |
-| Sentry (hosted MCP), #2329 | yes (#2329) | **Deployed, hidden on commonly.me since #2530**, the same way as Atlassian. Since #2649 and #2658 the hide has a walk exception for one account. **C0, C1 and C2 green on staging, each with a part #2536 did not record** (2026-10-23, `876870378`). Staging has no agent runtime, so C3, C6 and C9 were not walked there. **C3 green on commonly.me except the page comparison** (2026-10-25, `c9c0d71c1`): a hosted agent read through a pod grant, and the trail records the call ok. **C9's "cannot do more than granted" green for a read grant**: the agent was offered the 11 reads and no write tool. Whether a revoke takes effect, at Sentry included, is not walked, and neither is C6 (the commonly.me walk below). #2329 pins 11 named reads and `update_issue`, an irreversible write that parks for the connection's owner with its exact arguments. `get_sentry_resource` is pinned without the vendor's `url` argument, and the vendor's dispatcher, its catalogue and Seer are left out, as ruled in the PR thread. The client is CIMD, and the entry requests five scopes, four of them write. **C4 refused by design** (the C4 column). The walk's checks are below |
+| Sentry (hosted MCP), #2329 | yes (#2329) | **Deployed. Hidden on commonly.me from #2530, and offered again by the connect-and-read unhide** (still open on TASK-308: C6, and three C9 arms: the 12 `write-with-confirm` tool bounds, whether `get_sentry_resource` is offered without `url`, and a revoke taking effect). While hidden, #2649 and #2658 gave it a walk exception for one account; that key left the allowlist overlay with the unhide. **C0, C1 and C2 green on staging, each with a part #2536 did not record** (2026-10-23, `876870378`). Staging has no agent runtime, so C3, C6 and C9 were not walked there. **C3 green on commonly.me except the page comparison** (2026-10-25, `c9c0d71c1`): a hosted agent read through a pod grant, and the trail records the call ok. **C9's "cannot do more than granted" green for a read grant**: the agent was offered the 11 reads and no write tool. Whether a revoke takes effect, at Sentry included, is not walked, and neither is C6 (the commonly.me walk below). #2329 pins 11 named reads and `update_issue`, an irreversible write that parks for the connection's owner with its exact arguments. `get_sentry_resource` is pinned without the vendor's `url` argument, and the vendor's dispatcher, its catalogue and Seer are left out, as ruled in the PR thread. The client is CIMD, and the entry requests five scopes, four of them write. **C4 refused by design** (the C4 column). The walk's checks are below |
 | next app | no | Open decision; see below |
 
 ## Staging connector walk — 2026-10-23 on `876870378`
@@ -176,7 +176,7 @@ The test gate on "Scout (Default)" was switched back off after the walk. On the
 
 ## Walk checks: Atlassian writes and Sentry
 
-What a walk checks for the two entries above: C1, C3, C6, C8 and C9 for Atlassian writes, and C0 to C3, C6 and C9 for Sentry. C4 is refused by design for both until TASK-213, so it is not walked. The staging walk of 2026-10-23 (above, #2536) filled the cells staging can reach. Staging has no agent runtime, so a cell that needs an agent to call a tool waits for a walk on commonly.me. #2536 keeps both entries hidden there until that walk passes; the values-dev comment that hides them (#2530) still says a staging walk. A hidden entry refuses every connect, a reconnect included, and every new root grant, from every account but those its walk exception names (#2649, #2658; `docs/runbooks/hosted-mcp-hidden-entry-walks.md`). Sentry's commonly.me walk (above) ran that way, with the hide in place. Each result reads `unverified` until a walk replaces it with what it saw and a link to the evidence. Method rules 1 and 2 hold: a stranger account's own session, and every UI cell at 1200 and 390. #2536 does not record which widths it walked.
+What a walk checks for the two entries above: C1, C3, C6, C8 and C9 for Atlassian writes, and C0 to C3, C6 and C9 for Sentry. C4 is refused by design for both until TASK-213, so it is not walked. The staging walk of 2026-10-23 (above, #2536) filled the cells staging can reach. Staging has no agent runtime, so a cell that needs an agent to call a tool waits for a walk on commonly.me. #2536 kept both entries hidden until that walk passed. Sentry is offered since its connect-and-read walk passed (a Cofounder ruling, 2026-11-01); C6 and the open C9 arms in its row stay on TASK-308. Atlassian stays hidden, and the values-dev comment that hides it (#2530) still says a staging walk. A hidden entry refuses every connect, a reconnect included, and every new root grant, from every account but those its walk exception names (#2649, #2658; `docs/runbooks/hosted-mcp-hidden-entry-walks.md`). Sentry's commonly.me walk (above) ran that way, with the hide in place. Each result reads `unverified` until a walk replaces it with what it saw and a link to the evidence. Method rules 1 and 2 hold: a stranger account's own session, and every UI cell at 1200 and 390. #2536 does not record which widths it walked.
 
 **A staging green is not a commonly.me green.** Ready means green on commonly.me against the deployed build, so a cell that passes here is recorded as green on staging. Like "green to the external boundary", it keeps that mark when it is copied into the rows above, and it turns green when the same check passes on commonly.me (Method rule 5).
 

k8s/helm/commonly/values-dev.yaml

@@ -442,14 +442,15 @@ hostedMcp:
     # Not walked end to end on staging before the 10-23 deploy; unwalked entries ship hidden.
     # Remove each line once its staging walk passes.
     - atlassian
-    - sentry
+    # Sentry passed connect and read: C0-C2 on staging with a non-admin user (10-23), C3 live
+    # on prod (10-25), so it is offered. TASK-308 still owes the write-with-confirm arm (C6)
+    # and the open C9 arms listed in the matrix. Its allowlist key left the overlay secret with this change.
     # Added by #2429. Hidden until each is walked end to end.
     - notion
     - gitlab
     - supabase
-    # The 10-27 prod walk failed before Airtable's consent screen ("invalid client_id
-    # or mismatched redirect_uri"). Hidden until TASK-318 lands and a walk passes.
-    - airtable
+    # Airtable passed a live prod walk on 10-31 (TASK-307: connect, a list_bases call,
+    # grant revoke, disconnect), so it is offered. Its allowlist key left the overlay secret too.
     # Hidden until a fresh non-admin account walks connect, grant, call and
     # refusal end to end (TASK-290). That account joins the runner-only allowlist overlay (#2950).
     - github-mcp