v0.9.54: non-OAuth auth for twelve more integrations, agent API additions (workflow outline, schedules list, paused runs, scoped CLI pairing keys), concurrent-edit guard, dependency updates

Author: waleedlatif1

.agents/skills/v2-api-conventions/SKILL.md

@@ -11,7 +11,7 @@ The v2 surface makes one promise: **every response is the same two shapes, and a
 ```
 success (single)      { "data": {...} }
 success (collection)  { "data": [...], "nextCursor": "..." | null }
-failure (always)      { "error": { "code": "...", "message": "...", "details"?: ... } }
+failure (always)      { "error": { "code": "...", "message": "...", "details"?: ..., "requestId"?: "..." } }
 ```
 
 Nothing else at the top level. No `success: true`, no bare `{ "error": "string" }`, no HTML.
@@ -214,7 +214,7 @@ The consequence to keep true: **never put a resource id, filter, or scope into a
 
 Run this against any new or changed v2 endpoint.
 
-- [ ] Success body is exactly `{data}` or `{data, nextCursor}`; failures are exactly `{error:{code,message,details?}}`.
+- [ ] Success body is exactly `{data}` or `{data, nextCursor}`; failures are exactly `{error:{code,message,details?,requestId?}}`, where `v2Error` alone sets `requestId` (the `x-request-id` value).
 - [ ] Route uses a shared builder; no hand-built `NextResponse.json`.
 - [ ] Query and body schemas are `.strict()`.
 - [ ] The contract declares a `query` — `noInputSchema` when the endpoint takes no query params, never omission.

.github/CI.md

@@ -1,6 +1,6 @@
 # CI selection and acceptance ownership
 
-The `changes` job runs Turborepo 2.9.14's `affectedTasks` query before installing application dependencies or provisioning services. `turbo.json` records package dependency propagation; `apps/sim/turbo.json` partitions the app into shared runtime, server, workspace UI, and acceptance tasks. `.github/ci-suites.json` turns those tasks into job matrices. The uploaded `ci-plan` artifact names changed files, selected tasks, attribution reasons, and any fallback.
+The `changes` job runs Turborepo 2.11.10's `affectedTasks` query before installing application dependencies or provisioning services. `turbo.json` records package dependency propagation; `apps/sim/turbo.json` partitions the app into shared runtime, server, workspace UI, and acceptance tasks. `.github/ci-suites.json` turns those tasks into job matrices. The uploaded `ci-plan` artifact names changed files, selected tasks, attribution reasons, and any fallback.
 
 A PR compares the checked-out GitHub merge commit with its first parent: the actual target revision tested by that merge. The PR event's base SHA can become stale when the target advances. Scoping requires a matching GitHub merge ref and SHA, exactly two merge parents, and a usable target parent; otherwise every check runs. This works with the existing depth-two checkout without fetching older ancestry. Main/staging pushes execute all checks; the parent `ci` workflow skips checks on `dev` pushes, while PRs targeting `dev` still run checks. A manual `checks` run executes all checks unless supplied a full base commit SHA to reproduce a scoped plan. Missing history, an empty diff, unknown files outside the workspace graph, root script/CI changes, or a planner error run every check. Missing selection outputs fail the aggregate gate. The gate also rejects an omitted dependency, any failed/cancelled job, and any skip that its explicit selection flag did not authorize.
 
@@ -24,7 +24,7 @@ Integration also depends on workspace UI because the desktop executor integratio
 
 SEO depends on workspace UI and server code: landing pages reuse workspace pricing and preview components, provider models/pricing, and the block registry. These directory boundaries are not isolated application dependency graphs.
 
-`affectedTasks` already uses task inputs. Do not enable `futureFlags.affectedUsingTaskInputs` just for this planner: that flag also changes pruning, which can pull CI-only cross-app task dependencies into production Docker contexts.
+`affectedTasks` matches task inputs only under a task-level future flag; without one it reports every task of an affected package. The root `turbo.json` enables `futureFlags.filterUsingTasks`, which CI's package-name `--filter` calls are unaffected by. Do not use `futureFlags.affectedUsingTaskInputs` instead: that flag also changes pruning, which pulls CI-only cross-app task dependencies into production Docker contexts. `affectedTasks.items` also lists the prerequisites of affected tasks, so the planner selects `docs#build` through its own task filter, which applies before prerequisites are added.
 
 Affected type-checks follow the package graph too; repository audits and lint run whenever the checks workflow runs. Workspace-only unit jobs use a free GitHub runner and do not start the app test shards.
 

.github/scripts/ci-plan.gql

@@ -22,4 +22,10 @@ query($base: String!, $head: String!) {
       }
     }
   }
+  # `items` also lists the prerequisites of affected tasks, and docs#build is one for
+  # ci:e2e-docs-platform. The task filter applies before prerequisites are added, so this
+  # selection holds docs#build only when the docs site itself changed.
+  docsSite: affectedTasks(base: $base, head: $head, tasks: ["docs#build"]) {
+    items { fullName }
+  }
 }

apps/desktop/package.json

@@ -58,7 +58,7 @@
     "@types/react": "^19",
     "@types/react-dom": "^19",
     "electron": "43.8.1",
-    "electron-builder": "26.15.3",
+    "electron-builder": "26.18.0",
     "esbuild": "0.28.2",
     "jsdom": "^26.0.0",
     "postcss": "^8.5.30",

apps/docs/components/ui/icon-mapping.ts

@@ -409,6 +409,7 @@ export const blockTypeToIconMap: Record<string, IconComponent> = {
   credential: CredentialIcon,
   credential_group: GridOffset,
   crowdstrike: CrowdStrikeIcon,
+  crowdstrike_v2: CrowdStrikeIcon,
   crunchbase: CrunchbaseIcon,
   crunchbase_v2: CrunchbaseIcon,
   cursor: CursorIcon,
@@ -418,6 +419,7 @@ export const blockTypeToIconMap: Record<string, IconComponent> = {
   databricks: DatabricksIcon,
   databricks_v2: DatabricksIcon,
   datadog: DatadogIcon,
+  datadog_v2: DatadogIcon,
   datagma: DatagmaIcon,
   daytona: DaytonaIcon,
   daytona_v2: DaytonaIcon,
@@ -487,6 +489,7 @@ export const blockTypeToIconMap: Record<string, IconComponent> = {
   gmail: GmailIcon,
   gmail_v2: GmailIcon,
   gong: GongIcon,
+  gong_v2: GongIcon,
   google_ads: GoogleAdsIcon,
   google_appsheet: GoogleAppsheetIcon,
   google_bigquery: GoogleBigQueryIcon,
@@ -658,6 +661,7 @@ export const blockTypeToIconMap: Record<string, IconComponent> = {
   plane: PlaneIcon,
   plane_v2: PlaneIcon,
   planetscale: PlanetScaleIcon,
+  planetscale_v2: PlanetScaleIcon,
   polymarket: PolymarketIcon,
   postgresql: PostgresIcon,
   posthog: PosthogIcon,
@@ -703,6 +707,7 @@ export const blockTypeToIconMap: Record<string, IconComponent> = {
   s3: S3Icon,
   s3_v2: S3Icon,
   sailpoint: SailPointIcon,
+  sailpoint_v2: SailPointIcon,
   salesforce: SalesforceIcon,
   sap_concur: SapConcurIcon,
   sap_s4hana: SapS4HanaIcon,
@@ -719,6 +724,7 @@ export const blockTypeToIconMap: Record<string, IconComponent> = {
   serper: SerperIcon,
   servicenow: ServiceNowIcon,
   servicenow_v2: ServiceNowIcon,
+  servicenow_v3: ServiceNowIcon,
   ses: SESIcon,
   ses_v2: SESIcon,
   sftp: SftpIcon,
@@ -823,12 +829,14 @@ export const blockTypeToIconMap: Record<string, IconComponent> = {
   youtube: YouTubeIcon,
   youtube_v2: YouTubeIcon,
   zendesk: ZendeskIcon,
+  zendesk_v2: ZendeskIcon,
   zep: ZepIcon,
   zep_v2: ZepIcon,
   zerobounce: ZeroBounceIcon,
   zoho_desk: ZohoDeskIcon,
   zoom: ZoomIcon,
   zoominfo: ZoomInfoIcon,
+  zoominfo_v2: ZoomInfoIcon,
 }
 
 export const coreBlockTypes = new Set([

apps/docs/content/docs/api-reference/(generated)/workflow-runs/meta.json

@@ -1,6 +1,7 @@
 {
   "pages": [
     "listWorkflowRunsV2",
+    "listPausedWorkflowRunsV2",
     "getWorkflowRunV2",
     "downloadWorkflowRunFileV2",
     "resumeWorkflowRunV2",

apps/docs/content/docs/api-reference/(generated)/workflows/meta.json

@@ -9,6 +9,7 @@
     "duplicateWorkflow",
     "moveWorkflows",
     "getWorkflowState",
+    "getWorkflowOutline",
     "replaceWorkflowState",
     "applyWorkflowOperations",
     "applyWorkflowVariables",
@@ -24,6 +25,7 @@
     "updateWorkflowPublicApi",
     "listWorkflowTriggers",
     "updateWorkflowTrigger",
+    "listWorkspaceSchedules",
     "deployWorkflow",
     "undeployWorkflow",
     "rollbackWorkflow",

apps/docs/content/docs/api-reference/authentication.mdx

@@ -42,9 +42,9 @@ Delete a key from the same settings page to revoke it. Update applications that
 
 A read-only key cannot change workspace resources or run, resume, or cancel workflows. Reads can still cost credits: searches use embedding credits, and search chat uses model credits and keeps a private conversation history. Selector lookups call third-party services with your connected accounts.
 
-A refused request fails with `403` and the message `This API key is read-only and cannot perform this operation`. Where the surface carries a code, it is `READ_ONLY_API_KEY`: in `error.details.code` on the v2 API and the Sim MCP server, in `details.code` on the v1 API and workflow execution, and in `error.data.code` on a workflow MCP server.
+A refused request fails with `403` and the message `This API key is read-only and cannot perform this operation. Use a full-access API key.` Where the surface carries a code, it is `READ_ONLY_API_KEY`: in `error.details.code` on the v2 API and the Sim MCP server, in `details.code` on the v1 API and workflow execution, and in `error.data.code` on a workflow MCP server.
 
-Access narrows a key; it never grants more than the key's identity already has. Access is fixed at creation, so create a new key to change it. Keys created before access levels existed have full access. Keys created from the deploy modal or for a workflow MCP server always have full access, because they exist to run workflows. If **Access** isn't shown when you create a key, read-only keys aren't available on your deployment yet.
+Access narrows a key; it never grants more than the key's identity already has. Access is fixed at creation, so create a new key to change it. Keys created before access levels existed have full access. Keys created from the deploy modal or for a workflow MCP server always have full access, because they exist to run workflows.
 
 ### Expiration [#key-expiration]