@rosthq/cli 0.5.19 → 0.5.21

package/dist/index.js

@@ -41910,11 +41910,11 @@ No orphan agents. No raw secrets in prompts, logs, or tool arguments. No durable
     order: 41,
     title: "Add agents to your Responsibility Graph",
     summary: "The visual journey for adding an agent seat: where to start, choosing a mode, placing the seat, naming a Steward, setup, the safety gates, and go-live.",
-    version: "2026-06-21.1",
+    version: "2026-06-21.3",
     public: true,
     audiences: ["human", "in_app_agent"],
     stages: ["staffing"],
-    relatedCommandIds: ["agent_template.list", "agent_setup.start", "agent.create_from_template", "agent.create_custom", "agent.run_dry_run", "agent.go_live", "staffing.assign_user", "confirmation.approve"],
+    relatedCommandIds: ["agent_template.list", "agent_setup.start", "agent.create_from_template", "agent.create_custom", "skill.list", "skill.catalog", "skill.check_dependencies", "skill.assign_to_seat", "agent.run_dry_run", "agent.go_live", "staffing.assign_user", "confirmation.approve"],
     legal: { publicRisk: "low", notes: ["{{brand}}-native visual guidance for the agent-creation journey."] },
     sources: [
       {
@@ -41984,18 +41984,20 @@ Reopening the builder for a seat whose agent is already live shows its live stat
 - Parent or Steward seat archived during setup: go-live is blocked until you choose a live parent or reassign the Steward.
 - Failed dry run or a declined tool: the draft is preserved; fix the Charter or tool decision and rerun. See the troubleshooting guide.
 
-In read-only or demo mode the **Add agent** affordance never starts a write. The public demo instead replays the add-an-agent journey end to end \u2014 describe the role, watch the draft Charter assemble, see the four safety gates light, and watch a sandbox dry run reach the must-escalate boundary and stop \u2014 then routes go-live to sign-up, because going live is a human decision.`
+In read-only or demo mode the **Add agent** affordance never starts a write. The public demo instead replays the add-an-agent journey end to end \u2014 describe the role, watch the draft Charter assemble, see the four safety gates light, and watch a sandbox dry run reach the must-escalate boundary and stop \u2014 then routes go-live to sign-up, because going live is a human decision.
+
+For CLI and MCP setup, read agent-skill-setup-guide before adding or assigning Skills. List existing company Skills and the {{brand}} catalog first, read the full Skill file before proposing it, and run the dependency check before sign-off. A missing required Skill tool is fixed by updating the Charter permission manifest through tool configuration; it is never fixed by treating the Skill as authorization.`
   },
   {
     slug: "custom-agents-guide",
     order: 42,
     title: "Design a custom agent",
     summary: "How to build a custom agent from operational questions through the Charter Builder, tools, dry run, and go-live without writing prompts.",
-    version: "2026-06-18.4",
+    version: "2026-06-21.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "charter_design"],
-    relatedCommandIds: ["agent_setup.start", "agent_setup.get", "agent_setup.update", "agent.create_custom", "agent.configure_tools", "agent.run_dry_run", "agent.go_live", "charter.draft", "charter.sign_manifest", "credential.ingress", "confirmation.approve"],
+    relatedCommandIds: ["agent_setup.start", "agent_setup.get", "agent_setup.update", "agent.create_custom", "skill.list", "skill.catalog", "skill.get", "skill.file.get", "skill.check_dependencies", "skill.assign_to_seat", "agent.configure_tools", "agent.run_dry_run", "agent.go_live", "charter.draft", "charter.sign_manifest", "credential.ingress", "confirmation.approve"],
     legal: { publicRisk: "low", notes: ["{{brand}}-native custom-agent guidance."] },
     sources: [
       {
@@ -42050,8 +42052,11 @@ The same path is command-backed:
 1. \`agent_setup.start\` / \`rost_start_agent_setup\` with mode \`custom\` returns a \`setup_id\`.
 2. Iterate with \`agent_setup.get\` and \`agent_setup.update\` (parent, Steward, lane, schedule, and the operational answers).
 3. \`agent.create_custom\` / \`rost_create_custom_agent\` seeds a \`custom\` agent and a draft Charter from the operational answers only.
-4. \`agent.configure_tools\` / \`rost_configure_agent_tools\` records connect/decline decisions and credential-ingress requests (vault refs only).
-5. \`agent.run_dry_run\` / \`rost_run_agent_dry_run\` rehearses the task after the manifest is signed.
+4. Read \`skill.list\` / \`rost_list_skills\` and, when appropriate, \`skill.catalog\` / \`rost_list_rost_skill_catalog\`; inspect \`skill.get\` plus \`skill.file.get\` for the full \`SKILL.md\` before asking a tenant-admin or human operator to assign a Skill.
+5. Run \`skill.check_dependencies\` before assignment. Missing required tools are blockers for approval; optional tools are warnings. Resolve required blockers through \`agent.configure_tools\`, not by changing the Skill.
+6. A tenant-admin command caller can propose the Skill with \`skill.assign_to_seat\` / \`rost_assign_skill_to_seat\` after dependency checks; a seat-scoped agent escalates the assignment request instead of calling that command.
+7. \`agent.configure_tools\` / \`rost_configure_agent_tools\` records connect/decline decisions and credential-ingress requests (vault refs only).
+8. \`agent.run_dry_run\` / \`rost_run_agent_dry_run\` rehearses the task after the manifest is signed.
 
 ## Dry run and go-live
 
@@ -42140,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.1",
+    version: "2026-06-21.3",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -42326,7 +42331,7 @@ There is exactly one way to give a connected tool its credential, and it is the
     order: 47,
     title: "Available tools guide",
     summary: "How to think about tool categories available to seats and what each category should be used for.",
-    version: "2026-06-20.4",
+    version: "2026-06-21.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -42379,7 +42384,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.5",
+    version: "2026-06-21.11",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -42419,6 +42424,22 @@ External connectors are being rolled out provider by provider, conservatively (r
       "agent.get_run",
       "agent.list_runs",
       "agent.list_tool_calls",
+      "skill.list",
+      "skill.catalog",
+      "skill.enable_catalog",
+      "skill.install_local",
+      "skill.sync_local",
+      "skill.get",
+      "skill.file.get",
+      "skill.assigned.list",
+      "skill.check_dependencies",
+      "skill.create",
+      "skill.update_draft",
+      "skill.import_github",
+      "skill.import_upload",
+      "skill.publish",
+      "skill.assign_to_seat",
+      "skill.revoke_from_seat",
       "integration.list",
       "integration.readiness",
       "integration.status",
@@ -42545,7 +42566,7 @@ For CI, do not run an interactive device login on every job (a device code still
 
 ## First-run path
 
-This is the install/auth quickstart \u2014 it gets you logged in, MCP registered, and onboarding started. It is a convenience view, not the full org-setup procedure: for the canonical end-to-end setup order beyond install, \`agent-reference-map\` is the source of truth (its 19-step Standard Setup Order). Read it with \`{{cli}} reference get agent-reference-map\` (step 6 below).
+This is the install/auth quickstart \u2014 it gets you logged in, MCP registered, and onboarding started. It is a convenience view, not the full org-setup procedure: for the canonical end-to-end setup order beyond install, \`agent-reference-map\` is the source of truth. Read it with \`{{cli}} reference get agent-reference-map\` (step 6 below).
 
 1. Log in: \`npx {{cliPackage}}@latest login\` (or \`{{cli}} login --device\` for a headless agent)
 2. Confirm identity: \`{{cli}} whoami\`
@@ -42702,12 +42723,12 @@ A leaked tenant-admin token can administer the whole tenant, not just one seat.
 
 ### Storing the Anthropic key and other credentials
 
-Storing the tenant model key or any other secret goes through **credential ingress** as a vault reference \u2014 the secret is never pasted into a prompt, config, or log. Use \`rost_save_tenant_anthropic_key\` (\`tenant.anthropic_key.save\`) for the tenant Anthropic key, or \`rost_store_credential\` (\`credential.ingress\`) for other secrets; \`rost_configure_agent_tools\` stages credential requests but never accepts raw secrets. Credential storage is a gated \`credential_flow\` confirmation that a human approves. For the vault model and the security posture behind this, see the security-model-guide and the tool-access-and-vault guide; for the confirmation gate, see the confirmations-guide.
+Storing the tenant model key or any other secret goes through **credential ingress** as a vault reference \u2014 the secret is never pasted into a prompt, config, or log. Use \`rost_save_tenant_anthropic_key\` (\`tenant.anthropic_key.save\`) for the tenant Anthropic key, or \`rost_store_credential\` (\`credential.ingress\`) for other secrets; \`rost_configure_agent_tools\` stages credential requests but never accepts raw secrets. Credential storage is a gated \`credential_flow\` confirmation that a human approves. For the vault model and the security posture behind this, see the security-model-guide and the tool-access-and-vault guide; for model-bound data, BYOK provider handling, and local-client provider settings, see the ai-model-data-handling-guide; for the confirmation gate, see the confirmations-guide.
 
 ## When to use MCP or CLI
 
 - A technical operator wants to drive onboarding from a local agent session.
-- A partner wants to use their own local model subscription.
+- A partner wants to use their own local model subscription. Read the ai-model-data-handling-guide first so the operator can verify the local provider account, retention, telemetry, and transcript settings instead of assuming {{brand}} controls them.
 - A Steward wants a local agent to inspect context, draft changes, or prepare work.
 - A developer wants repeatable setup commands.
 
@@ -42799,13 +42820,13 @@ The signed-in app exposes the same Skill command surface under **Skills** in the
 | \`{{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|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}} settings get|update|product-learning\` | \`settings.get\`, \`settings.update\`, \`settings.product_learning.get\`, \`settings.product_learning.update\` | Read tenant settings, update budget caps, and read or update product-learning participation. Product-learning updates stop at human confirmation in non-interactive CLI/MCP sessions. | Tenant / Tenant-admin for updates | \`{{cli}} settings product-learning get --json\`; \`{{cli}} settings product-learning update --mode disabled --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\` |
+| \`{{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. Human CLI dry-runs print the rehearsal transcript and, when present, the per-tool preview labels (\`Would run\`, \`Blocked\`, \`Escalated\`) before go-live. Create and go-live stop at human gates; the dry-run is ungated by human approval but requires a signed manifest first. | Tenant and seat | \`{{cli}} agent fleet-digest --json\` |
 | \`{{cli}} tools list\` | \`tool.catalog\` | List the discoverable tool catalog the builder reads (id, scope tiers, credential requirement, access policy, and execution-boundary guidance). | Tenant | \`{{cli}} tools list --json\` |
-| \`{{cli}} skills list|get|file|assigned|check-dependencies\` | \`skill.list\`, \`skill.get\`, \`skill.file.get\`, \`skill.assigned.list\`, \`skill.check_dependencies\` | Discover reusable Skills, read descriptors and stored package files, list approved Seat assignments, and compare required/optional tool dependencies with a Seat's signed Charter manifest. Skills are instructions, not authority. | Tenant and seat | \`{{cli}} skills list --json\`; \`{{cli}} skills file --slug invoice-review --path SKILL.md\` |
-| \`{{cli}} skills catalog|enable|install|sync\` | \`skill.catalog\`, \`skill.enable_catalog\`, \`skill.install_local\`, \`skill.sync_local\` | Discover entitled ROST catalog Skills, enable a catalog Skill into the company library with human confirmation, and install or sync approved Skill files locally from ROST APIs. Private catalog source URLs and GitHub tokens never go to local agents. | Tenant and seat | \`{{cli}} skills sync --seat-id <id> --client codex\`; \`{{cli}} skills install rost/ap-review --seat-id <id> --client codex\` |
-| \`{{cli}} skills create|update-draft|import|publish|assign|revoke\` | \`skill.create\`, \`skill.update_draft\`, \`skill.import_github\`, \`skill.import_upload\`, \`skill.publish\`, \`skill.assign_to_seat\`, \`skill.revoke_from_seat\` | Create or import bounded text Skill packages, publish reviewed immutable versions, propose or approve Seat assignments, and revoke future use without deleting historical activations. Publish, revoke, and approved assignment stop at human confirmation; blocked required tools cannot be approved. | Tenant and seat | \`{{cli}} skills import github --url https://github.com/acme/skills/tree/main/ap --json\`; \`{{cli}} skills assign --seat-id <id> --slug invoice-review --json\` |
+| \`{{cli}} skills list|get|file|assigned|check-dependencies\` | \`skill.list\`, \`skill.get\`, \`skill.file.get\`, \`skill.assigned.list\`, \`skill.check_dependencies\` | Discover reusable Skills, read descriptors and stored package files, list approved Seat assignments, and compare required/optional tool dependencies with a Seat's signed Charter manifest. Skills are instructions, not authority. | Tenant-admin; seat-scoped reads for assigned Skills | \`{{cli}} skills list --json\`; \`{{cli}} skills file --slug invoice-review --path SKILL.md\` |
+| \`{{cli}} skills catalog|enable|install|sync\` | \`skill.catalog\`, \`skill.enable_catalog\`, \`skill.install_local\`, \`skill.sync_local\` | Discover entitled {{brand}} catalog Skills, enable a catalog Skill into the company library with human confirmation, and install or sync approved Skill files locally from {{brand}} APIs. Private catalog source URLs and GitHub tokens never go to local agents. | Tenant-admin for catalog enablement; seat-scoped sync for assigned Skills | \`{{cli}} skills sync --seat-id <id> --client codex\`; \`{{cli}} skills install rost/ap-review --seat-id <id> --client codex\` |
+| \`{{cli}} skills create|update-draft|import|publish|assign|revoke\` | \`skill.create\`, \`skill.update_draft\`, \`skill.import_github\`, \`skill.import_upload\`, \`skill.publish\`, \`skill.assign_to_seat\`, \`skill.revoke_from_seat\` | Create or import bounded text Skill packages, publish reviewed immutable versions, propose Seat assignments, and revoke future use without deleting historical activations. Publish, revoke, and approved assignment stop at human confirmation; blocked required tools cannot be approved. | Tenant-admin writes; seat agents read assignments and escalate requests | \`{{cli}} skills import github --url https://github.com/acme/skills/tree/main/ap --json\`; \`{{cli}} skills assign --seat-id <id> --slug invoice-review --json\` |
 | \`{{cli}} model list\` | \`model.catalog\` | List guided model tiers with recommendations, token prices, cost bands, best-fit work, and model ids for \`--model\`. | Tenant | \`{{cli}} model list --json\` |
 | \`{{cli}} compass show\` | \`compass.show_markdown\` | Render the current Compass as a clean markdown card for review. | Tenant | \`{{cli}} compass show --markdown\` |
 | \`{{cli}} charter show\` | \`charter.show_markdown\` | Render a seat's Charter as a clean markdown card for review. | Tenant | \`{{cli}} charter show --seat-id <id> --markdown\` |
@@ -42825,7 +42846,9 @@ Skills wrapper help:
 {{cli}} skills publish (--slug <slug>|--skill-version-id <id>) [--allow-warnings] [--json]
 \`\`\`
 
-\`{{cli}} skills install\` writes into the client Skills directory and records \`.rost-skill.json\` with \`skill_version_id\`, \`content_sha256\`, source, client, and \`installed_from: "rost_api"\`. Set \`ROST_SKILL_INSTALL_ROOT\` to override the local root in CI or a sandbox. Use \`install\` for one Skill and \`sync\` as the default local-agent command because it installs every approved Skill assigned to the Seat and skips unchanged local copies by hash. Entitlement failures mean the tenant cannot access that ROST catalog tier yet; stale local copies are fixed by rerunning \`sync\`; private catalog access is always served by ROST APIs, not by giving the agent a private GitHub credential.
+\`{{cli}} skills install\` writes into the client Skills directory and records \`.rost-skill.json\` with \`skill_version_id\`, \`content_sha256\`, source, client, and \`installed_from: "rost_api"\`. Set \`ROST_SKILL_INSTALL_ROOT\` to override the local root in CI or a sandbox. Use \`install\` for one Skill and \`sync\` as the default local-agent command because it installs every approved Skill assigned to the Seat and skips unchanged local copies by hash. Entitlement failures mean the tenant cannot access that {{brand}} catalog tier yet; stale local copies are fixed by rerunning \`sync\`; private catalog access is always served by {{brand}} APIs, not by giving the agent a private GitHub credential.
+
+{{brand}}-maintained catalog entries are seeded from first-party Skill packages with stable content hashes, application descriptors, and declared required or optional tool dependencies. Catalog seed validation is fail-closed: a package with parser warnings is not published. Enabling a catalog Skill copies the current immutable version into the company library; later catalog refreshes update the global catalog row but do not silently rewrite already-enabled tenant Skill versions.
 
 ### MCP registration
 
@@ -42961,6 +42984,8 @@ Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`
 | \`rost_update_tenant_settings\` | \`settings.update\` | Update tenant AI budget caps. | Tenant | Call with \`soft_cap_usd\` or \`hard_cap_usd\`; expect human confirmation. |
 | \`rost_get_sync_brief_scope\` | \`settings.sync_brief_scope.get\` | Read the tenant's Sync Brief scope (company_wide or per_cluster). | Tenant | Call with \`{}\`. |
 | \`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_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>"}\`. |
@@ -42989,9 +43014,9 @@ Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`
 | \`rost_show_agent_setup_as_markdown\` | \`agent.show_markdown\` | Render a seat's agent setup, model, steward, tools, and Charter as a clean markdown card for review. | Tenant | Call with \`{"seat_id":"<seat-id>"}\`. |
 | \`rost_list_tool_catalog\` | \`tool.catalog\` | List the discoverable tool catalog the agent builder reads \u2014 id, prescriptive description, scope tiers, credential requirement, access policy, and execution-boundary guidance. | Tenant | Call with \`{}\` or \`{"provider":"google"}\`. |
 | \`rost_list_skills\` | \`skill.list\` | List tenant Skills with application descriptors, dependency metadata, source status, latest version, and assigned Seat count. Seat-scoped reads are available through \`rost://skills\`. | Tenant-admin | Call with \`{}\` or \`{"query":"invoice"}\`. |
-| \`rost_list_rost_skill_catalog\` | \`skill.catalog\` | List entitled ROST catalog Skills. Private catalog source URLs and credentials stay server-side. | Tenant-admin | Call with \`{}\`; use \`{"include_unentitled":true}\` only to inspect tier availability. |
-| \`rost_enable_rost_catalog_skill\` | \`skill.enable_catalog\` | Enable an entitled ROST catalog Skill into the company library with human confirmation. | Tenant-admin | Call with \`{"slug":"rost/ap-review"}\`; non-interactive callers receive a confirmation handoff. |
-| \`rost_install_skill_locally\` | \`skill.install_local\` | Resolve company or entitled ROST catalog Skill files from ROST APIs for a local client install. It returns package files and metadata, not private GitHub URLs. | Tenant-admin | Call with \`{"slug":"invoice-review","client":"codex"}\`; \`rost/<slug>\` enablement may require confirmation. |
+| \`rost_list_rost_skill_catalog\` | \`skill.catalog\` | List entitled {{brand}} catalog Skills. Private catalog source URLs and credentials stay server-side. | Tenant-admin | Call with \`{}\`; use \`{"include_unentitled":true}\` only to inspect tier availability. |
+| \`rost_enable_rost_catalog_skill\` | \`skill.enable_catalog\` | Enable an entitled {{brand}} catalog Skill into the company library with human confirmation. | Tenant-admin | Call with \`{"slug":"rost/ap-review"}\`; non-interactive callers receive a confirmation handoff. |
+| \`rost_install_skill_locally\` | \`skill.install_local\` | Resolve company or entitled {{brand}} catalog Skill files from {{brand}} APIs for a local client install. It returns package files and metadata, not private GitHub URLs. | Tenant-admin | Call with \`{"slug":"invoice-review","client":"codex"}\`; \`rost/<slug>\` enablement may require confirmation. |
 | \`rost_sync_assigned_skills_locally\` | \`skill.sync_local\` | Resolve every approved Skill assigned to a Seat plus revoked local-copy markers for a local client sync. | Tenant-admin | Call with \`{"seat_id":"<seat-id>","client":"codex"}\`; local clients remove revoked copies. |
 | \`rost_get_skill\` | \`skill.get\` | Read one Skill descriptor and latest stored version metadata. Seat-scoped reads are available through \`rost://skills/{slug}\`. | Tenant-admin | Call with \`{"slug":"invoice-review"}\`. |
 | \`rost_get_skill_file\` | \`skill.file.get\` | Read stored Skill package file content by slug and package path; paths resolve only inside the stored package payload. Seat-scoped reads are available through \`rost://skills/{slug}/files/{path}\`. | Tenant-admin | Call with \`{"slug":"invoice-review","path":"SKILL.md"}\`. |
@@ -43062,11 +43087,285 @@ These rows are quick, at-a-glance triage. For deeper auth, tenant, scope, confir
 `
   },
   {
-    slug: "agent-reference-map",
+    slug: "skill-builder-guide",
     order: 49,
+    title: "Skill builder guide",
+    summary: "Create, import, review, publish, and assign reusable Skills without confusing procedures with authority.",
+    version: "2026-06-21.1",
+    public: true,
+    audiences: ["human", "cli", "mcp", "in_app_agent"],
+    stages: ["staffing", "operating_rhythm"],
+    relatedCommandIds: ["skill.list", "skill.catalog", "skill.get", "skill.file.get", "skill.create", "skill.update_draft", "skill.import_github", "skill.import_upload", "skill.publish", "skill.check_dependencies", "skill.assign_to_seat", "skill.revoke_from_seat", "agent.configure_tools", "confirmation.approve"],
+    legal: { publicRisk: "low", notes: ["Public guidance for tenant-authored and imported Skills."] },
+    sources: [
+      {
+        label: "Agent Skills implementation plan",
+        internalPath: "docs/specs/agent-skills-implementation-plan.md",
+        note: "Defines the Skills product boundary, governance model, and setup workflow."
+      }
+    ],
+    body: `# Skill builder guide
+
+Skills are reusable procedure packages. Use them for repeatable work patterns, domain-specific output contracts, local or client workflow setup, examples, templates, and company-standard operating routines.
+
+Skills are not authority. A Skill cannot grant a tool, approve a payment, change a Charter, store a secret, or bypass a human confirmation. The Charter, signed permission manifest, and server-side tool guard remain the control plane.
+
+## When to add a Skill
+
+Add a Skill when the procedure will be reused by more than one task or run:
+
+- A standard operating procedure such as AP exception review, weekly sync health checks, or support triage.
+- A required output contract such as named sections, evidence fields, or review checklist order.
+- A local-agent setup pattern that must be installed into Codex, Claude Code, or another client.
+- A reusable template, example, or evaluation fixture that helps agents produce consistent work.
+
+Do not add a Skill for authorization, secrets, one-off task context, temporary preferences, or rules that belong in the Charter. Put durable authority, must-escalate boundaries, and tool permissions in the Charter and permission manifest.
+
+## Package shape
+
+Every package has a \`SKILL.md\` file and may include bounded support files under \`references/\`, \`templates/\`, \`examples/\`, \`evals/\`, or \`scripts/\`. The frontmatter should define:
+
+- \`application\`: a short summary, when to use the Skill, and when not to use it.
+- \`required_tools\`: tool ids and minimum scope tiers that must exist before an approved assignment can be used safely.
+- \`optional_tools\`: useful tools that produce warnings when absent but do not block assignment.
+
+Use tool ids from \`tool.catalog\` / \`rost_list_tool_catalog\`. Required and optional tool entries are dependency declarations only; they never grant access.
+
+## Create or import
+
+Use the shared command path from the app, CLI, or tenant-admin MCP:
+
+- Create: \`skill.create\` / \`rost_create_skill\` with a bounded text package.
+- Update a draft: \`skill.update_draft\` / \`rost_update_skill_draft\`.
+- Import public GitHub: \`skill.import_github\` / \`rost_import_github_skill\`; {{brand}} records source URL, resolved ref, path, and content hash.
+- Import uploaded text: \`skill.import_upload\` / \`rost_import_uploaded_skill\`; MCP accepts structured text packages, not direct binary uploads.
+
+Imported Skills are untrusted until parsed, scanned, validated, and reviewed. Validation warnings should be fixed before publication.
+
+## Review and publish
+
+Publishing creates an immutable Skill version. Later edits create a new version; they do not rewrite what a prior agent run used. \`skill.publish\` is human-gated. Agent actors may draft or import, but they do not approve publication.
+
+Review before publishing:
+
+- The procedure is reusable and bounded.
+- It contains no secrets, keys, private tokens, or raw credential material.
+- Required tools are truly required; optional tools are not blockers.
+- The output contract does not ask the agent to exceed the Charter.
+- Support files are necessary and small enough to load safely.
+
+## Assign to a Seat
+
+Assignment pins a published immutable version to a Seat. Run \`skill.check_dependencies\` before \`skill.assign_to_seat\`.
+
+Dependency results mean:
+
+- \`ready\`: required tools meet the Skill's minimum scope tiers.
+- \`blocked\`: at least one required tool is missing, declined, or under-scoped. Approval is blocked.
+- \`warning\`: optional tools are missing or under-scoped. Assignment can proceed, but the operator should understand the degraded path.
+
+Fix blockers by updating the Seat's Charter permission manifest through \`agent.configure_tools\` and human sign-off. Do not edit the Skill to pretend authorization exists.
+
+## {{brand}} catalog and local install
+
+The {{brand}} catalog is first-party, entitlement-filtered, and private-source-safe. Use \`skill.catalog\` to list entitled catalog Skills, then \`skill.enable_catalog\` to copy an entitled catalog Skill into the company library with human confirmation. Standard tenants do not see private beta catalog entries unless explicitly entitled.
+
+Use \`skill.install_local\` for one Skill and \`skill.sync_local\` for all approved Skills assigned to a Seat. Local clients receive package files and \`.rost-skill.json\` metadata from {{brand}} APIs; private catalog GitHub URLs, signed URLs, and credentials are not returned.`
+  },
+  {
+    slug: "agent-skill-authoring-guide",
+    order: 50,
+    title: "Agent Skill authoring guide",
+    summary: "How CLI and MCP agents should propose reusable Skills safely.",
+    version: "2026-06-21.2",
+    public: true,
+    audiences: ["cli", "mcp", "in_app_agent"],
+    stages: ["staffing", "operating_rhythm"],
+    relatedCommandIds: ["skill.list", "skill.get", "skill.file.get", "skill.create", "skill.update_draft", "skill.import_github", "skill.import_upload", "skill.publish", "tool.catalog", "confirmation.approve"],
+    legal: { publicRisk: "low", notes: ["Machine-facing authoring guidance for safe Skill creation."] },
+    sources: [
+      {
+        label: "Agent Skills implementation plan",
+        internalPath: "docs/specs/agent-skills-implementation-plan.md",
+        note: "Defines agent-facing authoring constraints and safety boundaries."
+      }
+    ],
+    body: `# Agent Skill authoring guide
+
+Use this guide when you are a CLI or MCP agent asked to create, import, or revise a Skill.
+
+## First, check what already exists
+
+Do not create a duplicate procedure. Before authoring:
+
+1. Read \`agent-reference-map\`.
+2. Run \`skill.list\` / \`rost_list_skills\` and search by the job words.
+3. If the procedure may be first-party, run \`skill.catalog\` / \`rost_list_rost_skill_catalog\`.
+4. Read matching descriptors with \`skill.get\` and the full file with \`skill.file.get\`.
+
+If an existing Skill is close, propose an update draft or assignment instead of a new Skill.
+
+## Decide whether a Skill is appropriate
+
+Create a Skill for repeatable procedures, domain-specific output contracts, local/client setup patterns, reusable examples, and company operating standards.
+
+Do not create a Skill for:
+
+- Authorization or tool access.
+- Secrets, credentials, API keys, or vault refs.
+- One-off evidence that belongs on the task.
+- Temporary style preferences.
+- Charter rules, escalation boundaries, or human decision policy.
+
+If the user asks for authority, update the Charter path. If the user gives one-off evidence, keep it in the task context.
+
+## Authoring checklist
+
+The \`SKILL.md\` body should be short, procedural, and testable. Include:
+
+- A clear title.
+- An \`application.summary\` that says when to use it.
+- \`application.not_for\` for risky or out-of-scope cases.
+- Required and optional tools only when the procedure genuinely needs them.
+- An output contract when consistency matters.
+- Missing-evidence behavior: state what is missing instead of guessing.
+
+Use \`tool.catalog\` before naming a tool. Required tool scope tiers must be the minimum useful scope. Optional tools are for improved delivery, not hidden blockers.
+
+## Safe command path
+
+- Draft: \`skill.create\` or \`skill.update_draft\`.
+- Public GitHub import: \`skill.import_github\` with the URL, ref, and package path.
+- Uploaded text import: \`skill.import_upload\`.
+- Publish: \`skill.publish\` returns a human confirmation. Stop and ask the human to approve or reject.
+
+Never approve your own publication. Never paste secrets into \`SKILL.md\`, support files, command JSON, issue comments, or logs.
+
+## Quality bar
+
+Before handing off, say what the Skill is for, why it is reusable, what tools it depends on, and what human gate remains. If validation warnings exist, fix them or call them out as blockers.`
+  },
+  {
+    slug: "agent-skill-setup-guide",
+    order: 51,
+    title: "Agent Skill setup guide",
+    summary: "CLI and MCP recipes for discovering, reading, dependency-checking, assigning, and locally syncing Skills.",
+    version: "2026-06-21.1",
+    public: true,
+    audiences: ["cli", "mcp", "in_app_agent"],
+    stages: ["staffing", "operating_rhythm"],
+    relatedCommandIds: ["skill.list", "skill.catalog", "skill.enable_catalog", "skill.get", "skill.file.get", "skill.assigned.list", "skill.check_dependencies", "skill.install_local", "skill.sync_local", "skill.import_github", "skill.import_upload", "skill.assign_to_seat", "agent.configure_tools", "confirmation.approve"],
+    legal: { publicRisk: "low", notes: ["Machine-facing setup recipes for Skills over CLI and MCP."] },
+    sources: [
+      {
+        label: "Agent Skills implementation plan",
+        internalPath: "docs/specs/agent-skills-implementation-plan.md",
+        note: "Defines CLI/MCP setup sequence, dependency handling, and local sync behavior."
+      }
+    ],
+    body: `# Agent Skill setup guide
+
+Use this guide before creating, enabling, assigning, or locally installing Skills from CLI or MCP.
+
+## Setup sequence
+
+1. Read \`agent-reference-map\`.
+2. List company Skills: \`skill.list\` / \`rost_list_skills\` or read \`rost://skills\`.
+3. List {{brand}} catalog Skills when needed: \`skill.catalog\` / \`rost_list_rost_skill_catalog\`.
+4. Read descriptors: \`skill.get\` / \`rost_get_skill\` or \`rost://skills/{slug}\`.
+5. Read full files before assignment: \`skill.file.get\` / \`rost_get_skill_file\` or \`rost://skills/{slug}/files/SKILL.md\`.
+6. Check dependencies for the target Seat: \`skill.check_dependencies\` / \`rost_check_skill_dependencies\`.
+7. Tenant-admin command callers propose assignment with \`skill.assign_to_seat\` / \`rost_assign_skill_to_seat\`; seat-scoped agents read assigned Skills and escalate assignment requests to a human or tenant-admin.
+8. After approval, list assignments with \`skill.assigned.list\` or \`rost://seat/{id}/skills\`.
+9. For local clients, run \`skill.sync_local\` / \`rost_sync_assigned_skills_locally\`.
+
+Tenant-admin command callers may propose assignments; seat-scoped agents escalate assignment requests. Humans approve publication, approved assignment, revocation, and Charter or manifest changes.
+
+## Attach an existing company Skill to a new Seat
+
+Tenant-admin CLI:
+
+\`\`\`bash
+{{cli}} skills list --json
+{{cli}} skills get --slug invoice-review --json
+{{cli}} skills file --slug invoice-review --path SKILL.md
+{{cli}} skills check-dependencies --seat-id <seat-id> --slug invoice-review --json
+{{cli}} skills assign --seat-id <seat-id> --slug invoice-review --rationale "Use for AP exception work." --json
+\`\`\`
+
+Tenant-admin MCP:
+
+1. Call \`rost_list_skills\` with \`{}\`.
+2. Call \`rost_get_skill\` and \`rost_get_skill_file\`.
+3. Call \`rost_check_skill_dependencies\` with \`{"seat_id":"<seat-id>","slug":"invoice-review"}\`.
+4. If ready, call \`rost_assign_skill_to_seat\` with \`status:"proposed"\`.
+
+Seat-scoped MCP agents cannot call generated Skill assignment tools. They should read \`rost://seat/{id}/skills\`, read relevant assigned files through \`rost://skills/{slug}/files/{path}\`, and escalate when a new assignment or permission change is needed.
+
+If required tools are blocked, call \`rost_configure_agent_tools\` only when the human wants to amend the permission manifest. Then wait for the normal Charter/tool approval path.
+
+## Enable a {{brand}} catalog Skill and assign it
+
+CLI:
+
+\`\`\`bash
+{{cli}} skills catalog --json
+{{cli}} skills enable rost/ap-exception-brief --json
+{{cli}} skills check-dependencies --seat-id <seat-id> --slug ap-exception-brief --json
+{{cli}} skills assign --seat-id <seat-id> --slug ap-exception-brief --rationale "Use the first-party AP exception procedure." --json
+\`\`\`
+
+\`skill.enable_catalog\` creates a company-owned immutable copy and may return a human confirmation. Do not re-run blindly after approval; read the approval output or list Skills again.
+
+Tenant-admin MCP:
+
+1. Call \`rost_list_rost_skill_catalog\` with \`{}\`.
+2. Call \`rost_enable_rost_catalog_skill\` with \`{"slug":"rost/ap-exception-brief"}\`; if it returns a confirmation, stop for the human approval output.
+3. Call \`rost_check_skill_dependencies\` with the enabled Skill slug and target Seat.
+4. Call \`rost_assign_skill_to_seat\` with \`status:"proposed"\`; do not self-approve assignment.
+
+## Inspect, import, dependency-check, and propose a GitHub Skill
+
+Tenant-admin MCP:
+
+1. Call \`rost_import_github_skill\` with \`{"url":"https://github.com/acme/skills/tree/main/ap","status":"pending_review"}\`.
+2. Read the returned descriptor and validation findings.
+3. Call \`rost_get_skill_file\` for \`SKILL.md\`.
+4. If it should be assignable, ask a human to publish with \`rost_publish_skill\`.
+5. After publication, call \`rost_check_skill_dependencies\`.
+6. Propose assignment with \`rost_assign_skill_to_seat\`.
+
+Uploaded packages use \`rost_import_uploaded_skill\` with structured text files. MCP does not accept direct binary upload in this release.
+
+## Interpret dependency and entitlement output
+
+- \`required_tools\`: must be present at or above \`min_scope_tier\`; missing or under-scoped required tools block approved assignment.
+- \`optional_tools\`: useful but not required; missing optional tools warn only.
+- \`application\`: when to use the Skill and when not to.
+- \`entitlement_status: not_entitled\`: the tenant cannot enable that {{brand}} catalog tier. Do not ask for private source URLs.
+- Duplicate slug or existing company Skill: use the existing Skill or choose a distinct slug; catalog enablement does not overwrite tenant Skills.
+- Local install result \`installed\`, \`unchanged\`, or \`removed\`: the local client wrote, skipped by hash, or removed a revoked copy.
+
+Good assignment: the Seat's Charter already owns AP exception review, the Skill's application matches that work, and \`skill.check_dependencies\` is \`ready\`.
+
+Bad assignment: the Skill requires a payment-write tool the Charter does not grant, or the operator wants the Skill to authorize an approval boundary. Configure the Charter/tool path or choose a narrower Skill instead.
+
+## Local sync
+
+Prefer sync for local agents:
+
+\`\`\`bash
+{{cli}} skills sync --seat-id <seat-id> --client codex --json
+\`\`\`
+
+Set \`ROST_SKILL_INSTALL_ROOT\` only for a sandbox or CI override. Local copies are derived from {{brand}} command output and include \`.rost-skill.json\` metadata. A local copy is not authority; the server still loads assigned immutable Skill versions and still guards every tool call.`
+  },
+  {
+    slug: "agent-reference-map",
+    order: 55,
     title: "Agent reference map",
     summary: "Where CLI sessions, MCP clients, and in-app agents should retrieve {{brand}} guidance before recommending setup changes.",
-    version: "2026-06-20.2",
+    version: "2026-06-21.2",
     public: true,
     audiences: ["cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "graph_design", "charter_design", "staffing", "operating_rhythm"],
@@ -43100,7 +43399,7 @@ Use this map when you are a CLI session, MCP client, or in-app agent and need to
 - Search tool: rost_reference_search
 - Get tool: rost_reference_get
 - Reference resource template: rost://reference/{slug}
-- Operation resources (read-only, scope-enforced): rost://tenant/status, rost://graph, rost://seat/{id}/context, rost://compass/current, rost://sync/latest, rost://operations/reference-map
+- Operation resources (read-only, scope-enforced): rost://tenant/status, rost://graph, rost://seat/{id}/context, rost://compass/current, rost://sync/latest, rost://skills, rost://skills/{slug}, rost://skills/{slug}/files/{path}, rost://seat/{id}/skills, rost://operations/reference-map
 
 Start with rost_reference_search when the user asks a broad question. Use rost_reference_get when a workflow or command metadata already names a guide slug. Read the operation resources to load current tenant/seat facts before mutating; tenant-wide resources need a tenant-admin token and a seat token may read only its own rost://seat/{id}/context.
 
@@ -43141,12 +43440,16 @@ Agents that run on {{brand}}-managed inference draw against a tenant inference b
 11. tool-access-and-vault
 12. available-tools-guide
 13. mcp-and-cli-guide
-14. cascade-guide
-15. signal-guide
-16. friction-guide
-17. confirmations-guide
-18. steward-queue-guide
-19. sync-rhythm-playbook
+14. skill-builder-guide
+15. agent-skill-authoring-guide
+16. agent-skill-setup-guide
+17. ai-model-data-handling-guide
+18. cascade-guide
+19. signal-guide
+20. friction-guide
+21. confirmations-guide
+22. steward-queue-guide
+23. sync-rhythm-playbook
 
 ## Workflow to guide map
 
@@ -43160,6 +43463,9 @@ Read the listed guide before recommending or running each workflow. Every workfl
 - Add an agent through the app (graph or sidebar, visual journey): add-agents-guide.
 - Create an agent from a template: stock-agents-guide, then how-agents-work.
 - Create a custom agent (operational answers, Charter Builder, configure tools, dry run, go live): custom-agents-guide, then agent-staffing-playbook and tool-access-and-vault.
+- Create, import, review, or publish a reusable Skill: skill-builder-guide for human workflow, then agent-skill-authoring-guide for CLI/MCP authoring rules.
+- Assign, dependency-check, enable a catalog Skill, import a GitHub Skill, or sync local Skill files: agent-skill-setup-guide, then mcp-and-cli-guide.
+- Explain AI model data handling, BYOK, local agent provider settings, or what data may enter prompts/tool calls: ai-model-data-handling-guide, then security-model-guide.
 - Build a controlled agent worker directly on the CLI/MCP path (seat, steward, job, boundaries, tools, credentials, model, schedule, dry-run, go-live): agent-builder-guide \u2014 it shows the full setup sequence, the structured model config, the model catalog (model.catalog), the access tiers, how to discover tools (tool.catalog), which connector entries have live execution boundaries, and how to show your human a markdown readout (agent.show_markdown).
 - Connect an existing or local agent to a seat: stock-agents-guide (connect section), then mcp-and-cli-guide and runner-guide.
 - Run the operating loop as a seat (context, tasks, status, escalate): how-agents-work.
@@ -43176,10 +43482,10 @@ Read the listed guide before recommending or running each workflow. Every workfl
 - Company setup: rost-implementation-method, compass-authoring-guide, settings-guide, settings-members-and-invites-guide
 - Graph design: responsibility-graph-playbook
 - Charter design: charter-design-playbook, charter-authoring-deep-dive
-- Staffing: agent-staffing-playbook, add-agents-guide, custom-agents-guide, agent-builder-guide, how-agents-work, tool-access-and-vault, available-tools-guide, mcp-and-cli-guide, stock-agents-guide
+- Staffing: agent-staffing-playbook, add-agents-guide, custom-agents-guide, agent-builder-guide, how-agents-work, tool-access-and-vault, available-tools-guide, skill-builder-guide, agent-skill-authoring-guide, agent-skill-setup-guide, mcp-and-cli-guide, stock-agents-guide
 - Operating rhythm: cascade-guide, signal-guide, friction-guide, confirmations-guide, steward-queue-guide, sync-rhythm-playbook, notifications-guide
 - Local agents and runners: mcp-and-cli-guide, runner-guide, agent-reference-map
-- Security and troubleshooting: security-model-guide, troubleshooting-guide
+- Security and troubleshooting: ai-model-data-handling-guide, security-model-guide, troubleshooting-guide
 
 ## Agent behavior
 
@@ -43525,11 +43831,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.7",
+    version: "2026-06-21.2",
     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", "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", "settings.product_learning.get", "settings.product_learning.update"],
     legal: { publicRisk: "low", notes: ["{{brand}}-native settings guidance."] },
     sources: [
       {
@@ -43556,6 +43862,7 @@ Start with members and invites, then provider and channel connections, then MCP
 - Connected machines (the paired Runners that run scheduled local work orders).
 - Stored credentials (vault references only) and tool access approvals.
 - Operating defaults, including Sync Brief scope.
+- Product-learning participation for bounded product analytics.
 
 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.
 
@@ -43571,13 +43878,23 @@ Reconnects keep historical rows for audit, but provider status in Settings, CLI,
 
 The weekly Sync Brief compiles either company-wide or per cluster. Company-wide is one brief covering the whole company and is the default for a new company. Per cluster compiles one brief per cluster, scoped to each cluster's seats; pick it when clusters run their own weekly sync. Per cluster falls back to a single company-wide brief when the company has no clusters, so the rhythm never produces zero briefs. The owner sets this at onboarding and can change it later in Settings.
 
+## Product learning
+
+Product-learning participation controls whether {{brand}} may record product/page/recommendation analytics for this tenant. It does not disable security logs, audit logs, error logs, events, tool-call guard records, or other operational records required to run and secure the service.
+
+- \`enabled\` allows bounded product analytics for feature quality, defaults, templates, recommendations, safety checks, and reliability.
+- \`disabled\` blocks generic product/page/recommendation analytics for the tenant.
+- \`enterprise_contract\` blocks generic product-learning writes until contract-specific handling exists.
+
+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.
+
 ## Inference budget
 
 Agents that run on {{brand}}-managed inference draw against a tenant inference budget with a hard cap. A new company starts with a hard cap of $0, so a managed-inference run is blocked until the cap is raised. When a run hits the cap it stops with a typed budget error that names the fix; raise the cap before agents can run again.
 
 - Set the hard cap with \`settings.update\` (CLI: \`{{cli}} settings update --hard-cap-usd <amount>\`). The optional soft cap warns before the hard cap and must be less than or equal to it.
 - 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.
+- 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.
 
 ## Agent guidance
 
@@ -43894,15 +44211,200 @@ Most reads are safe to run while diagnosing. Any fix that changes authority, cre
 Name the failing surface, collect evidence, recommend the smallest correction, and escalate when the fix changes authority, credentials, or go-live state. Never paste secrets into chat or tool arguments while troubleshooting.`
   },
   {
-    slug: "security-model-guide",
+    slug: "ai-model-data-handling-guide",
     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",
+    public: true,
+    audiences: ["human", "cli", "mcp", "in_app_agent"],
+    stages: ["company_setup", "staffing", "operating_rhythm"],
+    relatedCommandIds: [
+      "tenant.anthropic_key.save",
+      "credential.ingress",
+      "agent.configure_tools",
+      "mcp_token.create",
+      "runner.pairing.start",
+      "agent.run_now",
+      "work_order.enqueue",
+      "tool.catalog"
+    ],
+    legal: {
+      publicRisk: "medium",
+      notes: [
+        "Provider policy summary must stay conservative and source-linked.",
+        "Does not claim zero-data-retention, HIPAA readiness, or model-training exclusions beyond provider account and contract scope."
+      ]
+    },
+    sources: [
+      {
+        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."
+      },
+      {
+        label: "OpenAI enterprise privacy",
+        url: "https://openai.com/enterprise-privacy/",
+        note: "Official enterprise privacy and API retention summary verified 2026-06-21."
+      },
+      {
+        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."
+      },
+      {
+        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."
+      },
+      {
+        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."
+      },
+      {
+        label: "Reference corpus and docs spec",
+        internalPath: "docs/specs/reference-corpus-and-docs.md",
+        note: "Defines the public reference guide set and agent retrieval surfaces."
+      }
+    ],
+    body: `# AI model data handling guide
+
+Use this guide when a human, CLI session, MCP client, or in-app agent needs to understand what data can reach an AI model, what {{brand}} controls, and what remains governed by the customer's provider account, local client, or connected tools.
+
+This is product guidance, not a legal warranty. Provider terms, enterprise contracts, data-processing addenda, retention controls, regional settings, and endpoint-specific behavior can change. Verify the provider account and contract before relying on a zero-data-retention, HIPAA, regional, or no-training posture.
+
+For {{brand}}'s own product-improvement posture, read the public Privacy Policy and Terms of Service at \`/privacy\` and \`/terms\`. They state that {{brand}} may analyze aggregated or de-identified data about usage, setup patterns, agent outcomes, and operating metrics to improve product features, defaults, templates, recommendations, safety checks, and reliability; they also state that {{brand}} does not sell customer data, share one customer's workspace data with another customer, or use identifiable customer content to train generalized AI models. Google user data and information derived from Google APIs stay under the Privacy Policy's Google user data limits and are not included in cross-customer product-improvement analytics. Do not turn this into a provider-side claim about a customer's local client, BYOK provider account, or third-party tool.
+
+## The three agent lanes
+
+{{brand}} names the execution lane on runs and work orders. Use these exact terms:
+
+| Lane | Where model-bound data is assembled | Who controls provider handling |
+|---|---|---|
+| \`cloud\` | The {{brand}} cloud runtime builds bounded prompt context from the Seat Charter, signed permission manifest, task or work order, relevant operating facts, selected Skill files, and tool results. | The current managed cloud path uses Anthropic-backed model configuration, either through {{brand}}'s platform-managed provider account or the tenant's approved BYOK Anthropic credential when that tenant has saved one. |
+| \`mcp_session\` | A local agent client such as Claude Code, Codex, OpenCode, Cursor, or another MCP-capable client asks {{brand}} for scoped context, resources, and command results. | The customer's local client, model provider account, proxy, and provider settings. {{brand}} does not control that local provider's retention, training, telemetry, or local transcript storage. |
+| \`runner\` | A paired runner claims work from {{brand}}, receives bounded work-order context, and may invoke a local or customer-controlled model client to complete the work. | The runner host, local client, and provider account used by that runner. {{brand}} controls the work-order boundary and audit path, not every downstream local model setting. |
+
+When answering "where did my data go?", name the lane first. Do not collapse \`cloud\`, \`mcp_session\`, and \`runner\` into one generic "agent" path.
+
+## Cloud agents
+
+For \`cloud\` runs, {{brand}} prepares the minimum context needed for the Seat to act:
+
+- Charter purpose, responsibilities, autonomous scope, approval scope, escalation rules, Signals, and signed permission manifest.
+- The task, work order, Sync/Friction/Signal context, or human instruction for that run.
+- Assigned Skill summaries and the bounded contents of selected approved Skill files.
+- Tool results that the server-side guard allowed and that are relevant to the next model turn.
+- Model catalog choices and run metadata needed to attribute cost and diagnostics.
+
+Cloud prompts should not include raw credentials, long exports, unrelated customer records, or secret values. A tool result can become model context, so keep tool scopes narrow and connect only the tools the Seat's Charter actually needs. The server-side guard decides whether a tool call is allowed, escalated, or denied; model output and Skill text never grant authority.
+
+## BYOK Anthropic
+
+Tenant BYOK changes which provider account is used for eligible \`cloud\` model calls. It does not loosen tool permissions, human gates, tenant isolation, or audit requirements.
+
+Store a tenant Anthropic key only through \`tenant.anthropic_key.save\` / \`rost_save_tenant_anthropic_key\` or the generic credential ingress path. The key is handled as a vault-backed credential: {{brand}} stores a vault reference and safe metadata, not the raw key in prompts, config, logs, or command output. A human approves the credential flow.
+
+After BYOK is saved, provider-side retention, training, regional, HIPAA, or zero-data-retention posture depends on that Anthropic organization, workspace, model, feature, and contract. Do not tell a customer "BYOK means zero retention" or "BYOK means no training" unless their provider arrangement actually says that.
+
+## Local MCP sessions
+
+In a \`mcp_session\`, {{brand}} is the governed operating-system surface. The local agent client is still its own model client.
+
+{{brand}} can enforce token scope, tenant isolation, command schemas, human confirmations, tool guards, and redacted command output. It cannot decide whether the local client stores transcripts, sends telemetry, opts into model improvement, uses a consumer account, uses a commercial account, routes through a proxy, or applies zero-data-retention settings. Those are local client and provider settings.
+
+{{brand}} command and resource outputs are returned to the local client. Seat context, Charter text, task and Signal facts, reference guide bodies, command JSON, and filtered tool results may become part of that client's provider request unless the operator narrows scope, redacts the input, or uses a provider setting that prevents it. Treat every MCP read as data that can enter the local model transcript.
+
+Before connecting a local agent to sensitive work, verify:
+
+- Which model provider and account the local client is using.
+- Whether the account is consumer, team, enterprise, API, or routed through another platform.
+- Whether model-improvement sharing, telemetry, transcript retention, and local logs are enabled.
+- Whether the client stores session files locally, and where those files live.
+- Whether screenshots, files, terminal output, browser data, or tool results can be included in the client transcript.
+
+For example, official Claude Code docs distinguish consumer and commercial handling, describe local plaintext session transcripts, and state that local clients send prompts and outputs to the configured provider. Official OpenAI API docs distinguish API data controls from consumer products, while official Codex help says ChatGPT training data controls apply to content processed through Codex when Codex is used with a ChatGPT plan. Treat each local agent's provider settings as part of the customer's environment review.
+
+## Runners
+
+A \`runner\` is paired to {{brand}} and claims work orders. {{brand}} records the work-order state, lane, Seat, run diagnostics, and audited tool-call outcomes. The runner host controls the local execution environment.
+
+Keep runner prompts bounded to the work order and Seat context. Do not paste runner bearer secrets, API keys, \`.env\` contents, SSH keys, OAuth tokens, database URLs, or private package credentials into prompts, tool args, screenshots, logs, or status updates. If a runner needs a credential, use the governed credential ingress and vault reference path or the customer's own secure local secret mechanism; do not turn the credential into model context.
+
+If a runner invokes Claude Code, Codex, OpenCode, Cursor, or another local model client, provider data handling follows that local client and account, not the {{brand}} cloud provider path.
+
+## Connected tools and tool results
+
+Connected tools are often the highest-risk data path because a valid tool result may be summarized into the next model turn.
+
+Use these rules:
+
+- Connect the narrowest tool scopes needed for the Seat's Charter.
+- Prefer filtered reads over full exports.
+- Keep credentials in vault refs and tool handlers; do not send raw secret values to the model.
+- Treat third-party tool data handling separately from model-provider data handling.
+- Escalate when a tool would expose regulated data, unusually broad customer records, confidential legal or HR material, or data outside the Seat's approved scope.
+
+Tool selection is never authorization. Every live tool call still passes the server-side guard and writes an audit record.
+
+## What not to put in prompts or tool args
+
+Do not intentionally put these into prompts, MCP tool arguments, runner work orders, Skill files, status updates, or screenshots unless the customer has a documented need and a matching provider/tool contract:
+
+- API keys, OAuth tokens, passwords, session cookies, SSH keys, signing keys, or recovery codes.
+- Raw \`.env\` files, private database URLs, credential vault payloads, or unredacted logs containing secrets.
+- Full customer exports when a filtered subset would answer the question.
+- Payment card data, PHI, government identifiers, or other regulated records without the required contract and workflow.
+- Private source URLs with embedded tokens or signed URLs.
+- Data from another tenant, workspace, account, or seat.
+
+If sensitive data appears by accident, stop, do not repeat it, and route cleanup through the customer's incident process.
+
+## 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 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 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."
+
+## Agent response checklist
+
+When asked about AI data handling:
+
+1. Identify the lane: \`cloud\`, \`mcp_session\`, or \`runner\`.
+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.`
+  },
+  {
+    slug: "security-model-guide",
+    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-20.1",
+    version: "2026-06-21.5",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing", "operating_rhythm"],
-    relatedCommandIds: ["mcp_token.create", "mcp_token.revoke", "charter.sign_manifest"],
+    relatedCommandIds: [
+      "mcp_token.create",
+      "mcp_token.revoke",
+      "charter.sign_manifest",
+      "credential.ingress",
+      "tenant.anthropic_key.save",
+      "runner.pairing.start",
+      "agent.configure_tools",
+      "agent.list_tool_calls",
+      "agent.get_run",
+      "integration.status",
+      "integration.readiness"
+    ],
     legal: { publicRisk: "low", notes: ["Public security model summary without internal implementation details."] },
     sources: [
       {
@@ -43928,12 +44430,97 @@ Name the failing surface, collect evidence, recommend the smallest correction, a
 - Tool calls are checked server-side and audited.
 - Agents recommend and draft; humans approve durable decisions.
 - Accepted knowledge changes by supersession, not silent mutation.
+- Skills are reusable procedures, not authority. They are versioned immutably, can declare tool dependencies, and are loaded only after assignment; they never grant tools or override the Charter.
+
+## What {{brand}} stores
+
+{{brand}} stores operating-system state for each tenant so humans and agents can run the company with an audit trail. The main stored categories are:
+
+- Company setup, onboarding state, members, roles, invites, and tenant settings.
+- Compass answers and versions, Responsibility Graph seats, occupancies, Steward links, Charters, signed permission manifests, goals, Signals, Frictions, tasks, decisions, Sync briefs, and events.
+- Agent setup state, model/run metadata, work orders, run diagnostics, transcript references, token and cost usage, Skill assignments, and immutable Skill activation records.
+- Tool-call audit rows: tool id, canonical guard result, safe argument summaries, outcome, evidence labels, escalation state, and error linkage.
+- Integration records, OAuth connection metadata, channel/binding metadata, notification preferences, notification delivery errors, and connector readiness/test results.
+- MCP token metadata, Runner metadata, runner-pairing state, and revocation state. Raw token material and runner bearer secrets are shown only at issuance when the flow requires it and are not retrievable from normal reads.
+- Credential records that contain vault references and safe metadata only. Raw API keys, OAuth refresh tokens, tenant Anthropic keys, Slack tokens, Google tokens, and REST connector secrets stay outside Postgres in the configured vault path.
+- Uploaded or generated documents and bounded extracted context when a user intentionally adds them to onboarding, Compass, Charter, or reference workflows.
+
+Do not store raw passwords, OAuth tokens, API keys, full \`.env\` files, session cookies, private signed URLs, or credential payloads in prompts, Skill files, command JSON, issue comments, logs, or reference docs. If a workflow needs a secret, route it through credential ingress and store a vault reference.
+
+## Access and isolation
+
+Every tenant-scoped product record is scoped by \`tenant_id\`, and database policies are written so one tenant cannot read another tenant's data through normal application access. Server-side tenant context comes from trusted server-side authority, not from client-supplied tenant ids: browser and CLI user sessions use authenticated Supabase claims plus membership, MCP sessions use the authenticated MCP token record, and runner sessions use the authenticated runner credential record.
+
+Human access is role-based through tenant membership:
+
+- Owners can administer tenant settings, integrations, members, MCP tokens, agent setup, and credential flows.
+- Stewards and members usually act through their seat occupancies and assigned responsibilities; some tenant-scoped setup, read, and credential workflows are also available to active tenant members when the command authorization layer allows them.
+
+Seat Steward accountability is separate from the tenant membership role named \`steward\`. A Seat Steward is the human accountability chain for an agent seat and receives escalations for that seat, but being named as a Seat Steward does not silently grant a model permission to act.
+
+Agent authority is seat-scoped even when the machine credential is broader. A seat-scoped MCP token can act only as the seat it was minted for. A paired runner authenticates as a tenant machine credential, claims tenant work orders, and receives seat-scoped work context plus a temporary seat-scoped MCP token for the claimed order; the runner bearer credential itself is not a single-seat credential. Tenant-admin MCP tokens are broader: they can reach workflows in the tenant-admin command surface, bounded by command authorization and guards. Reserve them for setup and administration, and prefer the narrowest scope that can do the job.
+
+Local clients such as Claude Code, Codex, OpenCode, and Cursor may receive command/resource output through MCP. {{brand}} enforces token scope, schemas, tenant isolation, and redaction on the output it returns; the local client and provider account control local transcript storage, telemetry, and model-provider handling. For that model-bound path, use the ai-model-data-handling-guide.
+
+## Credentials and integrations
+
+Credentials are never authority by themselves. A connected Slack, Google, REST, Anthropic, or future integration credential can be used only when all required checks pass:
+
+1. The actor is authorized for the tenant and command.
+2. The Seat Charter and signed permission manifest allow or escalate the tool.
+3. The tool handler exists and validates its input schema.
+4. The integration is connected for the tenant and has an active credential reference.
+5. Any extra binding exists, such as a Slack channel binding, REST host/method/path policy, or provider-specific setup requirement.
+6. Human confirmation is complete when the command or credential flow requires it.
+
+Tool selection is never authorization. A selected tool in setup records the requested permission; live execution still goes through the server-side guard, and the system is designed to write a tool-call audit row for every execution attempt. Standard agent audit reads do not return argument summaries or secret material.
+
+## Audit trail
+
+{{brand}} is designed to explain who or what changed operating state:
+
+- The event log is append-only. Corrections are new events, not edits to old events.
+- Decisions are human-decided records. Agents can draft or recommend, but durable decisions require a human.
+- Charters, Compass versions, and accepted knowledge change by supersession instead of silent overwrite.
+- Agent runs, work orders, tool calls, Skill activations, notification failures, and integration tests leave diagnostic records that can be inspected without exposing raw secrets.
+- Product-visible server/integration/runtime failures are recorded in \`error_logs\` when tenant context is available; pre-auth or tenant-less failures fall back to structured server logging.
+
+When reporting evidence to a human, summarize the relevant fields and include stable ids only when they help trace the record. Do not paste raw secrets, full provider responses, full prompt text, or broad exports into status updates.
+
+## Retention and support access boundaries
+
+{{brand}} keeps the records needed to operate, secure, troubleshoot, audit, and improve the product. This guide does not promise a fixed deletion schedule, zero retention, regional residency, HIPAA readiness, or staff-access workflow beyond what is explicitly stated in the customer contract, product settings, or public legal pages.
+
+Staff and support access should be treated as operationally sensitive. The current public posture is conservative: authorized personnel may access customer information when reasonably needed to operate, secure, or support the service; investigate abuse, reliability, or security issues; comply with law; or respond to a customer request. Google user data and information derived from Google APIs remain subject to the Privacy Policy's Google user data limits: humans may access that data only where the customer gives explicit permission for support, for security, to comply with law, or as required to operate the Google-connected features the customer uses. Do not claim that staff technically cannot access customer data in all circumstances unless that control is included in a separate written agreement and has been implemented for that account.
+
+When support access is needed, use the least data needed to diagnose the issue, prefer tenant-visible product evidence when available, redact secrets, and do not export broad customer datasets for routine support. Avoid asking customers to paste secrets, OAuth tokens, full provider responses, or raw mailbox/spreadsheet content into chat, tickets, issues, or docs. If a customer asks for deletion, retention, legal hold, DPA, BAA, regional processing, customer-visible staff access logs, break-glass approval, or staff-access commitments, escalate instead of improvising an answer.
+
+Retention language by category:
+
+- Workspace operating records such as graph, Charter, goal, Signal, Friction, task, Sync, run, event, and tool-call records are retained while the workspace is active so the product can show history, audit trails, and diagnostics.
+- Connected-service credentials are revoked when an integration is disconnected or the account is closed. Normal reads return credential metadata and vault references, not raw secret material.
+- Security, audit, event, diagnostic, and abuse-prevention records may be retained after an account or workspace deletion request is completed when needed for integrity, legal compliance, dispute resolution, or service protection.
+- Product-improvement analytics use only aggregated or de-identified data under the public Privacy Policy and Terms. Aggregated or de-identified derived metrics may be retained after account closure because they no longer identify a workspace.
+- Google user data and information derived from Google APIs stay under the Privacy Policy's Google user data limits and are not included in cross-customer product-improvement analytics.
+
+Deferred enterprise controls are not current promises: customer-visible staff access logs, formal break-glass approval, support-access approval workflows, customer-managed retention windows, full self-serve data export/deletion, regional data residency, DPA/BAA commitments, and HIPAA readiness require separate implementation or contract review before being promised.
 
 The public Privacy Policy and Terms of Service are available at \`/privacy\` and \`/terms\` before sign-in and from the authenticated app chrome.
 
+Those legal pages state that {{brand}} may analyze aggregated or de-identified data about usage, setup patterns, agent outcomes, and operating metrics to improve product features, defaults, templates, recommendations, safety checks, and reliability. They also state that {{brand}} does not sell customer data, does not share one customer's workspace data with another customer, and does not use identifiable customer content to train generalized AI models. Google user data and information derived from Google APIs stay under the Privacy Policy's Google user data limits and are not included in cross-customer product-improvement analytics. Keep those limits intact when explaining product improvement analytics, and escalate legal/security questions about contracts, deletion, regulated data, or customer-specific commitments.
+
+For model-bound data questions \u2014 including what \`cloud\`, \`mcp_session\`, or \`runner\` sends to an AI provider, what BYOK changes, and what local clients can store or transmit \u2014 read the ai-model-data-handling-guide before making a provider, retention, HIPAA, ZDR, or no-training claim.
+
+## Where to read next
+
+- Read the ai-model-data-handling-guide for model-provider, BYOK, local-client, MCP-session, and runner data paths.
+- Read the tool-access-and-vault guide for credential ingress, vault references, permission manifests, and tool execution boundaries.
+- Read the mcp-and-cli-guide for token scope, installation, rotation, and local-agent setup.
+- Read the runner-guide for runner pairing, local credential storage, bearer-token handling, and queue boundaries.
+
 ## Agent guidance
 
-Never infer permission from the user's wording or a locally available tool. Check the Charter, manifest, and server response. When in doubt, escalate with the evidence and the narrow question a human must decide.`
+Never infer permission from the user's wording, a local client configuration, a connected credential, a Skill, or a locally available tool. Check the tenant, role, seat occupancy, Charter, signed permission manifest, command schema, confirmation state, and server response. When in doubt, escalate with the evidence and the narrow question a human must decide.`
   },
   {
     slug: "migration-and-legal-notes",
@@ -45239,6 +45826,18 @@ function field(record2, key) {
   }
   return String(value);
 }
+function dryRunToolActionLabel(status) {
+  switch (status) {
+    case "intended":
+      return "Would run";
+    case "blocked":
+      return "Blocked";
+    case "escalated":
+      return "Escalated";
+    default:
+      return status;
+  }
+}
 function formatDryRunTranscript(value) {
   const transcript = asRecord(value);
   const steps = asArray(transcript.steps);
@@ -45251,7 +45850,11 @@ function formatDryRunTranscript(value) {
     const guard = record2.guard === null || record2.guard === void 0 ? "" : ` [${field(record2, "guard")}]`;
     return `  ${kind}: ${field(record2, "text")}${guard}`;
   });
-  return ["rehearsal:", ...lines].join("\n");
+  const toolPreview = asArray(transcript.tool_preview).map((action) => {
+    const record2 = asRecord(action);
+    return `  ${dryRunToolActionLabel(field(record2, "status"))}: ${field(record2, "intended_action")} [${field(record2, "tool_name")}]`;
+  });
+  return ["rehearsal:", ...lines, ...toolPreview.length > 0 ? ["tool preview:", ...toolPreview] : []].join("\n");
 }
 function markdownLine(output) {
   const markdown = asRecord(output).markdown;
@@ -45898,12 +46501,33 @@ function integrationUsage(bin) {
   ${bin} integration test --provider <name>`;
 }
 var settingsWrapper = (context, args) => dispatch(context, "settings", args, {
+  "product-learning": (ctx, rest) => dispatch(ctx, "settings product-learning", rest, {
+    get: (innerCtx, innerRest) => {
+      const parsed = parseFlags(innerRest);
+      return execute(innerCtx, parsed, "settings.product_learning.get", {}, (output) => {
+        const policy = asRecord(asRecord(output).product_learning);
+        return `product_learning ${field(policy, "mode")}  product_analytics_enabled=${field(policy, "product_analytics_enabled")}  security_audit_logs_enabled=${field(policy, "security_audit_logs_enabled")}`;
+      });
+    },
+    update: (innerCtx, innerRest) => {
+      const parsed = parseFlags(innerRest);
+      const mode = optionalValue(parsed, "mode");
+      if (mode !== "enabled" && mode !== "disabled" && mode !== "enterprise_contract") {
+        throw new UsageError("Provide --mode enabled|disabled|enterprise_contract.");
+      }
+      return execute(innerCtx, parsed, "settings.product_learning.update", { mode }, (output) => {
+        const policy = asRecord(asRecord(output).product_learning);
+        return `Updated product-learning policy to ${field(policy, "mode")} (product_analytics_enabled=${field(policy, "product_analytics_enabled")}).`;
+      });
+    }
+  }, settingsUsage(ctx.binName)),
   get: (ctx, rest) => {
     const parsed = parseFlags(rest);
     return execute(ctx, parsed, "settings.get", {}, (output) => {
       const record2 = asRecord(output);
       const spend = asRecord(record2.spend);
-      return `tenant ${field(record2, "tenant_id")}  plan=${field(record2, "plan")}  status=${field(record2, "status")}  spend=$${field(spend, "spend_usd")}  has_anthropic_key=${field(record2, "has_anthropic_key")}`;
+      const policy = asRecord(record2.product_learning);
+      return `tenant ${field(record2, "tenant_id")}  plan=${field(record2, "plan")}  status=${field(record2, "status")}  spend=$${field(spend, "spend_usd")}  has_anthropic_key=${field(record2, "has_anthropic_key")}  product_learning=${field(policy, "mode")}`;
     });
   },
   update: (ctx, rest) => {
@@ -45922,9 +46546,11 @@ var settingsWrapper = (context, args) => dispatch(context, "settings", args, {
   }
 }, settingsUsage(context.binName));
 function settingsUsage(bin) {
-  return `Usage: ${bin} settings get|update [--json]
+  return `Usage: ${bin} settings get|update|product-learning [--json]
   ${bin} settings get
-  ${bin} settings update [--soft-cap-usd <n>] [--hard-cap-usd <n>]`;
+  ${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`;
 }
 var memberWrapper = (context, args) => dispatch(context, "member", args, {
   invite: (ctx, rest) => {
@@ -46574,7 +47200,7 @@ function operationUsageLines(bin) {
     `${bin} sync brief|compile|complete`,
     `${bin} runner list|status|work-orders|revoke`,
     `${bin} notification settings|test|errors`,
-    `${bin} settings get|update`,
+    `${bin} settings get|update|product-learning`,
     `${bin} member invite|update|remove`,
     `${bin} agent templates|create|setup|tools|dry-run|go-live|status|run-now|fleet-digest|get-run|show`,
     `${bin} tools list`,