@rosthq/cli 0.5.25 → 0.5.27

package/dist/index.js

@@ -42145,7 +42145,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-21.4",
+    version: "2026-06-27.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -42155,6 +42155,7 @@ Decisions should be recorded as human decisions. Handoffs should attach to seats
       "agent.status",
       "agent.list_fleet",
       "agent.fleet_digest",
+      "system.health",
       "agent_setup.get",
       "agent_setup.update",
       "agent.decommission",
@@ -42235,11 +42236,19 @@ Provider requests carry only the model payload the runtime needs; run attributio
 
 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.
 
+## Company guardrails
+
+Beyond each seat's own manifest, the company can set one ceiling on how much an agent may do *autonomously*. Every tool's scope carries an autonomous-risk level \u2014 reading and drafting are low, writing-with-approval is high, and unrestricted access is critical; an unrecognized tool is treated as critical, never as safe. The guardrail caps that risk for the whole organization through a named profile (locked down, balanced, high autonomy, or a custom ceiling), with balanced as the default. An autonomous call that stays within the ceiling runs as usual; an autonomous call above it is treated as needing a human instead of acting on its own. Calls that are already human-gated or being escalated are never affected \u2014 the ceiling only ever narrows autonomous action, it never blocks the human-approval path. New organizations start balanced and in a watch-only mode, so the guardrail first reports where it would intervene before it begins enforcing.
+
 ## 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. 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, loaded Skill versions, 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, 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. Shared system-health summaries use the same server-derived tenant, member, or seat-token scope so UI, CLI, and MCP operators see consistent stalled-work, unresolved-error, runner, and notification counts without client-supplied tenant boundaries. 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.
+
+For an operational audit, start with the \`/health\` dashboard or \`{{cli}} system health --json\` / \`system.health\` / \`rost_system_health\` before manually chaining fleet, run, Signal, Friction, task, integration, runner, and Sync commands. The dashboard, CLI, and MCP tool share the same command-backed system-health model, with server-derived tenant, member, requested-seat, or seat-token scope. Owners see tenant health; members see occupied-seat subtrees; seat-scoped tokens see their own seat plus authorized downstream seats, and optional \`seat_id\` narrowing can only reduce that server-derived scope. Seat pages link to \`/health?seat_id=<seat>\` for scoped follow-up. Every health finding includes a remediation action with a human label/link plus command id, schema reference, CLI command, help text, and human-gated marker for agents. Open Friction without an action task links to the Friction detail and gives agents the \`task.create\` then \`friction.link_task\` next step; the final issue resolution still requires the human \`friction.resolve\` decision.
+
+Use the lower-level commands after health names a finding: \`agent.get_run\` for a specific failed run, \`signal.list\` for off-track readings, \`task.list\` for the owning seat's queue, \`integration.status\` or \`integration.test\` for connector evidence, \`runner.list\` / \`runner.diagnose\` for local-runner repair, and \`sync.brief.compile\` for missing Sync Briefs. 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",
@@ -42384,7 +42393,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-21.15",
+    version: "2026-06-27.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -43011,6 +43020,8 @@ Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`
 | \`rost_update_sync_brief_scope\` | \`settings.sync_brief_scope.update\` | Set the tenant's Sync Brief scope (company_wide or per_cluster). | Tenant-admin | Owner-only; call with \`{"sync_brief_scope":"company_wide"}\` or \`{"sync_brief_scope":"per_cluster"}\`. |
 | \`rost_get_product_learning_policy\` | \`settings.product_learning.get\` | Read whether product/page/recommendation analytics are allowed. | Tenant | Call with \`{}\`; audit/security logs are always enabled. |
 | \`rost_update_product_learning_policy\` | \`settings.product_learning.update\` | Set product-learning mode. | Tenant-admin | Human-gated; call with \`{"mode":"enabled"}\`, \`{"mode":"disabled"}\`, or \`{"mode":"enterprise_contract"}\`. |
+| \`rost_get_company_autonomy_ceiling\` | \`settings.agent_policy.get\` | Read the company autonomy ceiling (Company Guardrails): profile, enforcement, and max_autonomous_risk. | Tenant | Call with \`{}\`; metadata only. |
+| \`rost_set_company_autonomy_ceiling\` | \`settings.agent_policy.update\` | Set the company autonomy ceiling. | Tenant-admin | Owner-only, human-gated; call with \`{"profile":"locked_down"}\` (or \`balanced\`/\`high_autonomy\`, or \`{"profile":"custom","max_autonomous_risk":"high"}\`). Enforced by default. |
 | \`rost_list_signals\` | \`signal.list\` | List measurables with their latest reading and on/off-track state. | Seat or tenant-admin | Call with \`{}\` to find measurable ids. |
 | \`rost_get_signal\` | \`signal.get\` | Read a measurable with its full reading history. | Seat or tenant-admin | Call with \`{"measurable_id":"<id>"}\`. |
 | \`rost_confirm_signal_reading\` | \`signal.confirm_reading\` | Confirm an unconfirmed reading as human-verified. | Seat or tenant-admin | Humans confirm; call with \`{"reading_id":"<id>"}\`. |
@@ -43741,7 +43752,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-20.1",
+    version: "2026-06-27.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -43780,6 +43791,10 @@ In the app, the evidence is shown as a legible card, not raw data: a proposed to
 
 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.
 
+## How escalations reach you
+
+An escalation reaches you the same way no matter how the agent raised it \u2014 in a chat or CLI session, or on its own scheduled cloud run. When the agent stops at a boundary it opens the queue item and sends a notification to the accountable human along the steward chain, preferring a connected Slack channel and falling back to email. If no human occupies the agent's seat, the chain walks up to the next Steward. Delivery is idempotent: a retried run never notifies you twice for the same escalation, and the notification carries only summarized, redacted evidence \u2014 never secret material.
+
 ## Work the queue from CLI or MCP
 
 The Steward reads the queue from any surface but decides as a human.
@@ -43801,7 +43816,7 @@ Keep agent scope tight at first. Approve more autonomy only after evidence. Use
     order: 71,
     title: "Confirmations and human gates guide",
     summary: "How {{brand}} routes authority-changing work through human confirmation, and why agents never approve their own requests.",
-    version: "2026-06-20.2",
+    version: "2026-06-27.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["graph_design", "charter_design", "staffing", "operating_rhythm"],
@@ -43836,6 +43851,8 @@ The \`dangerous\` confirmation **level** is rare and is not the same as the **ri
 
 A gated command does not mutate when an agent calls it. It returns a pending confirmation with the command id, a risk level, and an \`approveVia\` block containing a web URL and the exact \`{{cli}} command confirmation.approve --json ...\` line. The human approves through the web link or the CLI; the agent surfaces the link and stops. A logged-in human at an interactive CLI can run their own gated \`{{cli}} command <id>\` without copy-pasting the approval command because the CLI completes the returned confirmation inline.
 
+When an **agent** triggers a gate, {{brand}} also notifies the seat's steward (Slack with an email fallback) so the held action does not sit silent \u2014 a human is told a decision is waiting and given the approve link. A human pausing their own gated command does not self-notify. See the notifications guide.
+
 \`\`\`bash
 # Human approves a pending confirmation
 {{cli}} command confirmation.approve --json '{"confirmation_id":"<confirmation-id>"}'
@@ -43843,6 +43860,10 @@ A gated command does not mutate when an agent calls it. It returns a pending con
 {{cli}} command confirmation.reject --json '{"confirmation_id":"<confirmation-id>"}'
 \`\`\`
 
+## The approvals queue
+
+The \`/approvals\` page is one place a human clears every pending decision across the company. It unions still-pending confirmations with open steward escalations into a single queue, each item shown with its risk, the source seat, and redacted arguments \u2014 secret material is never displayed. You see only items for seats you have authority over: an owner sees all of them; a member sees confirmations for the seats they occupy and escalations routed to their steward chain, and nothing else. Approve and reject route through the same \`confirmation.approve\` / \`confirmation.reject\` and escalation decision commands the CLI and per-seat surfaces use, so the audit trail and the agents-recommend-humans-decide rule are identical wherever you act.
+
 ## The rule for agents
 
 An agent never approves or rejects its own request. \`decisions.decided_by\` is always a human. The steward decision commands (\`escalation.resolve\`, \`escalation.reject\`) are not even exposed over MCP. When an agent hits a gate, it prepares the evidence and the recommended action, returns the approve link, and waits for a human.
@@ -43856,11 +43877,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-21.4",
+    version: "2026-06-27.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
-    relatedCommandIds: ["onboarding.create_invite", "mcp_token.create", "mcp_token.revoke", "mcp_token.list", "integration.list", "integration.readiness", "integration.status", "integration.test", "settings.get", "settings.update", "tenant.rename", "settings.sync_brief_scope.get", "settings.sync_brief_scope.update", "settings.product_learning.get", "settings.product_learning.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", "tenant.rename", "settings.sync_brief_scope.get", "settings.sync_brief_scope.update", "settings.product_learning.get", "settings.product_learning.update", "settings.agent_policy.get", "settings.agent_policy.update"],
     legal: { publicRisk: "low", notes: ["{{brand}}-native settings guidance."] },
     sources: [
       {
@@ -43913,7 +43934,13 @@ Product-learning participation controls whether {{brand}} may record product/pag
 
 Read the policy with \`settings.product_learning.get\` (CLI: \`{{cli}} settings product-learning get\`). Change it with \`settings.product_learning.update\` (CLI: \`{{cli}} settings product-learning update --mode disabled\`). Analytics ingestion code should call the shared product-learning policy helper instead of reading \`tenants.settings\` directly.
 
-The product analytics foundation stores only bounded product telemetry: product events, page views by route template, command invocation metadata, onboarding milestones, and recommendation outcomes. Authenticated users can read analytics rows for their tenant, but writes are server-owned through the trusted DB helpers. The helpers and database constraints reject or redact obvious raw URLs, filesystem paths, secrets, prompt/content fields, command argument/output fields, direct contact/payment identifiers, and long prose-shaped values. These analytics rows are not audit records; operational logs and security evidence stay in their dedicated append-only or product-visible tables.
+The product analytics foundation stores only bounded product telemetry: product events, page views by route template, command invocation metadata, onboarding milestones, and recommendation outcomes. Recommendation outcomes use bounded statuses such as \`shown\`, \`accepted\`, \`edited\`, \`rejected\`, \`dismissed\`, and \`reversed\`; current instrumented paths include model-tier recommendations from \`agent.create_custom\` and Charter seat-type recommendations from the Charter lifecycle. These rows store safe enums/categories and fingerprints, not raw responsibility answers, Charter prose, prompt text, tool arguments, or customer content. Authenticated users can read analytics rows for their tenant, but writes are server-owned through the trusted DB helpers. The helpers and database constraints reject or redact obvious raw URLs, filesystem paths, secrets, prompt/content fields, command argument/output fields, direct contact/payment identifiers, and long prose-shaped values. These analytics rows are not audit records; operational logs and security evidence stay in their dedicated append-only or product-visible tables.
+
+The authenticated web app records first-party page views and product events through route templates, not raw full URLs or query strings. The ingestion route resolves tenant and user server-side, caps client batches, validates enriched payloads with the shared protocol schemas, and treats product-learning opt-out as a skipped analytics write rather than a product error.
+
+Onboarding milestones are recorded from durable server-side transitions such as company setup, graph review, first Charter draft, first agent setup/dry run/pass/live, first Signal, first goal, Sync rhythm start, and onboarding finish. They are idempotent per tenant and milestone: repeated UI, CLI, MCP, or system calls keep the earliest product-learning timestamp instead of creating duplicate funnel steps. The append-only event log remains the audit timeline; onboarding milestone rows are a bounded analytics projection and are skipped when product learning is disabled.
+
+Command invocation analytics are emitted from the central command executor for UI, CLI, and MCP calls. They store command id, source, actor/scope kind, outcome class, duration, confirmation flag, guard result, request id when UUID-shaped, safe error code, and bounded changed ids. They do not store raw command arguments or outputs. The command outcome classes are \`ok\`, \`denied\`, \`pending_confirmation\`, \`validation_error\`, \`precondition_error\`, \`authorization_error\`, and \`internal_error\`. Product analytics write failures are ignored so they cannot mask the command result or replace audit/security records.
 
 ## Inference budget
 
@@ -43923,6 +43950,16 @@ Agents that run on {{brand}}-managed inference draw against a tenant inference b
 - The sandbox dry run is free and is never blocked by the cap, so a fresh company can charter, dry-run, and take an agent live before setting a budget. The cap applies only to real managed-inference runs.
 - A company that brings its own provider key (BYOK) is metered on that key and is not subject to the {{brand}}-managed hard cap. BYOK changes the provider account used for eligible cloud calls, not the Charter, tool guard, human gate, or data-retention posture; see the ai-model-data-handling-guide before making provider-handling claims.
 
+## Company autonomy ceiling (Company Guardrails)
+
+The company autonomy ceiling is a single tenant-wide dial that caps how much ANY agent may do **without a human in the loop**. It is the fourth governance gate, after the signed manifest, the budget, and before escalation \u2014 it never replaces them. It only ever constrains AUTONOMOUS (always_allow) actions; a tool already routed to a human (always_ask), an explicit escalation, a connector that already escalated, or secret-shaped input is never blocked by the ceiling.
+
+- Read it with \`settings.agent_policy.get\` (CLI: \`{{cli}} settings agent-policy get\`).
+- Set it with \`settings.agent_policy.update\` (CLI: \`{{cli}} settings agent-policy set --profile locked_down\`). Owner-only and human-gated.
+- Profiles are named ceilings: \`locked_down\` (agents autonomously read/draft only; every write/send escalates), \`balanced\` (the default; read/draft autonomous, writes escalate), \`high_autonomy\` (approval-marked write tools may run autonomously; only full-access escalates), and \`custom\` + \`max_autonomous_risk\` (\`low\`, \`medium\`, \`high\`, \`critical\`).
+- An explicitly set ceiling is ENFORCED by default. Enforcement has two modes: \`enforce\` blocks an over-ceiling autonomous call and routes it to the steward (it is never a dead-end deny \u2014 a human can still approve), and \`observe\` allows the call but logs it. The platform default for a company that never set a policy is balanced + observe, so existing live agents are never retro-bricked.
+- When enforcement is on, signing a manifest or taking an agent live is REFUSED if the manifest grants always_allow to a tool whose risk exceeds the ceiling; the error names the exact ceiling, tool, and risk in its \`details\`. Lower that tool to always_ask, or raise the ceiling, then retry.
+
 ## Agent guidance
 
 Agents may explain which setting is needed and why. They should not ask users to paste secrets into chat or tool arguments. When credentials are required, route the user to the vault-backed setup flow.`
@@ -43966,7 +44003,7 @@ When a user asks to add a person, clarify whether they mean app access, seat occ
     order: 74,
     title: "Notifications guide",
     summary: "How {{brand}} should notify humans about decisions, escalations, stale work, and agent boundaries.",
-    version: "2026-06-19.1",
+    version: "2026-06-27.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -43987,6 +44024,7 @@ Notifications should move decisions to the right human without turning {{brand}}
 
 - An agent hits a must-escalate condition.
 - A tool or credential approval is needed.
+- An agent holds a durable command behind a pending confirmation \u2014 the seat's steward is notified so the held action does not sit silent. A human pausing their own gated command does not self-notify.
 - A Signal is broken or stale.
 - A Friction item needs a decision.
 - A Sync decision creates a handoff.
@@ -44244,7 +44282,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-21.4",
+    version: "2026-06-22.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing", "operating_rhythm"],
@@ -44269,27 +44307,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-21."
+        note: "Official API data-use and retention controls verified 2026-06-22."
       },
       {
         label: "OpenAI enterprise privacy",
         url: "https://openai.com/enterprise-privacy/",
-        note: "Official enterprise privacy and API retention summary verified 2026-06-21."
+        note: "Official enterprise privacy and API retention summary verified 2026-06-22."
       },
       {
         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-21."
+        note: "Official Codex plan data-control scope verified 2026-06-22."
       },
       {
         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-21."
+        note: "Official Claude API ZDR, HIPAA, and retention scope verified 2026-06-22."
       },
       {
         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-21."
+        note: "Official local Claude Code data-flow, training, and retention summary verified 2026-06-22."
       },
       {
         label: "Reference corpus and docs spec",
@@ -44392,15 +44430,15 @@ 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-21, 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-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 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-21, 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-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 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.
 
 For local Claude Code clients running through \`mcp_session\` or \`runner\`, check whether the customer is using a consumer, team, enterprise, API, or third-party-platform path. Official Claude Code documentation separately describes consumer versus commercial handling, local transcript storage, telemetry, feedback, and provider-specific defaults.
 
-Use those statements only as current provider-doc summaries. Do not convert them into a blanket {{brand}} claim. The correct customer-facing answer is: "Here is the lane, here is what {{brand}} sends, here is which provider account or local client handles it, and here is what to verify in that account before treating the workflow as no-training, zero-retention, HIPAA-ready, or region-bound."
+Use those statements only as current provider-doc summaries. Do not convert them into a blanket {{brand}} claim. The correct customer-facing answer is: "Here is the lane, here is what {{brand}} sends, here is which provider account or local client handles it, and here is what to verify in that account before treating the workflow as no-training, zero-retention, HIPAA-ready, or region-bound." If a customer or prospect asks for a DPA, BAA, SOC 2 report, regional processing commitment, customer-managed retention window, staff-access approval workflow, or customer-visible staff-access log, escalate instead of answering from this guide.
 
 ## Agent response checklist
 
@@ -44410,7 +44448,8 @@ When asked about AI data handling:
 2. Name the specific data classes that can enter the prompt or tool result.
 3. Name whether the provider path is platform-managed, tenant BYOK Anthropic, local client/account, or runner-controlled.
 4. Warn if the answer depends on provider settings, contract terms, ZDR approval, HIPAA readiness, model choice, endpoint, or third-party tool policy.
-5. Recommend the smallest safe next step: narrow the tool scope, use a vault ref, redact the input, switch to the approved provider account, or escalate for human/legal review.`
+5. Escalate contractual, compliance, regional-processing, customer-managed retention, or staff-access-commitment questions instead of answering from this guide.
+6. Recommend the smallest safe next step: narrow the tool scope, use a vault ref, redact the input, switch to the approved provider account, or escalate for human/legal review.`
   },
   {
     slug: "security-model-guide",
@@ -46599,6 +46638,30 @@ var settingsWrapper = (context, args) => dispatch(context, "settings", args, {
       });
     }
   }, settingsUsage(ctx.binName)),
+  "agent-policy": (ctx, rest) => dispatch(ctx, "settings agent-policy", rest, {
+    get: (innerCtx, innerRest) => {
+      const parsed = parseFlags(innerRest);
+      return execute(innerCtx, parsed, "settings.agent_policy.get", {}, (output) => {
+        const policy = asRecord(asRecord(output).agent_policy);
+        return `agent_policy profile=${field(policy, "profile")}  enforcement=${field(policy, "enforcement")}  max_autonomous_risk=${field(policy, "max_autonomous_risk")}  explicit=${field(policy, "explicit")}`;
+      });
+    },
+    set: (innerCtx, innerRest) => {
+      const parsed = parseFlags(innerRest);
+      const profile = optionalValue(parsed, "profile");
+      if (profile !== "locked_down" && profile !== "balanced" && profile !== "high_autonomy" && profile !== "custom") {
+        throw new UsageError("Provide --profile locked_down|balanced|high_autonomy|custom.");
+      }
+      const body = withOptional({ profile }, {
+        max_autonomous_risk: optionalValue(parsed, "max-autonomous-risk"),
+        enforcement: optionalValue(parsed, "enforcement")
+      });
+      return execute(innerCtx, parsed, "settings.agent_policy.update", body, (output) => {
+        const policy = asRecord(asRecord(output).agent_policy);
+        return `Set company autonomy ceiling to ${field(policy, "profile")} (max_autonomous_risk=${field(policy, "max_autonomous_risk")}, enforcement=${field(policy, "enforcement")}).`;
+      });
+    }
+  }, settingsUsage(ctx.binName)),
   get: (ctx, rest) => {
     const parsed = parseFlags(rest);
     return execute(ctx, parsed, "settings.get", {}, (output) => {
@@ -46635,11 +46698,13 @@ var settingsWrapper = (context, args) => dispatch(context, "settings", args, {
   }
 }, settingsUsage(context.binName));
 function settingsUsage(bin) {
-  return `Usage: ${bin} settings get|update|product-learning|rename [--json]
+  return `Usage: ${bin} settings get|update|product-learning|agent-policy|rename [--json]
   ${bin} settings get
   ${bin} settings update [--soft-cap-usd <n>] [--hard-cap-usd <n>]
   ${bin} settings product-learning get
   ${bin} settings product-learning update --mode enabled|disabled|enterprise_contract
+  ${bin} settings agent-policy get
+  ${bin} settings agent-policy set --profile locked_down|balanced|high_autonomy|custom [--max-autonomous-risk low|medium|high|critical] [--enforcement enforce|observe]
   ${bin} settings rename --company <name>`;
 }
 var memberWrapper = (context, args) => dispatch(context, "member", args, {
@@ -47366,7 +47431,10 @@ function formatSystemHealth(output) {
     lines.push("top_actions:");
     for (const action of actions) {
       const item = asRecord(action);
-      lines.push(`  ${field(item, "label")}  command=${field(item, "command_id")}  cli=${field(item, "cli")}`);
+      lines.push(`  ${field(item, "label")}  command=${field(item, "command_id")}  schema=${field(item, "schema_ref")}  cli=${field(item, "cli")}`);
+      if (field(item, "help") !== "\u2014") {
+        lines.push(`    ${field(item, "help")}`);
+      }
     }
   }
   const fleet = asRecord(sections.fleet);