@rosthq/cli 0.5.12 → 0.5.14

package/dist/index.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";AAMA,OAAO,EAAE,gBAAgB,EAAE,yBAAyB,EAAE,MAAM,WAAW,CAAC;AACxE,OAAO,EAAoB,mBAAmB,EAAE,MAAM,kBAAkB,CAAC;AACzE,OAAO,EAAoB,KAAK,UAAU,EAAE,MAAM,kBAAkB,CAAC;AAYrE,KAAK,KAAK,GAAG;IACX,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC;IAC1C,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC;IAK1C,WAAW,CAAC,EAAE,OAAO,CAAC;CACvB,CAAC;AAEF,KAAK,WAAW,GAAG;IACjB,KAAK,CAAC,EAAE,UAAU,CAAC;IACnB,EAAE,CAAC,EAAE,KAAK,CAAC;IACX,KAAK,CAAC,EAAE,OAAO,gBAAgB,CAAC;IAChC,WAAW,CAAC,EAAE,OAAO,mBAAmB,CAAC;IACzC,cAAc,CAAC,EAAE,OAAO,yBAAyB,CAAC;CACnD,CAAC;AAEF,wBAAsB,IAAI,CAAC,IAAI,WAAwB,EAAE,OAAO,GAAE,WAAgB,GAAG,OAAO,CAAC,MAAM,CAAC,CA+LnG;AAwXD,wBAAgB,eAAe,CAAC,SAAS,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,GAAG,SAAS,GAAG,OAAO,CAUxF"}
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";AAMA,OAAO,EAAE,gBAAgB,EAAE,yBAAyB,EAAE,MAAM,WAAW,CAAC;AACxE,OAAO,EAAoB,mBAAmB,EAAE,MAAM,kBAAkB,CAAC;AACzE,OAAO,EAAoB,KAAK,UAAU,EAAE,MAAM,kBAAkB,CAAC;AAYrE,KAAK,KAAK,GAAG;IACX,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC;IAC1C,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC;IAK1C,WAAW,CAAC,EAAE,OAAO,CAAC;CACvB,CAAC;AAEF,KAAK,WAAW,GAAG;IACjB,KAAK,CAAC,EAAE,UAAU,CAAC;IACnB,EAAE,CAAC,EAAE,KAAK,CAAC;IACX,KAAK,CAAC,EAAE,OAAO,gBAAgB,CAAC;IAChC,WAAW,CAAC,EAAE,OAAO,mBAAmB,CAAC;IACzC,cAAc,CAAC,EAAE,OAAO,yBAAyB,CAAC;CACnD,CAAC;AAEF,wBAAsB,IAAI,CAAC,IAAI,WAAwB,EAAE,OAAO,GAAE,WAAgB,GAAG,OAAO,CAAC,MAAM,CAAC,CA+LnG;AAoZD,wBAAgB,eAAe,CAAC,SAAS,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,GAAG,SAAS,GAAG,OAAO,CAUxF"}

package/dist/index.js

@@ -41896,7 +41896,7 @@ No orphan agents. No raw secrets in prompts, logs, or tool arguments. No durable
     order: 41,
     title: "Add agents to your Responsibility Graph",
     summary: "The visual journey for adding an agent seat: where to start, choosing a mode, placing the seat, naming a Steward, setup, the safety gates, and go-live.",
-    version: "2026-06-18.1",
+    version: "2026-06-20.1",
     public: true,
     audiences: ["human", "in_app_agent"],
     stages: ["staffing"],
@@ -42051,7 +42051,7 @@ The dry run is a real sandbox rehearsal, not a stamp. It executes a mock-provide
     order: 80,
     title: "Sync rhythm playbook",
     summary: "How Signal, Friction, Cascade, and Sync Briefs turn weekly meetings into decision time.",
-    version: "2026-06-18.1",
+    version: "2026-06-20.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -42217,11 +42217,11 @@ Review the first dry runs, fleet overview, tool-call audit rows, escalations, an
     order: 46,
     title: "Tool access and vault",
     summary: "How to give agents access to tools without exposing raw credentials or expanding authority by accident.",
-    version: "2026-06-20.2",
+    version: "2026-06-20.4",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
-    relatedCommandIds: ["charter.sign_manifest", "credential.ingress", "agent.configure_tools", "mcp_token.create", "mcp_token.revoke", "mcp_token.list", "confirmation.approve"],
+    relatedCommandIds: ["charter.sign_manifest", "credential.ingress", "agent.configure_tools", "integration.list", "integration.status", "integration.test", "mcp_token.create", "mcp_token.revoke", "mcp_token.list", "confirmation.approve"],
     legal: {
       publicRisk: "low",
       notes: [
@@ -42265,6 +42265,12 @@ For an API with no dedicated connector, the generic REST tool lets a seat call a
 
 \`slack.post_message\` reuses the connected Slack workspace credential and the seat's Slack channel binding. A live call posts only to that bound channel, through the server-side guard and vault-bound bot token. If the bound channel is marked sensitive, the handler escalates for human approval instead of posting. A sandbox dry run makes no Slack request and does not open the vault.
 
+## Google connector status
+
+Google can be connected from Settings once the workspace OAuth app is configured. The connection flow requests offline access for Gmail read/compose and Sheets, stores the returned credential in the vault, and records only account and scope metadata in the integration row. The test action refreshes the vaulted credential and performs a minimal Gmail profile read. Gmail and Sheets agent tools remain configuration-only until their guarded handlers ship; connecting Google does not by itself let an agent read mail or edit a sheet.
+
+CLI and MCP can inspect connector readiness without seeing secrets: \`integration.list\` / \`rost_list_integrations\` lists connected providers and health metadata, \`integration.status\` / \`rost_get_integration_status\` reads one provider by id or name, and \`integration.test\` / \`rost_test_integration_connection\` runs the installed provider-specific health check. For Google, the test refreshes the vaulted OAuth credential and reads the Gmail profile, then records only account, scope, and health metadata.
+
 ## One write-only credential flow across every surface
 
 There is exactly one way to give a connected tool its credential, and it is the same on every surface (agent setup, Charter Builder, CLI, MCP). Connecting a tool only authorizes the access \u2014 it never captures a secret. When a connected tool needs a credential, you stage a vault-backed *request* (provider, scope, and a credential name \u2014 all labels, never the secret). You then provide the actual secret separately through the vault-backed ingress flow from Settings. No {{brand}} surface ever has a field that accepts raw secret material, so a secret can never reach a prompt, log, event, or tool argument.
@@ -42280,6 +42286,7 @@ There is exactly one way to give a connected tool its credential, and it is the
 ## Connect tools and credentials from CLI or MCP
 
 - Stage tools on a draft agent: \`agent.configure_tools\` / \`rost_configure_agent_tools\` \u2014 connect or decline proposed tools and stage credential-ingress requests. Pass vault references, never raw secret material.
+- Inspect connector readiness: \`integration.list\` / \`rost_list_integrations\`, \`integration.status\` / \`rost_get_integration_status\`, and \`integration.test\` / \`rost_test_integration_connection\` return provider metadata and health only.
 - Store a secret: \`credential.ingress\` / \`rost_store_credential\` (scope: seat) persists only a vault reference. \`credential.ingress\` is \`credential_flow\` \u2014 it returns a pending confirmation and runs only with a real human-provided secret, captured as a vault reference. (Because it redacts that secret, the pending confirmation also shows a high-risk badge \u2014 see the confirmations guide for badge-versus-level.)
 - Sign the manifest: \`charter.sign_manifest\` / \`rost_sign_charter_manifest\` requests human confirmation for the seat's permission manifest.
 - Mint local access: prefer \`{{cli}} mcp install\` for users; \`mcp_token.create\` is \`human_required\` and returns the token once. List metadata with \`mcp_token.list\` (never token material); revoke with \`mcp_token.revoke\`.
@@ -42342,7 +42349,7 @@ External connectors are being rolled out provider by provider, conservatively (r
     order: 48,
     title: "CLI and MCP installation guide",
     summary: "Install the public CLI, register remote token-backed MCP clients, and find the full command and tool catalog.",
-    version: "2026-06-20.4",
+    version: "2026-06-20.7",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -42411,7 +42418,7 @@ The MCP server is remote and token-backed. There is no local MCP daemon to insta
 A headless agent cannot complete setup unattended. Two things always require a human, so plan to announce the handoff rather than stall silently:
 
 - **Device-code approval at first login.** \`{{cli}} login --device\` prints a code; a human must open the workspace URL in a browser, sign in with Google, match the code, and approve.
-- **Durable gated commands.** Setting or approving a Charter, staffing a seat, and taking an agent live each open a confirmation that a human approves (an agent never approves its own request \u2014 see the confirmations-guide). The CLI surfaces the \`confirmation_id\` and an \`approveVia\` URL for the human. (\`{{cli}} mcp install\` is a partial exception: for an **interactive** operator it completes its own token-mint approval inline; in a **headless/agent** session it surfaces the confirmation and stops unless \`--skip-permissions\` / \`{{envPrefix}}_CLI_SKIP_PERMISSIONS=1\` is set \u2014 see Approving the token mint below.)
+- **Durable gated commands.** Setting or approving a Charter, staffing a seat, and taking an agent live each require a human approval boundary (an agent never approves its own request \u2014 see the confirmations-guide). In a **headless/agent** session, or over MCP, the command surfaces the \`confirmation_id\` and an \`approveVia\` URL for a human and stops. When a logged-in human runs \`{{cli}} command <id>\` from an **interactive TTY**, the official CLI completes that returned confirmation inline by calling \`confirmation.approve\` and printing the approved command output. (\`{{cli}} mcp install\` follows the same interactive rule for token minting, with \`--skip-permissions\` / \`{{envPrefix}}_CLI_SKIP_PERMISSIONS=1\` as an explicit headless loosening \u2014 see Approving the token mint below.)
 
 Treat these as blocking prerequisites: the agent prepares the request and waits for the human approver.
 
@@ -42754,6 +42761,7 @@ These ergonomic wrappers (including the \`{{cli}} agent\` group) require **{{cli
 | \`{{cli}} sync brief|compile|complete\` | \`sync.brief.get\`, \`sync.brief.compile\`, \`sync.run.complete\` | Compile, read, and complete a weekly Sync. | Tenant | \`{{cli}} sync brief --json\` |
 | \`{{cli}} runner list|status|work-orders|revoke\` | \`runner.list\`, \`runner.status\`, \`work_order.list\`, \`runner.revoke\` | Inspect runners and work orders; revoke a runner. | Tenant | \`{{cli}} runner list --json\` |
 | \`{{cli}} notification settings|test|errors\` | \`notification.settings.get\`, \`notification.test\`, \`notification.list_errors\` | Read notification settings, send a test, and list failed deliveries with linked product error source, seat id, and run id when available. | Tenant | \`{{cli}} notification errors --limit 10 --json\` |
+| \`{{cli}} integration list|status|test\` | \`integration.list\`, \`integration.status\`, \`integration.test\` | List connector metadata, read one connector's health, and run the provider-specific connection test without exposing credentials. | Tenant | \`{{cli}} integration test --provider google --json\` |
 | \`{{cli}} settings get|update\` | \`settings.get\`, \`settings.update\` | Read tenant settings; update budget caps. | Tenant | \`{{cli}} settings get --json\` |
 | \`{{cli}} member invite|update|remove\` | \`member.invite\`, \`member.update\`, \`member.remove\` | Manage tenant members. | Tenant | \`{{cli}} member invite --email ops@example.com --role member\` |
 | \`{{cli}} agent templates|create|setup|tools|dry-run|go-live|status|run-now|get-run|show\` | \`agent_template.list\`, \`agent.create_from_template\`, \`agent.create_custom\`, \`agent_setup.get\`, \`agent_setup.update\`, \`agent.configure_tools\`, \`agent.run_dry_run\`, \`agent.go_live\`, \`agent.status\`, \`agent.run_now\`, \`agent.get_run\`, \`agent.show_markdown\` | Run the full agent setup and operation flow: list templates, create a draft from a template or guided custom answers (with \`--model\` and \`--effort\`), read or answer setup state, connect or decline tools, dry-run, go live, run on demand, read one run's transcript/error diagnostics, and show a markdown readout. Create and go-live stop at human gates; the dry-run is ungated by human approval but requires a signed manifest first. | Tenant and seat | \`{{cli}} agent get-run --seat-id <seat-id> --run-id <run-id> --json\` |
@@ -42875,7 +42883,7 @@ Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`
 | \`rost_list_mcp_tokens\` | \`mcp_token.list\` | List MCP token metadata (never token material). | Tenant | Call with \`{}\` or \`{"include_revoked":true}\`. |
 | \`rost_list_runners\` | \`runner.list\` | List local runners and their online/offline/revoked state. | Tenant | Call with \`{}\`. |
 | \`rost_runner_status\` | \`runner.status\` | Read a single runner's capability and state. | Tenant | Call with \`runner_id\`. |
-| \`rost_start_runner_pairing\` | \`runner.pairing.start\` | Open a runner pairing session and return the human pairing code. | Tenant | Call with \`name\` and \`platform\`. |
+| \`rost_start_runner_pairing\` | \`runner.pairing.start\` | Open a runner pairing session and return the human pairing code. | Tenant-admin | Call with \`name\` and \`platform\`; owner/admin only. |
 | \`rost_revoke_runner\` | \`runner.revoke\` | Revoke a runner so it can no longer authenticate. | Tenant | Call with \`runner_id\`; expect human confirmation. |
 | \`rost_list_work_orders\` | \`work_order.list\` | List runner/cloud work orders for the tenant. | Tenant | Call with optional \`status\`, \`agent_id\`, or \`runner_id\`. |
 | \`rost_enqueue_work_order\` | \`work_order.enqueue\` | Queue a work order for a live scheduled agent. | Tenant | Call with \`agent_id\`. |
@@ -42884,6 +42892,9 @@ Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`
 | \`rost_update_notification_settings\` | \`notification.settings.update\` | Update tenant notification preferences. | Tenant | Call with the fields to change. |
 | \`rost_send_test_notification\` | \`notification.test\` | Emit an in-app test notification to the acting human. | Tenant | Call with \`{}\`. |
 | \`rost_list_notification_errors\` | \`notification.list_errors\` | List recent failed notification deliveries with linked \`error_log_id\`, source, seat id, and run id when available. | Tenant | Call with optional \`limit\`; \`source=run\` rows can be followed with \`agent.get_run\`. |
+| \`rost_list_integrations\` | \`integration.list\` | List connected integration metadata and latest health state. | Tenant | Call with \`{}\` or \`{"provider":"google"}\`; no secrets or vault refs are returned. |
+| \`rost_get_integration_status\` | \`integration.status\` | Read one integration's metadata by provider or integration id. | Tenant | Call with \`{"provider":"google"}\` or \`{"integration_id":"<id>"}\`. |
+| \`rost_test_integration_connection\` | \`integration.test\` | Run the provider-specific connection test and update integration health. | Tenant | Call with \`{"provider":"google"}\`; result is bounded metadata only. |
 | \`rost_invite_member\` | \`member.invite\` | Create a pending tenant invite for a human teammate. | Tenant | Call with \`email\` and \`role\`. |
 | \`rost_update_member_role\` | \`member.update\` | Change a tenant member's role. | Tenant | Call with \`member_id\` and \`role\`; expect human confirmation. |
 | \`rost_remove_member\` | \`member.remove\` | Remove a tenant member. | Tenant | Call with \`member_id\`; blocked if it would orphan an agent steward chain. |
@@ -43360,7 +43371,7 @@ Keep agent scope tight at first. Approve more autonomy only after evidence. Use
     order: 71,
     title: "Confirmations and human gates guide",
     summary: "How {{brand}} routes authority-changing work through human confirmation, and why agents never approve their own requests.",
-    version: "2026-06-18.1",
+    version: "2026-06-20.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["graph_design", "charter_design", "staffing", "operating_rhythm"],
@@ -43393,7 +43404,7 @@ The \`dangerous\` confirmation **level** is rare and is not the same as the **ri
 
 ## What a gated command returns over MCP
 
-A gated command does not mutate when an agent calls it. It returns a pending confirmation with the command id, a risk level, and an \`approveVia\` block containing a web URL and the exact \`{{cli}} command confirmation.approve --json ...\` line. The human approves through the web link or the CLI; the agent surfaces the link and stops.
+A gated command does not mutate when an agent calls it. It returns a pending confirmation with the command id, a risk level, and an \`approveVia\` block containing a web URL and the exact \`{{cli}} command confirmation.approve --json ...\` line. The human approves through the web link or the CLI; the agent surfaces the link and stops. A logged-in human at an interactive CLI can run their own gated \`{{cli}} command <id>\` without copy-pasting the approval command because the CLI completes the returned confirmation inline.
 
 \`\`\`bash
 # Human approves a pending confirmation
@@ -43415,11 +43426,11 @@ Stop before: approving a Charter, signing a manifest, connecting a tool or crede
     order: 72,
     title: "Settings guide",
     summary: "How to use Settings as the control plane for company access, channels, providers, tokens, and operating defaults.",
-    version: "2026-06-18.1",
+    version: "2026-06-20.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
-    relatedCommandIds: ["onboarding.create_invite", "mcp_token.create", "mcp_token.revoke", "mcp_token.list", "settings.get", "settings.update", "settings.sync_brief_scope.get", "settings.sync_brief_scope.update"],
+    relatedCommandIds: ["onboarding.create_invite", "mcp_token.create", "mcp_token.revoke", "mcp_token.list", "integration.list", "integration.status", "integration.test", "settings.get", "settings.update", "settings.sync_brief_scope.get", "settings.sync_brief_scope.update"],
     legal: { publicRisk: "low", notes: ["{{brand}}-native settings guidance."] },
     sources: [
       {
@@ -43447,6 +43458,10 @@ Start with members and invites, then provider and channel connections, then MCP
 - Stored credentials (vault references only) and tool access approvals.
 - Operating defaults, including Sync Brief scope.
 
+## Integration health
+
+\`integration.list\` lists connector metadata for CLI and MCP operators, \`integration.status\` reads one provider or integration id, and \`integration.test\` runs the installed provider-specific health check. These commands return account labels, scopes, capabilities, timestamps, and health only; they never return vault references, access tokens, refresh tokens, or raw provider responses. Google's test refreshes the vaulted OAuth credential and reads the Gmail profile as the minimal live check.
+
 ## Sync Brief scope
 
 The weekly Sync Brief compiles either company-wide or per cluster. Company-wide is one brief covering the whole company and is the default for a new company. Per cluster compiles one brief per cluster, scoped to each cluster's seats; pick it when clusters run their own weekly sync. Per cluster falls back to a single company-wide brief when the company has no clusters, so the rhythm never produces zero briefs. The owner sets this at onboarding and can change it later in Settings.
@@ -43540,7 +43555,7 @@ Every notification should include the seat, cause, evidence, and requested decis
     order: 75,
     title: "Local runner guide",
     summary: "How local agent sessions and runner surfaces should operate through {{brand}} without bypassing Charters or audit.",
-    version: "2026-06-19.2",
+    version: "2026-06-20.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -43568,7 +43583,7 @@ The local runner is for human-controlled local agent work. It should retrieve {{
 
 ## Inspect and control runners from CLI or MCP
 
-- Pair a new runner: \`runner.pairing.start\` / \`rost_start_runner_pairing\` with \`name\` and \`platform\` returns a human pairing code.
+- Pair a new runner: \`runner.pairing.start\` / \`rost_start_runner_pairing\` with \`name\` and \`platform\` returns a human pairing code. This is owner/admin-only because it mints a short-lived runner pairing session that leads to machine credentials.
 - Inspect: \`{{cli}} runner list --json\` / \`runner.list\` / \`rost_list_runners\` shows online/offline/revoked state; \`{{cli}} runner status\` / \`runner.status\` / \`rost_runner_status\` reads one runner.
 - Work orders: \`{{cli}} runner work-orders\` / \`work_order.list\` / \`rost_list_work_orders\`; queue with \`work_order.enqueue\` / \`rost_enqueue_work_order\` for a live scheduled agent, or use \`agent.run_now\` / \`rost_run_agent_now\` when an operator wants the product to queue and dispatch an immediate live run from a seat id; cancel with \`work_order.cancel\` / \`rost_cancel_work_order\`.
 - Revoke: \`{{cli}} runner revoke\` / \`runner.revoke\` / \`rost_revoke_runner\` so a runner can no longer authenticate.
@@ -43577,7 +43592,7 @@ The local runner is for human-controlled local agent work. It should retrieve {{
 
 Use this flow when a headless or desktop runner cannot use the interactive web confirmation flow.
 
-1. The owner runs \`runner.pairing.start\` or \`rost_start_runner_pairing\` with the runner \`name\` and \`platform\`.
+1. The owner/admin runs \`runner.pairing.start\` or \`rost_start_runner_pairing\` with the runner \`name\` and \`platform\`.
 2. The owner gives the returned \`user_code\` to the runner through a trusted out-of-band channel.
 3. The runner calls \`POST /api/runner/pairing/claim\` with \`{"user_code":"ABCD-2345"}\`.
 4. The response returns \`runner_id\`, \`runner_secret\`, \`name\`, and \`platform\`. Store the runner secret only on the runner machine.
@@ -43585,7 +43600,7 @@ Use this flow when a headless or desktop runner cannot use the interactive web c
 
 ## When to stop for confirmation
 
-\`runner.revoke\` and \`work_order.cancel\` are \`human_required\`; \`runner.pairing.start\`, \`work_order.enqueue\`, and \`agent.run_now\` are \`none\`, so an operator can pair a runner and queue work directly. List and status reads are not gated. Revoking a runner or cancelling work is the human-approved act. An agent inspects runner state and proposes the action.
+\`runner.pairing.start\`, \`work_order.enqueue\`, and \`agent.run_now\` are \`none\`, so they do not create a separate pending confirmation, but \`runner.pairing.start\` is still owner/admin-only at the command authorization layer. \`runner.revoke\` and \`work_order.cancel\` are \`human_required\`. List and status reads are not gated. Revoking a runner or cancelling work is the human-approved act. An agent inspects runner state and proposes the action.
 
 ## Guardrails
 
@@ -45697,6 +45712,57 @@ function notificationUsage(bin) {
   ${bin} notification test
   ${bin} notification errors [--limit <n>]`;
 }
+var integrationWrapper = (context, args) => dispatch(context, "integration", args, {
+  list: (ctx, rest) => {
+    const parsed = parseFlags(rest);
+    const body = withOptional({}, { provider: optionalValue(parsed, "provider") });
+    return execute(ctx, parsed, "integration.list", body, (output) => {
+      const integrations = asArray(asRecord(output).integrations);
+      if (integrations.length === 0) {
+        return "No integrations are connected.";
+      }
+      return integrations.map((entry) => formatIntegrationLine(asRecord(entry))).join("\n");
+    });
+  },
+  status: (ctx, rest) => {
+    const parsed = parseFlags(rest);
+    const body = integrationLookupBody(parsed);
+    return execute(ctx, parsed, "integration.status", body, (output) => {
+      const integration = asRecord(output).integration;
+      if (integration === null) {
+        return "Integration not found.";
+      }
+      return formatIntegrationLine(asRecord(integration));
+    });
+  },
+  test: (ctx, rest) => {
+    const parsed = parseFlags(rest);
+    const body = integrationLookupBody(parsed);
+    return execute(ctx, parsed, "integration.test", body, (output) => {
+      const record2 = asRecord(output);
+      return `${field(record2, "provider")} ${field(record2, "status")} (ok=${field(record2, "ok")})  ${field(record2, "message")}`;
+    });
+  }
+}, integrationUsage(context.binName));
+function integrationLookupBody(parsed) {
+  const body = withOptional({}, {
+    provider: optionalValue(parsed, "provider"),
+    integration_id: optionalValue(parsed, "integration-id")
+  });
+  if (Object.keys(body).length === 0) {
+    throw new UsageError("Provide --provider or --integration-id.");
+  }
+  return body;
+}
+function formatIntegrationLine(record2) {
+  return `${field(record2, "provider")}  status=${field(record2, "status")}  account=${field(record2, "account_email")}  last_test=${field(record2, "last_test_result")}  id=${field(record2, "id")}`;
+}
+function integrationUsage(bin) {
+  return `Usage: ${bin} integration list|status|test [--json]
+  ${bin} integration list [--provider <name>]
+  ${bin} integration status --provider <name>
+  ${bin} integration test --provider <name>`;
+}
 var settingsWrapper = (context, args) => dispatch(context, "settings", args, {
   get: (ctx, rest) => {
     const parsed = parseFlags(rest);
@@ -46060,6 +46126,7 @@ var OPERATION_GROUPS = [
   "sync",
   "runner",
   "notification",
+  "integration",
   "settings",
   "member",
   "agent",
@@ -46078,6 +46145,7 @@ var wrappers = {
   sync: syncWrapper,
   runner: runnerWrapper,
   notification: notificationWrapper,
+  integration: integrationWrapper,
   settings: settingsWrapper,
   member: memberWrapper,
   agent: agentWrapper,
@@ -46099,6 +46167,7 @@ var groupUsageBuilders = {
   sync: syncUsage,
   runner: runnerUsage,
   notification: notificationUsage,
+  integration: integrationUsage,
   settings: settingsUsage,
   member: memberUsage,
   agent: agentUsage,
@@ -46616,9 +46685,38 @@ async function printCommandOutput(io, client, commandId, body = {}, format, opti
 `);
     return 0;
   } catch (error51) {
+    if (io.interactive === true) {
+      const pending = pendingConfirmationFromError(error51);
+      if (pending && pending.commandId === commandId) {
+        io.stderr.write(`Approving ${pending.commandId} confirmation ${pending.confirmationId} as the interactive CLI user.
+`);
+        try {
+          const approved = await client.execute("confirmation.approve", { confirmation_id: pending.confirmationId });
+          const approvedOutput = asRecord2(approved.output).output ?? approved.output;
+          const rendered = format ? format(approvedOutput) : JSON.stringify(approvedOutput, null, 2);
+          io.stdout.write(`${rendered}
+`);
+          return 0;
+        } catch (approvalError) {
+          return printCommandError(io, approvalError);
+        }
+      }
+    }
     return printCommandError(io, error51);
   }
 }
+function pendingConfirmationFromError(error51) {
+  if (!(error51 instanceof CommandClientError) || !error51.response || error51.response.ok || error51.response.error.code !== "COMMAND_CONFIRMATION_REQUIRED") {
+    return null;
+  }
+  const details = asRecord2(error51.response.error.details);
+  const confirmationId = details.confirmationId;
+  const commandId = details.commandId;
+  if (typeof confirmationId !== "string" || confirmationId.length === 0 || typeof commandId !== "string" || commandId.length === 0) {
+    return null;
+  }
+  return { confirmationId, commandId };
+}
 function printCommandError(io, error51) {
   if (error51 instanceof CommandClientError && error51.response && !error51.response.ok) {
     const help = error51.response.error.help;