@rosthq/cli 0.5.16 → 0.5.17

package/dist/index.js

@@ -41830,7 +41830,7 @@ Drafting can be assisted by agents. Activation is a human decision. When authori
     order: 40,
     title: "Agent staffing playbook",
     summary: "How to decide whether a seat should be human, agent, or hybrid, and how to go live safely.",
-    version: "2026-06-19.2",
+    version: "2026-06-20.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -41891,6 +41891,12 @@ Two creation paths, both draft-first. Read the stock-agents guide for templates
 - Run on demand: \`{{cli}} agent run-now --seat-id <seat-id>\` / \`agent.run_now\` / \`rost_run_agent_now\` queues an immediate live run without changing the saved schedule. Cloud agents dispatch to the Inngest executor; runner agents queue work for the paired runner. The command is ungated but still requires a live staffed agent and the normal server-side tool guard.
 - Audit what an agent did (Trust Card): \`{{cli}} command agent.list_runs --json '{"seat_id":"<seat-id>"}'\` / \`rost_list_agent_runs\` returns the seat's run history with per-run tool-call and guard-held counts; \`{{cli}} agent get-run --seat-id <seat-id> --run-id <run-id>\` / \`agent.get_run\` / \`rost_get_agent_run_diagnostics\` reads one run's transcript reference, token/cost usage, outcome, and product-visible run errors; \`{{cli}} command agent.list_tool_calls --json '{"seat_id":"<seat-id>"}'\` / \`rost_list_agent_tool_calls\` returns the tool-call ledger with each call's guard result. Both list commands include a \`denied_tool_call_count\` rollup \u2014 the actions held because they exceeded the charter. Pass \`{"seat_id":"<seat-id>","held_only":true}\` to \`agent.list_tool_calls\` for only the held calls. The web seat page shows the same facts as a Trust Card.
 
+## Review readiness before go-live
+
+The fleet page and seat page should make readiness inspectable, not implied. A staffed agent row shows whether the Steward chain, lane or runtime substrate, vaulted credentials, granted tools, model config, sandbox dry run, and go-live state are complete. Each missing item links to the exact setup surface that fixes it: seat staffing, the Charter Builder, agent operations, runner settings, vault settings, or tool configuration.
+
+After an agent runs, review its completed work as well as its telemetry. Seat pages combine explicit deliverables, work-log evidence, and successful run summaries into a readable output trail with safe evidence links labelled as internal, Linear, GitHub, or external. Held confirmations and escalations remain visible until decided or expired: confirmations can be approved or rejected from the seat page, while escalations link to the Steward queue for the human decision.
+
 ## When to stop for confirmation
 
 \`agent.create_from_template\`, \`agent.create_custom\`, \`staffing.assign_user\`, \`agent.go_live\`, \`agent.update_schedule\`, and \`mcp_token.create\` are \`human_required\`; \`agent.configure_tools\` and \`credential.ingress\` are \`credential_flow\` (both gate through the vault-backed credential path with human approval; \`agent.configure_tools\` stages the request and only \`credential.ingress\` takes the raw secret, as a vault reference); \`agent.decommission\` is \`dangerous\`. \`agent.run_now\` is not human-gated because it does not expand authority or change the schedule; it only queues an immediate run for an already-live agent. An agent may draft, configure (with vault refs), dry-run, and request an on-demand run; the human approves go-live, credentials, schedule changes, and decommission. \`run_dry_run\` is ungated by human approval, but it is **precondition-gated**: the seat's permission manifest must be signed first (\`charter.sign_manifest\`). Attempting a dry run before sign-off returns a clean \`COMMAND_PRECONDITION_FAILED\` naming \`charter.sign_manifest\`, not a generic failure. Go-live after a passed dry run is \`human_required\`. See the confirmations guide.
@@ -42133,7 +42139,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.3",
+    version: "2026-06-20.4",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -42225,20 +42231,20 @@ Before an agent goes live, the sandbox dry run rehearses this against fake data
 
 ## What humans should review
 
-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.
+The Agents page shows fleet health first: live state, recent runs, failed runs, open held actions, last activity, cost, and the next operator action. It also shows configuration completeness for each staffed agent seat: Steward chain, lane or runtime substrate, vaulted credentials, granted tools, model config, sandbox dry run, and go-live state, each with a remediation link when incomplete. 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.`
+Review the first dry runs, fleet overview, tool-call audit rows, escalations, deliverables, and Signal impact. A seat's completed-work area combines explicit deliverables, work-log evidence, and successful run summaries into one operator-facing trail with safe links labelled as internal, Linear, GitHub, or external. 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.4",
+    version: "2026-06-20.5",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
-    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"],
+    relatedCommandIds: ["charter.sign_manifest", "credential.ingress", "agent.configure_tools", "integration.list", "integration.readiness", "integration.status", "integration.test", "mcp_token.create", "mcp_token.revoke", "mcp_token.list", "confirmation.approve"],
     legal: {
       publicRisk: "low",
       notes: [
@@ -42288,6 +42294,8 @@ Google can be connected from Settings once the workspace OAuth app is configured
 
 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.
 
+\`integration.readiness\` / \`{{cli}} integration readiness --provider google --json\` / \`rost_check_integration_readiness\` returns the same setup checklist Settings shows: OAuth env and callback status, tenant connection state, granted scopes, latest test state, external verification/CASA caveats, handler availability, and the next Linear issue or action. The checklist is metadata-only. It never returns access tokens, refresh tokens, client secrets, vault refs, or raw provider responses.
+
 ## 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.
@@ -42370,7 +42378,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.10",
+    version: "2026-06-20.11",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -42409,7 +42417,11 @@ External connectors are being rolled out provider by provider, conservatively (r
       "agent.fleet_digest",
       "agent.get_run",
       "agent.list_runs",
-      "agent.list_tool_calls"
+      "agent.list_tool_calls",
+      "integration.list",
+      "integration.readiness",
+      "integration.status",
+      "integration.test"
     ],
     legal: {
       publicRisk: "low",
@@ -42783,7 +42795,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}} integration list|readiness|status|test\` | \`integration.list\`, \`integration.readiness\`, \`integration.status\`, \`integration.test\` | List connector metadata, read the setup-readiness checklist, read one connector's health, and run the provider-specific connection test without exposing credentials. | Tenant | \`{{cli}} integration readiness --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|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\` |
@@ -42917,6 +42929,7 @@ Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`
 | \`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_check_integration_readiness\` | \`integration.readiness\` | Return the connector setup checklist: OAuth env/callback, tenant connection, scopes, latest test state, external verification/CASA, handler availability, and DER-coded next actions. | Tenant | Call with \`{"provider":"google"}\`; metadata only, no secrets or vault refs. |
 | \`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\`. |
@@ -43144,7 +43157,7 @@ Retrieve the narrowest relevant guide before making a setup recommendation. Pref
     order: 60,
     title: "Cascade guide",
     summary: "How to connect company goals to seat-level work without turning {{brand}} into a project-management tool.",
-    version: "2026-06-20.1",
+    version: "2026-06-20.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -43197,6 +43210,10 @@ Cascade warnings are advisory, not blockers. They point to setup that should be
 - Agent goal missing human accountability parent: an agent-owned goal has no human or hybrid goal in its ancestry.
 - Orphaned goal branch: the owner seat or parent chain no longer reaches an active Compass objective.
 
+On \`/cascade\`, the screen renders the full goal depth, not just one or two levels. Off-track descendant branches stay open so the operator can see why a parent rolled up to risk.
+
+On human and function seat pages, goal visibility includes both direct goals and descendant seat goals from the Responsibility Graph subtree, so a manager can review team progress without double-owning the agent's work.
+
 ## What does not belong
 
 Do not put every task into Cascade. Small errands, private notes, and work with no strategic connection should stay out. Cascade should answer whether the company is moving toward its stated outcomes.
@@ -43288,7 +43305,7 @@ Agents may record readings when the Charter allows it. Agent-reported readings s
     order: 62,
     title: "Friction guide",
     summary: "How to capture issues with evidence, rank them, and resolve them without losing ownership.",
-    version: "2026-06-18.1",
+    version: "2026-06-20.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -43337,6 +43354,8 @@ Friction is where operational issues become visible. A good Friction item is spe
 
 Agents should file Friction when a measurable breaks, a tool fails, a repeated exception appears, or the Charter says a condition must be escalated. The agent should attach evidence and avoid deciding beyond its scope.
 
+In the app, operational evidence is summarized for humans instead of shown as the primary interface. Incident fields, proposed tool calls, schedules, payload labels, and source links render as readable fields with raw details tucked behind supporting context when useful. Secret-shaped values stay redacted.
+
 ## Operate Friction, tasks, and escalations from CLI or MCP
 
 Friction, tasks, and escalations are the issue-to-action loop. A seat files, a task carries the work, and an escalation routes a decision a seat cannot make alone.
@@ -43358,7 +43377,7 @@ Resolving Friction should produce one of four outcomes: a decision, a task, a Ch
     order: 70,
     title: "Steward queue guide",
     summary: "How Stewards review escalations, approve agent boundaries, and keep agents accountable.",
-    version: "2026-06-18.2",
+    version: "2026-06-20.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -43395,6 +43414,8 @@ Read the seat, Charter, evidence, and recommended action. Decide the narrow ques
 
 In the app, the evidence is shown as a legible card, not raw data: a proposed tool call lists the tool and its summarized arguments, and any attached context shows as labeled fields. Values that read like credentials are redacted, so you can decide without seeing secret material.
 
+When nothing is waiting, the Steward page still proves the governance loop. It shows which agent or hybrid seats the human stewards, how many escalations were raised or decided recently, and whether any are open. That empty state is an operating summary, not a dead end.
+
 ## Work the queue from CLI or MCP
 
 The Steward reads the queue from any surface but decides as a human.
@@ -43471,11 +43492,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-20.5",
+    version: "2026-06-20.7",
     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", "integration.list", "integration.status", "integration.test", "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.readiness", "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: [
       {
@@ -43505,11 +43526,11 @@ Start with members and invites, then provider and channel connections, then MCP
 
 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.
+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. Notification timestamps and integration test timestamps follow the same safe-label rule, so a malformed or missing timestamp becomes \`Unknown\` or unavailable copy rather than a page crash.
 
 ## 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.
+\`integration.list\` lists connector metadata for CLI and MCP operators, \`integration.readiness\` returns the setup checklist, \`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, checklist status, DER-coded next actions, and health only; they never return vault references, access tokens, refresh tokens, client secrets, 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 readiness facts and test action beside Connect/Reconnect, showing whether OAuth env, callback registration, tenant connection, scopes, tests, Google verification/CASA, and Gmail/Sheets handler slices are ready or still waiting on DER-880, DER-881, DER-866, DER-867, or DER-869.
 
 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.
 
@@ -43772,7 +43793,7 @@ Templates may draft. Humans approve. A stock agent should not go live until a hu
     order: 77,
     title: "Troubleshooting guide",
     summary: "How users and agents should diagnose common setup, tool, Signal, Friction, and MCP problems.",
-    version: "2026-06-18.4",
+    version: "2026-06-20.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing", "operating_rhythm"],
@@ -43805,10 +43826,12 @@ Before calling a command that changes state, discover its exact shape so you do
 - Onboarding seems stuck: call \`onboarding.status\` / \`rost_onboard_status\` and inspect missing graph, Charter, Compass, or staffing steps.
 - Graph looks wrong: read \`graph.get\` / \`rost://graph\` to confirm seat ids, parents, and occupancy before mutating.
 - Agent cannot act: check the Charter, permission manifest, Steward chain, and token scope with \`agent.status\` / \`rost_get_agent_status\` and \`seat.get\`.
+- Agent looks incomplete: open the fleet row on \`/agents\` and follow the configuration readiness links for the missing Steward chain, lane/substrate, credentials, tools, model config, sandbox dry run, or go-live state.
 - Signal looks wrong: read \`signal.list\` / \`rost_list_signals\` and check owner seat, cadence, target, and evidence.
 - Friction is noisy: read \`friction.list\` and check whether the underlying Charter or measurable is unclear.
 - Escalations are aging: read \`escalation.list\` / \`rost_list_escalations\`; a human resolves through the Steward queue.
 - MCP access fails: revoke and recreate the narrowest token after checking scope (\`mcp_token.revoke\` then \`{{cli}} mcp install --client <client> --scope seat --seat-id <seat-id>\`; standalone \`mcp install\` requires an explicit \`--scope\`).
+- Settings section unavailable: keep the route open, read which section is marked unavailable, and retry or fix that source directly. Do not treat a missing Settings panel as permission to write blind values; budget and Sync Brief settings stay read-only until their data loads.
 
 ## Surface-specific failures
 
@@ -45775,6 +45798,17 @@ var integrationWrapper = (context, args) => dispatch(context, "integration", arg
       return integrations.map((entry) => formatIntegrationLine(asRecord(entry))).join("\n");
     });
   },
+  readiness: (ctx, rest) => {
+    const parsed = parseFlags(rest);
+    const body = withOptional({}, { provider: optionalValue(parsed, "provider") });
+    return execute(ctx, parsed, "integration.readiness", body, (output) => {
+      const connectors = asArray(asRecord(output).connectors);
+      if (connectors.length === 0) {
+        return "No connector readiness facts found.";
+      }
+      return connectors.map((entry) => formatIntegrationReadiness(asRecord(entry))).join("\n\n");
+    });
+  },
   status: (ctx, rest) => {
     const parsed = parseFlags(rest);
     const body = integrationLookupBody(parsed);
@@ -45808,9 +45842,24 @@ function integrationLookupBody(parsed) {
 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 formatIntegrationReadiness(record2) {
+  const checks = asArray(record2.checks).map((entry) => {
+    const check2 = asRecord(entry);
+    const issue2 = field(check2, "linear_issue") === "\u2014" ? "" : ` ${field(check2, "linear_issue")}`;
+    return `  - ${field(check2, "label")}: ${field(check2, "status")}${issue2} \u2014 ${field(check2, "detail")}`;
+  });
+  const actions = asArray(record2.next_actions).map((entry) => `  - ${String(entry)}`);
+  return [
+    `${field(record2, "provider")} readiness=${field(record2, "overall_status")}  id=${field(record2, "integration_id")}`,
+    field(record2, "summary"),
+    checks.length > 0 ? ["checks:", ...checks].join("\n") : "",
+    actions.length > 0 ? ["next:", ...actions].join("\n") : ""
+  ].filter((line) => line.length > 0).join("\n");
+}
 function integrationUsage(bin) {
-  return `Usage: ${bin} integration list|status|test [--json]
+  return `Usage: ${bin} integration list|readiness|status|test [--json]
   ${bin} integration list [--provider <name>]
+  ${bin} integration readiness [--provider google]
   ${bin} integration status --provider <name>
   ${bin} integration test --provider <name>`;
 }