@rosthq/cli 0.5.13 → 0.5.15

package/dist/index.js

@@ -41752,7 +41752,7 @@ When operating through CLI or MCP, create fewer seats first and ask for confirma
     order: 30,
     title: "Charter design playbook",
     summary: "How to draft strong Charters that work for human, agent, and hybrid seats.",
-    version: "2026-06-13.1",
+    version: "2026-06-20.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["charter_design", "staffing"],
@@ -41809,6 +41809,8 @@ List and read first, then draft, then leave activation to a human.
 - Draft one: \`{{cli}} command charter.draft --json '{"seat_id":"<seat-id>"}'\` (scope: seat or tenant-admin); draft every eligible seat with \`charter.draft_all\` / \`rost_draft_all_charters\`. Draft commands are not gated \u2014 they produce a draft \`charter_version_id\`. \`charter.draft_all\` only drafts **active** seats and returns the real result: \`{ drafted, skipped, draft_ids, skipped_seats: [{ seat_id, reason }] }\` where \`reason\` is \`seat_not_active\` (the seat is still draft/vacant \u2014 confirm it first) or \`charter_exists\` (it already has a draft/active Charter). Read \`skipped_seats\` to see why a freshly-built graph drafted fewer Charters than it has seats.
 - Edit a draft: \`charter.update_draft\` / \`rost_update_charter_draft\` with the \`charter_version_id\` and the new \`doc\`.
 
+In the app, \`/charters\` is both a drafting queue and a governance library. It shows active Charters, draft amendments, seats missing Charters, unsigned manifests, and steward-review gaps. Opening a live Charter is a review mode: read the active version, inspect its governance state, and open an amendment draft when the job needs to change. Active Charter content is never silently edited in place.
+
 ## When to stop for confirmation
 
 \`charter.approve\`, \`charter.skip\`, \`charter.apply_seat_type_recommendation\`, and \`charter.sign_manifest\` are \`human_required\`. Over MCP \`rost_approve_charter\` returns a pending confirmation, not an activation. Approving a Charter, signing a permission manifest, or expanding authority is a human act recorded against \`decided_by\`. An agent prepares the draft and surfaces the approve link; it does not approve. See the confirmations guide.
@@ -41896,7 +41898,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 +42053,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"],
@@ -42121,7 +42123,7 @@ Decisions should be recorded as human decisions. Handoffs should attach to seats
     order: 45,
     title: "How agents work",
     summary: "How {{brand}} agents operate inside seats, use Charters, report work, and escalate beyond authority.",
-    version: "2026-06-20.1",
+    version: "2026-06-20.3",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -42130,6 +42132,7 @@ Decisions should be recorded as human decisions. Handoffs should attach to seats
       "agent.go_live",
       "agent.status",
       "agent.list_fleet",
+      "agent.fleet_digest",
       "agent_setup.get",
       "agent_setup.update",
       "agent.decommission",
@@ -42204,24 +42207,28 @@ The model is only ever offered the tools the seat's manifest grants \u2014 a den
 3. The action runs bound to the seat's vaulted credential. The secret stays inside the call and never reaches the result, the audit row, the logs, or the model.
 4. Every call \u2014 allowed, denied, escalated, or invalid \u2014 writes a tool-call audit row you can review.
 
+When operational evidence appears in the app, it is formatted for review instead of shown as primary raw JSON. Tool arguments, escalation evidence, status evidence, Sync inputs, and task context are summarized as labeled fields; secret-looking values stay redacted. Raw identifiers remain available only as supporting detail when they help an operator trace the record.
+
 Provider requests carry only the model payload the runtime needs; run attribution, tenant attribution, usage, and cost are recorded in {{brand}} audit tables after the call, not sent as custom provider metadata.
 
 Before an agent goes live, the sandbox dry run rehearses this against fake data and returns a per-tool preview: for each tool the agent would touch, whether it would run it, would be blocked, or would escalate \u2014 no external side effect. Review that preview before you approve go-live.
 
 ## What humans should review
 
-Review the first dry runs, fleet overview, tool-call audit rows, escalations, and Signal impact. The fleet view at \`/agents\` shows every staffed agent seat at a glance; the agent-native equivalent is \`{{cli}} command agent.list_fleet --json '{}'\` / \`rost_list_agent_fleet\`, which returns lane, live state, last real turn, 24h/7d real turns, top measurable status, open escalations, and 7-day spend. Fleet real-turn counts use the same seat-run association as \`agent.list_runs\`, filtered to real runs. Scheduled agents are checked in rounded five-minute buckets, so a minute-level cron inside the bucket queues one work order for that bucket rather than one order per minute. Sandbox dry runs do not count as real turns. If the agent is repeatedly blocked, revise the Charter or split the seat. If the agent is taking too much judgment, narrow its autonomous scope.`
+The Agents page shows fleet health first: live state, recent runs, failed runs, open held actions, last activity, cost, and the next operator action. A seat's Trust Card drills into the same facts: run history, one-run detail, tool-call outcomes, product-visible errors, transcript references, and held confirmations or escalations. Open confirmations stay visible until they are decided or expire, even when they are older than the default activity window. Approving or rejecting a held confirmation from the seat page is scoped to that seat; rejection can include a short reason.
+
+Review the first dry runs, fleet overview, tool-call audit rows, escalations, and Signal impact. The fleet view at \`/agents\` shows every staffed agent seat at a glance; the agent-native equivalents are \`{{cli}} command agent.list_fleet --json '{}'\` / \`rost_list_agent_fleet\` for the compact overview, and \`{{cli}} agent fleet-digest --json\` / \`agent.fleet_digest\` / \`rost_get_dogfood_fleet_health_digest\` for the daily dogfood evidence bundle. The digest returns live/idle state, 24h/7d turns, 7d/30d spend, recent failed runs, unresolved product errors, failed notifications, and a next action per seat. Fleet real-turn counts use the same seat-run association as \`agent.list_runs\`, filtered to real runs. Scheduled agents are checked in rounded five-minute buckets, so a minute-level cron inside the bucket queues one work order for that bucket rather than one order per minute. Sandbox dry runs do not count as real turns. If the agent is repeatedly blocked, revise the Charter or split the seat. If the agent is taking too much judgment, narrow its autonomous scope.`
   },
   {
     slug: "tool-access-and-vault",
     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 +42272,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 +42293,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\`.
@@ -42293,7 +42307,7 @@ There is exactly one way to give a connected tool its credential, and it is the
     order: 47,
     title: "Available tools guide",
     summary: "How to think about tool categories available to seats and what each category should be used for.",
-    version: "2026-06-20.2",
+    version: "2026-06-20.3",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -42342,7 +42356,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.5",
+    version: "2026-06-20.8",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -42378,6 +42392,7 @@ External connectors are being rolled out provider by provider, conservatively (r
       "agent.go_live",
       "agent.status",
       "agent.list_fleet",
+      "agent.fleet_digest",
       "agent.get_run",
       "agent.list_runs",
       "agent.list_tool_calls"
@@ -42754,9 +42769,10 @@ 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\` |
+| \`{{cli}} agent templates|create|setup|tools|dry-run|go-live|status|run-now|fleet-digest|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.fleet_digest\`, \`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, capture the fleet-health digest, 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 fleet-digest --json\` |
 | \`{{cli}} tools list\` | \`tool.catalog\` | List the discoverable tool catalog the builder reads (id, scope tiers, credential requirement, access policy, and execution-boundary guidance). | Tenant | \`{{cli}} tools list --json\` |
 | \`{{cli}} model list\` | \`model.catalog\` | List guided model tiers with recommendations, token prices, cost bands, best-fit work, and model ids for \`--model\`. | Tenant | \`{{cli}} model list --json\` |
 | \`{{cli}} compass show\` | \`compass.show_markdown\` | Render the current Compass as a clean markdown card for review. | Tenant | \`{{cli}} compass show --markdown\` |
@@ -42856,6 +42872,7 @@ Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`
 | \`rost_list_compass_gaps\` | \`compass.list_gaps\` | List unanswered and answered Compass context gaps. | Tenant | Call with \`{}\` before answering gaps. |
 | \`rost_get_agent_status\` | \`agent.status\` | Read agent lane, live state, steward chain, dry-run result, Runner availability. | Seat or tenant-admin | Call with \`{"seat_id":"<seat-id>"}\`. |
 | \`rost_list_agent_fleet\` | \`agent.list_fleet\` | Read every staffed agent seat at once: lane, live state, last real turn, 24h/7d real turns, measurable status, escalations, and 7-day spend. | Tenant | Call with \`{}\`; counts use the same seat-run association as \`agent.list_runs\`, with sandbox dry runs excluded from real turns. |
+| \`rost_get_dogfood_fleet_health_digest\` | \`agent.fleet_digest\` | Capture the daily dogfood fleet-health digest: live/idle state, 24h/7d turns, spend, recent failed runs, unresolved errors, failed notifications, and next actions. | Tenant | Call with \`{}\`; optional \`window_hours\` bounds recent failed-run evidence, while \`error_limit\` caps linked evidence per seat. |
 | \`rost_run_agent_now\` | \`agent.run_now\` | Queue an immediate run for a live staffed agent without changing its saved schedule; cloud lane dispatches to the executor and runner lane queues for the paired runner. | Tenant | Call with \`{"seat_id":"<seat-id>"}\`. |
 | \`rost_list_agent_runs\` | \`agent.list_runs\` | Read a seat's agent run history (status, lane, model, cost, per-run tool-call and guard-held counts) plus the seat's run/tool-call rollup including held-action count. | Seat or tenant-admin | Call with \`{"seat_id":"<seat-id>"}\`; pass \`limit\` for a deeper window. |
 | \`rost_get_agent_run_diagnostics\` | \`agent.get_run\` | Read one run's diagnostic record: transcript reference, token/cost usage, outcome, and linked product-visible run errors. | Seat or tenant-admin | Call with \`{"seat_id":"<seat-id>","run_id":"<run-id>"}\`. |
@@ -42875,7 +42892,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 +42901,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. |
@@ -43415,11 +43435,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.5",
     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 +43467,16 @@ 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.
 
+Settings lifecycle timestamps are display metadata for tokens, connected machines, integrations, and stored credentials. They may be emitted by the database as either timestamp values or strings, but Settings renders them as safe labels rather than treating timestamp formatting failures as page-level failures.
+
+When a settings source is temporarily unavailable, the app keeps the route open and marks affected sections as unavailable instead of showing raw errors or stale-looking editable values. Budget and Sync Brief controls stay read-only until their server-backed data can be loaded.
+
+## 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. Settings exposes the same Google test as an owner/operator button beside Connect/Reconnect, shows the last tested time, and turns failures into reconnect-oriented remediation copy rather than raw provider errors.
+
+Reconnects keep historical rows for audit, but provider status in Settings, CLI, and MCP prefers the current connected row first, then the latest error or disconnected row.
+
 ## 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 +43570,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 +43598,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 +43607,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 +43615,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 +45727,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);
@@ -45896,6 +45977,24 @@ ${field(record2, "summary")}`;
       return `queued ${field(workOrder, "lane")} work order ${field(workOrder, "id")} for agent ${field(workOrder, "agent_id")} (${field(workOrder, "status")})`;
     });
   },
+  "fleet-digest": (ctx, rest) => {
+    const parsed = parseFlags(rest);
+    const body = withOptional({}, {
+      window_hours: optionalNumber(parsed, "window-hours"),
+      error_limit: optionalNumber(parsed, "error-limit")
+    });
+    return execute(ctx, parsed, "agent.fleet_digest", body, (output) => {
+      const record2 = asRecord(output);
+      const summary = asRecord(record2.summary);
+      const agents = asArray(record2.agents);
+      const header = `fleet ${field(summary, "fleet_count")} seats  live=${field(summary, "live_count")}  idle=${field(summary, "idle_count")}  turns24h=${field(summary, "turns_24h")}  failed24h=${field(summary, "failed_runs_24h")}  spend7d=$${field(summary, "spend_7d_usd")}`;
+      const lines = agents.map((agent) => {
+        const r = asRecord(agent);
+        return `${field(r, "seat_name")}  ${field(r, "health_status")}  live=${field(r, "live")}  turns24h=${field(r, "turns_24h")}  failed=${field(r, "failed_runs_24h")}  next=${field(r, "suggested_next_action")}`;
+      });
+      return [header, ...lines].join("\n");
+    });
+  },
   "get-run": (ctx, rest) => {
     const parsed = parseFlags(rest);
     const body = {
@@ -45937,7 +46036,7 @@ function agentConfigureTools(ctx, rest, decision) {
   });
 }
 function agentUsage(bin) {
-  return `Usage: ${bin} agent templates|create|setup|tools|dry-run|go-live|status|run-now|get-run|show [--json]
+  return `Usage: ${bin} agent templates|create|setup|tools|dry-run|go-live|status|run-now|fleet-digest|get-run|show [--json]
   ${bin} agent templates
   ${bin} agent create --seat-id <id> --template <slug> [--expected-version <v>]
   ${bin} agent create --seat-id <id> --custom [--steward-seat-id <id>] [--lane cloud|mcp_session|runner] [--model triage|balanced|complex|hardest|<id>] [--effort low|medium|high|xhigh|max] [--owns <text>] [--success <text>] [--never-alone <text>]
@@ -45948,6 +46047,7 @@ function agentUsage(bin) {
   ${bin} agent go-live --seat-id <id> --charter-version-id <id>
   ${bin} agent status --seat-id <id>
   ${bin} agent run-now --seat-id <id> [--task-id <id>]
+  ${bin} agent fleet-digest [--window-hours <n>] [--error-limit <n>]
   ${bin} agent get-run --seat-id <id> --run-id <id>
   ${bin} agent show --seat-id <id> [--markdown]`;
 }
@@ -46060,6 +46160,7 @@ var OPERATION_GROUPS = [
   "sync",
   "runner",
   "notification",
+  "integration",
   "settings",
   "member",
   "agent",
@@ -46078,6 +46179,7 @@ var wrappers = {
   sync: syncWrapper,
   runner: runnerWrapper,
   notification: notificationWrapper,
+  integration: integrationWrapper,
   settings: settingsWrapper,
   member: memberWrapper,
   agent: agentWrapper,
@@ -46099,6 +46201,7 @@ var groupUsageBuilders = {
   sync: syncUsage,
   runner: runnerUsage,
   notification: notificationUsage,
+  integration: integrationUsage,
   settings: settingsUsage,
   member: memberUsage,
   agent: agentUsage,
@@ -46131,7 +46234,7 @@ function operationUsageLines(bin) {
     `${bin} notification settings|test|errors`,
     `${bin} settings get|update`,
     `${bin} member invite|update|remove`,
-    `${bin} agent templates|create|setup|tools|dry-run|go-live|status|run-now|get-run|show`,
+    `${bin} agent templates|create|setup|tools|dry-run|go-live|status|run-now|fleet-digest|get-run|show`,
     `${bin} tools list`,
     `${bin} model list`,
     `${bin} compass show`,