@rosthq/cli 0.5.28 → 0.5.30

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;AAerE,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,CAgPnG;AA+bD,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;AAerE,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,CAmPnG;AA6cD,wBAAgB,eAAe,CAAC,SAAS,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,GAAG,SAAS,GAAG,OAAO,CAUxF"}

package/dist/index.js

@@ -41758,7 +41758,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-20.1",
+    version: "2026-06-29.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["charter_design", "staffing"],
@@ -42257,7 +42257,7 @@ Use the lower-level commands after health names a finding: \`agent.get_run\` for
     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-27.6",
+    version: "2026-06-30.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -42307,15 +42307,15 @@ For an API with no dedicated connector, the generic REST tool lets a seat call a
 
 ## Gmail connector
 
-The native Gmail handlers run inside the same broker boundary as the REST and Slack connectors: every call passes the server guard and writes an audit row, and the vaulted Google OAuth token is bound only inside a credential closure \u2014 the agent never sees it, and both the access and refresh tokens are redacted from anything a handler returns. \`gmail.read\` (read scoped inbox) and \`gmail.draft\` (compose a draft, never send) are autonomous-eligible. \`gmail.send\` is approval-gated: it never sends autonomously \u2014 it holds the action for steward approval. A sandbox dry run previews the intended read/draft/held-send with no Gmail request and without opening the vault. Live external Gmail send stays gated on Google verification and domain cutover (DER-880 / DER-881); the draft and send-with-approval paths are live now.
+The native Gmail handlers run inside the same broker boundary as the REST and Slack connectors: every call passes the server guard and writes an audit row, and the vaulted Google OAuth token is bound only inside a credential closure \u2014 the agent never sees it, and both the access and refresh tokens are redacted from anything a handler returns. \`gmail.read\` (read scoped inbox) and \`gmail.draft\` (compose a draft, never send) are autonomous-eligible when a tenant has a connected Google credential. \`gmail.send\` is approval-gated: it never sends autonomously \u2014 it holds the action for steward approval. A sandbox dry run previews the intended read/draft/held-send with no Gmail request and without opening the vault. For partner demos before Google verification is complete, use sandbox dry runs, setup previews, and approval-held examples as the demo-safe substitute. Live external Gmail send stays gated on Google verification and domain cutover (DER-880 / DER-881).
 
 ## 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. Sheets agent tools remain configuration-only until their guarded handlers ship; connecting Google does not by itself let an agent edit a sheet.
+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 read/draft, bounded Sheets read, and approval-held Sheets write handlers run through the guarded broker when Google is connected; connecting Google still does not bypass the signed Charter manifest, tenant policy ceiling, credential vault, or tool-call audit. Sheet grants should use exact signed argument bindings for approved spreadsheet ids and ranges.
 
 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.
+\`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, the demo-safe partner path, 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
 
@@ -42346,7 +42346,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-27.2",
+    version: "2026-06-30.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -42392,14 +42392,14 @@ Agents should explain the job, the required tool category, the minimum permissio
 
 Every tool call passes the server-side guard first: the guard checks the call against the seat's signed permission manifest and records a tool-call audit row for **every** call \u2014 allowed, denied, or escalated. Tool selection is never authorization. Only an allowed call reaches its handler. A connected credential is bound into the handler for the duration of the call only; the secret never appears in the result, the audit summary, logs, or the model's context.
 
-External connectors are being rolled out provider by provider, conservatively (read and draft before send; write behind approval). A selected tool is only a permission until a live handler exists and the seat has the required credential or binding. Today the built-in execution path supports internal status reporting, the generic REST connector when a signed host/method/path allowlist and credential exist, \`slack.post_message\` for a bound Slack channel, and the Gmail handlers (\`gmail.read\`/\`gmail.draft\` autonomous-eligible, \`gmail.send\` held for approval) when Google is connected. Other provider entries remain configuration-only until their connector ships, so nothing runs silently.`
+External connectors are being rolled out provider by provider, conservatively (read and draft before send; write behind approval). A selected tool is only a permission until a live handler exists and the seat has the required credential or binding. Today the built-in execution path supports internal status reporting, the generic REST connector when a signed host/method/path allowlist and credential exist, \`slack.post_message\` for a bound Slack channel, and Google handlers for \`gmail.read\`, \`gmail.draft\`, \`sheets.read\`, and approval-held \`sheets.write\` when Google is connected. \`gmail.send\` remains held for approval and live external send stays gated on Google verification. Before that verification is complete, partner demos should show sandbox dry runs, setup previews, and approval-held examples rather than claim production Google readiness. Other provider entries remain configuration-only until their connector ships, so nothing runs silently.`
   },
   {
     slug: "mcp-and-cli-guide",
     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-28.3",
+    version: "2026-06-30.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -42522,9 +42522,9 @@ Commands below use angle-bracket placeholders. The CLI prints the real, fully-re
 A {{brand}} **account** (the human identity) is created with Google sign-in \u2014 in the browser at \`/signup\`, or headlessly via \`{{cli}} login --device\` (a human approves the code in any browser). A **company** (tenant) can then be created either way:
 
 - **Browser:** at \`/signup\`, name your company, then return to the CLI.
-- **Headless (no browser step):** once logged in, run \`{{cli}} signup --company "<name>"\`. This provisions the company for your session and makes it your active tenant, so \`{{cli}} onboard status\` and every other tenant-scoped command work immediately. This is the recommended path for an autonomous agent setting up from scratch.
+- **Headless (no browser step):** once logged in, run \`{{cli}} signup --company "<name>"\`. If the account has no active company yet, this provisions the first company for your session and makes it active, so \`{{cli}} onboard status\` and every other tenant-scoped command work immediately. This is the recommended path for an autonomous agent setting up from scratch.
 
-If you run a tenant-scoped command before any company exists, the CLI tells you both options. You only get one company per signup; running \`{{cli}} signup --company\` again returns your existing company rather than creating a duplicate.
+If you run a tenant-scoped command before any company exists, the CLI tells you both options. \`{{cli}} signup --company\` is not a second-company creation command: running it again returns the active company, names the company you requested, and says that no new company was created. The default output is human-readable; add \`--json\` only when an automation needs the raw command output. To inspect or switch among companies you can already access, use \`{{cli}} tenants\` and \`{{cli}} use <tenant-slug-or-id>\`. Additional company creation is not exposed as a public self-serve CLI path in this milestone.
 
 ## Install the CLI
 
@@ -42788,7 +42788,7 @@ These are the security posture rules for operating after install \u2014 a checkl
 | \`{{cli}} login\` | Open browser login and store the CLI session. | User session | \`{{cli}} login\` |
 | \`{{cli}} login --device\` | Device-code login for a headless agent: prints a short code + URL, a human approves in any browser, the CLI polls until authorized \u2014 no browser session needed on the agent's machine. | User session | \`{{cli}} login --device\` |
 | \`{{cli}} logout\` | Clear the local CLI session. | Local session | \`{{cli}} logout\` |
-| \`{{cli}} signup [--company "<name>"]\` | With no flag, open/print the web signup page. With \`--company\`, create the company headlessly for the logged-in session (no browser step) \u2014 it becomes your active tenant. | Public (\`--company\` needs a login session) | \`{{cli}} signup --company "Acme"\` |
+| \`{{cli}} signup [--company "<name>"] [--json]\` | With no flag, open/print the web signup page. With \`--company\`, bootstrap the first company headlessly for the logged-in session. If one is already active, it returns that company and says no new company was created. Add \`--json\` for machine-readable output. | Public (\`--company\` needs a login session) | \`{{cli}} signup --company "Acme"\` |
 | \`{{cli}} whoami\` | Show the authenticated user, accessible tenant roles, and the active tenant (\`current_tenant_id\`). | User | \`{{cli}} whoami\` |
 | \`{{cli}} tenants\` | List tenants the user can access; the active one is marked \`current\`. | User | \`{{cli}} tenants\` |
 | \`{{cli}} use <tenant>\` | Select a tenant slug or id as the active tenant for the session. It persists, so a following \`{{cli}} whoami\` reports it as \`current_tenant_id\`. | User | \`{{cli}} use acme-ops\` |
@@ -43709,7 +43709,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-20.1",
+    version: "2026-06-29.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -43911,7 +43911,7 @@ 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-27.1",
+    version: "2026-06-29.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -43950,7 +43950,7 @@ When a settings source is temporarily unavailable, the app keeps the route open
 
 ## Integration health
 
-\`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.
+\`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 handlers are ready or still waiting on DER-880, DER-881, DER-866, or DER-867.
 
 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.
 
@@ -44244,7 +44244,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-20.1",
+    version: "2026-06-29.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing", "operating_rhythm"],
@@ -44283,6 +44283,7 @@ Before calling a command that changes state, discover its exact shape so you do
 - 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.
+- Org-intake upload failed: read the safe parse status and reason, then ask the human for a better source file or continue by chat. Browser org intake accepts bounded CSV, text, PDF, DOCX, XLSX, PNG, and JPEG files; extraction failures are retryable and should not be worked around by pasting raw binary, stack traces, secrets, or full customer exports into a prompt.
 
 ## Surface-specific failures
 
@@ -44296,7 +44297,7 @@ Before calling a command that changes state, discover its exact shape so you do
 
 These are the common blockers when adding an agent (see the add-agents guide and the custom agents guide):
 
-- Missing Steward: an agent occupancy or go-live is blocked because no Steward chain resolves to a human. Name a human Steward on the seat, then retry. The no-orphan-agent rule is enforced server-side; do not route around it.
+- Missing Steward: an agent occupancy or go-live is blocked because no Steward chain resolves to a human. Use the inline steward-chain fix when the builder offers a human-occupied candidate, or name a human Steward on the seat, then retry. The no-orphan-agent rule is enforced server-side; do not route around it.
 - Failed dry run: the draft is kept and the failure reason is shown. Read it with \`agent.status\` / \`rost_get_agent_status\`, fix the Charter, manifest, or tool decision, then \`agent.run_dry_run\` again. A passed dry run is required before go-live.
 - Declined tool: declining a proposed tool updates the permission manifest and the dry-run task. If the agent then cannot complete the task, either grant a narrower tool or adjust the Charter so the work still routes safely or escalates.
 - Expired confirmation: a pending human gate expired before approval. Re-issue the gated command (for example \`agent.create_from_template\`, \`charter.sign_manifest\`, or \`agent.go_live\`) and approve the new confirmation; an agent never approves its own request.
@@ -44316,7 +44317,7 @@ Name the failing surface, collect evidence, recommend the smallest correction, a
     order: 78,
     title: "AI model data handling guide",
     summary: "How {{brand}} cloud agents, local MCP sessions, runners, BYOK, and connected tools handle model-bound data.",
-    version: "2026-06-22.1",
+    version: "2026-06-29.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing", "operating_rhythm"],
@@ -44341,27 +44342,27 @@ Name the failing surface, collect evidence, recommend the smallest correction, a
       {
         label: "OpenAI API data controls",
         url: "https://developers.openai.com/api/docs/guides/your-data",
-        note: "Official API data-use and retention controls verified 2026-06-22."
+        note: "Official API data-use and retention controls verified 2026-06-29."
       },
       {
         label: "OpenAI enterprise privacy",
         url: "https://openai.com/enterprise-privacy/",
-        note: "Official enterprise privacy and API retention summary verified 2026-06-22."
+        note: "Official enterprise privacy and API retention summary verified 2026-06-29."
       },
       {
         label: "OpenAI Codex with ChatGPT plan",
         url: "https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan",
-        note: "Official Codex plan data-control scope verified 2026-06-22."
+        note: "Official Codex plan data-control scope verified 2026-06-29."
       },
       {
         label: "Anthropic API and data retention",
         url: "https://platform.claude.com/docs/en/manage-claude/api-and-data-retention",
-        note: "Official Claude API ZDR, HIPAA, and retention scope verified 2026-06-22."
+        note: "Official Claude API ZDR, HIPAA, and retention scope verified 2026-06-29."
       },
       {
         label: "Claude Code data usage",
         url: "https://code.claude.com/docs/en/data-usage",
-        note: "Official local Claude Code data-flow, training, and retention summary verified 2026-06-22."
+        note: "Official local Claude Code data-flow, training, and retention summary verified 2026-06-29."
       },
       {
         label: "Reference corpus and docs spec",
@@ -44464,9 +44465,9 @@ If sensitive data appears by accident, stop, do not repeat it, and route cleanup
 
 ## Provider policy checkpoints
 
-For platform-managed \`cloud\` runs and BYOK Anthropic \`cloud\` runs, check the Anthropic account, workspace, model, and contract. As of 2026-06-22, official Anthropic Claude API documentation says retained API data is not used for model training without express permission, that some API features are ZDR-eligible while others are not, and that ZDR, HIPAA readiness, model-specific retention requirements, consumer products, Claude Code, and third-party integrations each have their own scope.
+For platform-managed \`cloud\` runs and BYOK Anthropic \`cloud\` runs, check the Anthropic account, workspace, model, and contract. As of 2026-06-29, official Anthropic Claude API documentation says retained API data is not used for model training without express permission, that some API features are ZDR-eligible while others are not, and that ZDR, HIPAA readiness, model-specific retention requirements, consumer products, Claude Code, and third-party integrations each have their own scope.
 
-For local OpenAI API-key clients running through \`mcp_session\` or \`runner\`, check the customer's OpenAI organization, project, endpoint, and API data controls. As of 2026-06-22, official OpenAI API documentation says API data is not used to train or improve OpenAI models unless the customer explicitly opts in, and default abuse-monitoring logs may retain customer content for up to 30 days unless approved controls apply. OpenAI says zero data retention is available only for eligible customers, endpoints, and use cases.
+For local OpenAI API-key clients running through \`mcp_session\` or \`runner\`, check the customer's OpenAI organization, project, endpoint, and API data controls. As of 2026-06-29, official OpenAI API documentation says API data is not used to train or improve OpenAI models unless the customer explicitly opts in, and default abuse-monitoring logs may retain customer content for up to 30 days unless approved controls apply. OpenAI says zero data retention is available only for eligible customers, endpoints, and use cases.
 
 For Codex specifically, first identify whether the operator is using Codex through a ChatGPT Free/Plus/Pro, Business, Enterprise, Edu, API, or other workspace path. Official OpenAI Codex help says ChatGPT training data controls apply to whether content processed through Codex may be used to improve OpenAI models when Codex is used with a ChatGPT plan, and that Pro and Plus conversations may be used unless training is disabled. Do not give a Codex user the OpenAI API answer unless they are actually using an API-governed Codex path.
 
@@ -44490,7 +44491,7 @@ When asked about AI data handling:
     order: 79,
     title: "Security model guide",
     summary: "How {{brand}} protects tenant data, credentials, tool calls, and human decisions across web, MCP, CLI, and agents.",
-    version: "2026-06-21.5",
+    version: "2026-06-29.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing", "operating_rhythm"],
@@ -44921,7 +44922,7 @@ This worked document **omits** \`unanswered_boundaries\` and \`seat_type_recomme
     order: 43,
     title: "Agent builder guide",
     summary: "The full agent setup sequence on the CLI/MCP path \u2014 seat, steward, job, boundaries, tools, credentials, model, schedule, dry-run, go-live \u2014 with the structured model config and access tiers.",
-    version: "2026-06-20.2",
+    version: "2026-06-29.1",
     public: true,
     audiences: ["cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -44969,13 +44970,15 @@ Building teams of controlled agent workers is the product's core differentiator.
 3. **Job** \u2014 what the seat owns. On \`agent.create_custom\` this is the operational answers (what it owns, what success looks like, what it must never do alone); for a strong contract, submit the full Charter directly via \`charter.update_draft\` (see the charter-authoring deep-dive).
 4. **Boundaries** \u2014 the Charter's \`decision_authority\` (can-do / must-ask / never / escalate), \`escalation_rules\`, and \`budget\`. Conservative by default: send/spend/irreversible actions are approval-gated or escalated.
 5. **Tools** \u2014 pick from the discoverable catalog (\`{{cli}} tools list\`); each tool has a default scope tier and access policy. Connect or decline via \`agent.configure_tools\`. Selecting a tool records permission; live handlers execute later only behind the signed manifest, server guard, required credential or binding, and connector-specific approval boundary.
-6. **Credentials** \u2014 a tool that needs access declares a credential-ingress request (provider, scope, secret name). The secret itself flows through the vault-backed ingress command as a vault ref \u2014 never paste a secret into a builder command.
+6. **Credentials and provider readiness** \u2014 a tool that needs access declares a credential-ingress request (provider, scope, secret name). The secret itself flows through the vault-backed ingress command as a vault ref \u2014 never paste a secret into a builder command. For Google-backed tools, inspect the provider readiness shown in Settings or the builder: not connected, connected but untested, connected and tested, or failed. Use \`integration.test\` / \`rost_test_integration_connection\` or the builder Test connection action to refresh the same safe status facts; do not infer authorization from a connected credential.
 7. **Operating instructions** \u2014 the runtime composes the agent's context from its Charter; you do not write a system prompt.
 8. **Model** \u2014 select the structured model config (see below). Read \`{{cli}} model list\` / \`model.catalog\` first when you are unsure; it returns the recommended default, effort, token price estimates, cost band, and best-fit work for each tier. If \`agent.create_custom\` omits \`model_config\`, {{brand}} recommends a tier from the supplied responsibility answers.
 9. **Heartbeat** \u2014 set the schedule (\`schedule_cron\`) for a recurring agent; a live scheduled agent must keep a steward chain.
 10. **Dry-run** \u2014 \`agent.run_dry_run\` rehearses in sandbox after the manifest is signed; it is ungated by human approval but requires a signed manifest.
 11. **Go-live** \u2014 \`agent.go_live\` is \`human_required\`. Prepare everything and surface the go-live to a human; never go live on a human's behalf.
 
+If \`agent_setup.get\` returns \`next_action: "set_steward"\`, use the returned steward-remediation candidates or choose an existing human-occupied seat with \`agent_setup.update --json '{"seat_id":"<agent-seat-id>","steward_seat_id":"<human-seat-id>"}'\`. If no human-occupied candidate exists, create or staff a human seat first. Do not bypass the no-orphan-agent guard; go-live remains blocked until the chain resolves to a person.
+
 ## Choosing the model (structured config)
 
 The agent's model is a structured object, not a bare string:
@@ -47552,7 +47555,8 @@ var deliverableWrapper = (context, args) => dispatch(context, "deliverable", arg
       title: requireValue2(parsed, "title")
     }, {
       summary: optionalValue(parsed, "summary"),
-      content: optionalValue(parsed, "content")
+      content: optionalValue(parsed, "content"),
+      delivered_at: optionalValue(parsed, "delivered-at")
     });
     return execute(ctx, parsed, "deliverable.create", body, formatDeliverableWrite);
   },
@@ -47575,7 +47579,7 @@ function deliverableUsage(bin) {
   return `Usage: ${bin} deliverable list|get|create|attach [--json]
   ${bin} deliverable list --seat-id <id>
   ${bin} deliverable get --seat-id <id> --deliverable-id <id>
-  ${bin} deliverable create --title <text> [--kind brief|work_evidence|artifact|report|other] [--summary <text>] [--content <text>]
+  ${bin} deliverable create --title <text> [--kind brief|work_evidence|artifact|report|other] [--summary <text>] [--content <text>] [--delivered-at <iso>]
   ${bin} deliverable attach --title <text> [--run-id <id>] [--task-id <id>] [--work-order-id <id>] [--kind brief|work_evidence|artifact|report|other] [--summary <text>] [--content <text>]`;
 }
 function formatSystemHealth(output) {
@@ -47753,25 +47757,48 @@ function signupUrl(appUrl2) {
   return new URL("/signup", ensureTrailingSlash2(appUrl2)).toString();
 }
 function parseSignupCompany(args) {
+  const json2 = args.includes("--json");
   const index = args.indexOf("--company");
   if (index === -1) {
-    return { companyName: null };
+    return { companyName: null, json: json2 };
   }
   const value = args[index + 1];
   if (value === void 0 || value.startsWith("--") || value.trim() === "") {
     throw new Error(`--company requires a value, e.g. ${cliBrand.binName} signup --company "Acme"`);
   }
-  return { companyName: value };
+  return { companyName: value, json: json2 };
 }
-async function runSignupProvision(io, client, companyName, run2) {
+var signupProvisionOutputSchema = external_exports.object({
+  tenant_id: external_exports.string().min(1),
+  slug: external_exports.string().min(1),
+  name: external_exports.string().min(1),
+  created: external_exports.boolean()
+}).loose();
+async function runSignupProvision(io, client, companyName, run2, options = {}) {
   const exitCode = await run2(io, client, "signup.provision_tenant", { company_name: companyName });
-  if (exitCode === 0) {
+  if (exitCode.exitCode === 0) {
+    const parsed = signupProvisionOutputSchema.safeParse(exitCode.output);
+    if (!parsed.success) {
+      return exitCode.exitCode;
+    }
+    if (options.json === true) {
+      io.stdout.write(`${JSON.stringify(parsed.data, null, 2)}
+`);
+      return exitCode.exitCode;
+    }
+    if (!parsed.data.created) {
+      io.stdout.write(
+        `No new company was created. Your account already has active company '${parsed.data.name}' (${parsed.data.slug}); requested '${companyName}' was not provisioned. Run '${cliBrand.binName} tenants' to see companies or '${cliBrand.binName} use ${parsed.data.slug}' to keep working there.
+`
+      );
+      return exitCode.exitCode;
+    }
     io.stdout.write(
-      `Company '${companyName}' is ready and active. Run '${cliBrand.binName} onboard status' to continue setup.
+      `Company '${parsed.data.name}' is ready and active. Run '${cliBrand.binName} onboard status' to continue setup.
 `
     );
   }
-  return exitCode;
+  return exitCode.exitCode;
 }
 async function runSignup(io, appUrl2, openBrowser2 = tryOpenBrowser) {
   const url2 = signupUrl(appUrl2);
@@ -48716,9 +48743,12 @@ async function main(argv = process.argv.slice(2), options = {}) {
     return 0;
   }
   let signupCompany = null;
+  let signupJson = false;
   if (command === "signup") {
     try {
-      signupCompany = parseSignupCompany(args).companyName;
+      const signupOptions = parseSignupCompany(args);
+      signupCompany = signupOptions.companyName;
+      signupJson = signupOptions.json;
     } catch (error51) {
       io.stderr.write(`${redactForLog(error51 instanceof Error ? error51.message : String(error51))}
 `);
@@ -48825,7 +48855,7 @@ Run ${cliBrand.binName} login --device again if the next command asks you to aut
     await maybePrintSignupBootstrap(io, client, config2.appUrl);
   }
   if (command === "signup") {
-    return runSignupProvision(io, client, signupCompany, (signupIo, signupClient, commandId, body) => printCommandOutput(signupIo, signupClient, commandId, body));
+    return runSignupProvision(io, client, signupCompany, (signupIo, signupClient, commandId, body) => executeCommandWithResult(signupIo, signupClient, commandId, body), { json: signupJson });
   }
   if (command === "whoami") {
     return printCommandOutput(io, client, "user.whoami");
@@ -49158,6 +49188,14 @@ async function printCommandOutput(io, client, commandId, body = {}, format, opti
     return printCommandError2(io, error51);
   }
 }
+async function executeCommandWithResult(io, client, commandId, body = {}) {
+  try {
+    const result = await client.execute(commandId, body);
+    return { exitCode: 0, output: result.output };
+  } catch (error51) {
+    return { exitCode: printCommandError2(io, error51) };
+  }
+}
 function pendingConfirmationFromError2(error51) {
   if (!(error51 instanceof CommandClientError) || !error51.response || error51.response.ok || error51.response.error.code !== "COMMAND_CONFIRMATION_REQUIRED") {
     return null;