@rosthq/cli 0.5.9 → 0.5.10

package/dist/index.js

@@ -42084,7 +42084,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-19.6",
+    version: "2026-06-20.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -42173,14 +42173,14 @@ Before an agent goes live, the sandbox dry run rehearses this against fake data
 
 ## What humans should review
 
-Review the first dry runs, fleet overview, tool-call audit rows, escalations, and Signal impact. The fleet view at \`/agents\` shows every staffed agent seat at a glance; the agent-native equivalent is \`{{cli}} command agent.list_fleet --json '{}'\` / \`rost_list_agent_fleet\`, which returns lane, live state, last real turn, 24h/7d real turns, top measurable status, open escalations, and 7-day spend. 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, and Signal impact. The fleet view at \`/agents\` shows every staffed agent seat at a glance; the agent-native equivalent is \`{{cli}} command agent.list_fleet --json '{}'\` / \`rost_list_agent_fleet\`, which returns lane, live state, last real turn, 24h/7d real turns, top measurable status, open escalations, and 7-day spend. Fleet real-turn counts use the same seat-run association as \`agent.list_runs\`, filtered to real runs. Scheduled agents are checked in rounded five-minute buckets, so a minute-level cron inside the bucket queues one work order for that bucket rather than one order per minute. Sandbox dry runs do not count as real turns. If the agent is repeatedly blocked, revise the Charter or split the seat. If the agent is taking too much judgment, narrow its autonomous scope.`
   },
   {
     slug: "tool-access-and-vault",
     order: 46,
     title: "Tool access and vault",
     summary: "How to give agents access to tools without exposing raw credentials or expanding authority by accident.",
-    version: "2026-06-19.2",
+    version: "2026-06-20.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -42224,6 +42224,10 @@ Connecting a tool is a human-controlled step. The agent can recommend a tool, ex
 
 For an API with no dedicated connector, the generic REST tool lets a seat call an HTTP endpoint with a credential you paste through the vault \u2014 no {{brand}}-owned app. It is escalate-by-default: the agent may only call a host a steward has signed onto the allowlist; any other host is refused and escalated, with no request made. The connector sets the Authorization header from the vaulted credential itself \u2014 the agent never sees the token, and the secret is redacted from the response before it reaches the agent, the audit row, or the logs. The token is only ever sent over HTTPS, only to the signed host, and a redirect is never followed \u2014 so an allowlisted endpoint cannot bounce the call (and the token) to another host. A sandbox dry run of a REST tool makes no real request.
 
+## Slack post connector
+
+\`slack.post_message\` reuses the connected Slack workspace credential and the seat's Slack channel binding. A live call posts only to that bound channel, through the server-side guard and vault-bound bot token. If the bound channel is marked sensitive, the handler escalates for human approval instead of posting. A sandbox dry run makes no Slack request and does not open the vault.
+
 ## One write-only credential flow across every surface
 
 There is exactly one way to give a connected tool its credential, and it is the same on every surface (agent setup, Charter Builder, CLI, MCP). Connecting a tool only authorizes the access \u2014 it never captures a secret. When a connected tool needs a credential, you stage a vault-backed *request* (provider, scope, and a credential name \u2014 all labels, never the secret). You then provide the actual secret separately through the vault-backed ingress flow from Settings. No {{brand}} surface ever has a field that accepts raw secret material, so a secret can never reach a prompt, log, event, or tool argument.
@@ -42252,7 +42256,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-18.1",
+    version: "2026-06-20.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -42294,14 +42298,14 @@ Agents should explain the job, the required tool category, the minimum permissio
 
 Every tool call passes the server-side guard first: the guard checks the call against the seat's signed permission manifest and records a tool-call audit row for **every** call \u2014 allowed, denied, or escalated. Tool selection is never authorization. Only an allowed call reaches its handler. A connected credential is bound into the handler for the duration of the call only; the secret never appears in the result, the audit summary, logs, or the model's context.
 
-External connectors (such as email, drive, or a generic API) are being rolled out provider by provider, conservatively (read and draft before send; write behind approval). Until a provider's connector is live, a tool you select is configuration only and has no external side effect \u2014 the guard and audit trail are already in force, so nothing runs silently.`
+External connectors are being rolled out provider by provider, conservatively (read and draft before send; write behind approval). A selected tool is only a permission until a live handler exists and the seat has the required credential or binding. Today the built-in execution path supports internal status reporting, the generic REST connector when a signed allowlist and credential exist, and \`slack.post_message\` for a bound Slack channel. Other provider entries remain configuration-only until their connector ships, so nothing runs silently.`
   },
   {
     slug: "mcp-and-cli-guide",
     order: 48,
     title: "CLI and MCP installation guide",
     summary: "Install the public CLI, register remote token-backed MCP clients, and find the full command and tool catalog.",
-    version: "2026-06-19.4",
+    version: "2026-06-20.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -42716,7 +42720,7 @@ These ergonomic wrappers (including the \`{{cli}} agent\` group) require **{{cli
 | \`{{cli}} settings get|update\` | \`settings.get\`, \`settings.update\` | Read tenant settings; update budget caps. | Tenant | \`{{cli}} settings get --json\` |
 | \`{{cli}} member invite|update|remove\` | \`member.invite\`, \`member.update\`, \`member.remove\` | Manage tenant members. | Tenant | \`{{cli}} member invite --email ops@example.com --role member\` |
 | \`{{cli}} agent templates|create|setup|tools|dry-run|go-live|status|run-now|get-run|show\` | \`agent_template.list\`, \`agent.create_from_template\`, \`agent.create_custom\`, \`agent_setup.get\`, \`agent_setup.update\`, \`agent.configure_tools\`, \`agent.run_dry_run\`, \`agent.go_live\`, \`agent.status\`, \`agent.run_now\`, \`agent.get_run\`, \`agent.show_markdown\` | Run the full agent setup and operation flow: list templates, create a draft from a template or guided custom answers (with \`--model\` and \`--effort\`), read or answer setup state, connect or decline tools, dry-run, go live, run on demand, read one run's transcript/error diagnostics, and show a markdown readout. Create and go-live stop at human gates; the dry-run is ungated by human approval but requires a signed manifest first. | Tenant and seat | \`{{cli}} agent get-run --seat-id <seat-id> --run-id <run-id> --json\` |
-| \`{{cli}} tools list\` | \`tool.catalog\` | List the discoverable tool catalog the builder reads (id, scope tiers, credential requirement, access policy). Configuration only; the tools do not execute yet. | Tenant | \`{{cli}} tools list --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}} 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\` |
 
@@ -42738,7 +42742,7 @@ These ergonomic wrappers (including the \`{{cli}} agent\` group) require **{{cli
 This catalog is the canonical machine surface \u2014 the \`rost_*\` tools your MCP client calls. Three different things are called "tools" in {{brand}}; do not confuse them:
 
 1. **The MCP tools below** \u2014 the \`rost_*\` surface your client actually calls to read and act.
-2. **\`{{cli}} tools list\` / \`tool.catalog\`** (MCP \`rost_list_tool_catalog\`) \u2014 the agent-configuration catalog the builder reads when staffing an agent. It is selectable per agent and **does not execute yet**; it is not the surface you call to operate.
+2. **\`{{cli}} tools list\` / \`tool.catalog\`** (MCP \`rost_list_tool_catalog\`) \u2014 the agent-configuration catalog the builder reads when staffing an agent. It is selectable per agent, but selecting a tool is not itself a call; live handlers execute later only behind the signed manifest, guard, credentials, and bindings.
 3. **The "Available tools guide"** (in the sidebar) \u2014 covers tool *categories* and governance, not a callable surface. See the available-tools-guide.
 
 Sections below: Command discovery (2) \xB7 Public reference (3) \xB7 Tenant-admin tools (grouped by domain) \xB7 Seat-scoped operating tools (9) \xB7 MCP operation resources (9).
@@ -42812,7 +42816,7 @@ Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`
 | \`rost_get_current_compass\` | \`compass.get_current\` | Read the active and draft Compass versions and source documents. | Tenant | Call with \`{}\`. |
 | \`rost_list_compass_gaps\` | \`compass.list_gaps\` | List unanswered and answered Compass context gaps. | Tenant | Call with \`{}\` before answering gaps. |
 | \`rost_get_agent_status\` | \`agent.status\` | Read agent lane, live state, steward chain, dry-run result, Runner availability. | Seat or tenant-admin | Call with \`{"seat_id":"<seat-id>"}\`. |
-| \`rost_list_agent_fleet\` | \`agent.list_fleet\` | Read every staffed agent seat at once: lane, live state, last real turn, 24h/7d real turns, measurable status, escalations, and 7-day spend. | Tenant | Call with \`{}\`; sandbox dry runs are excluded from real turns. |
+| \`rost_list_agent_fleet\` | \`agent.list_fleet\` | Read every staffed agent seat at once: lane, live state, last real turn, 24h/7d real turns, measurable status, escalations, and 7-day spend. | Tenant | Call with \`{}\`; counts use the same seat-run association as \`agent.list_runs\`, with sandbox dry runs excluded from real turns. |
 | \`rost_run_agent_now\` | \`agent.run_now\` | Queue an immediate run for a live staffed agent without changing its saved schedule; cloud lane dispatches to the executor and runner lane queues for the paired runner. | Tenant | Call with \`{"seat_id":"<seat-id>"}\`. |
 | \`rost_list_agent_runs\` | \`agent.list_runs\` | Read a seat's agent run history (status, lane, model, cost, per-run tool-call and guard-held counts) plus the seat's run/tool-call rollup including held-action count. | Seat or tenant-admin | Call with \`{"seat_id":"<seat-id>"}\`; pass \`limit\` for a deeper window. |
 | \`rost_get_agent_run_diagnostics\` | \`agent.get_run\` | Read one run's diagnostic record: transcript reference, token/cost usage, outcome, and linked product-visible run errors. | Seat or tenant-admin | Call with \`{"seat_id":"<seat-id>","run_id":"<run-id>"}\`. |
@@ -42874,7 +42878,7 @@ Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`
 | \`rost_show_compass_as_markdown\` | \`compass.show_markdown\` | Render the current Compass and its open gaps as a clean markdown card for review. | Tenant | Call with \`{}\`. |
 | \`rost_show_charter_as_markdown\` | \`charter.show_markdown\` | Render a seat's active or latest Charter as a clean markdown card for review. | Tenant | Call with \`{"seat_id":"<seat-id>"}\`. |
 | \`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. Configuration only; the tools do not execute yet. | Tenant | Call with \`{}\` or \`{"provider":"google"}\`. |
+| \`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"}\`. |
 
 ### Seat-scoped operating tools
 
@@ -42932,7 +42936,7 @@ These rows are quick, at-a-glance triage. For deeper auth, tenant, scope, confir
     order: 49,
     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-18.1",
+    version: "2026-06-20.1",
     public: true,
     audiences: ["cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "graph_design", "charter_design", "staffing", "operating_rhythm"],
@@ -42982,7 +42986,7 @@ Never guess a command's JSON shape. Before calling a command that changes state,
 
 - List every callable command: {{cli}} command list (CLI) or rost_list_commands (MCP)
 - Read one command's exact input/output schema, help pointer, and a worked example: {{cli}} command schema <id> (CLI) or rost_describe_command with {"command_id":"<id>"} (MCP)
-- List the tool catalog the agent builder reads (id, scope tiers, credential requirement, access policy \u2014 configuration only; the tools do not execute yet): {{cli}} tools list (CLI) or rost_list_tool_catalog (MCP)
+- List the tool catalog the agent builder reads (id, scope tiers, credential requirement, access policy, and execution-boundary guidance): {{cli}} tools list (CLI) or rost_list_tool_catalog (MCP)
 - Show a Compass, Charter, or agent setup as a markdown card to review with your human: {{cli}} compass show --markdown, {{cli}} charter show --seat-id <id> --markdown, {{cli}} agent show --seat-id <id> --markdown
 
 When a command fails, the error returns a machine-readable code, a message, and a help field naming the exact command to run next. Read the help field and run the command it points at \u2014 do not retry the same call blindly. A failed precondition (for example a manifest not yet signed, a dry run that has not passed, or the inference budget hard cap reached) returns COMMAND_PRECONDITION_FAILED with a help pointer, not an opaque internal error.
@@ -43025,7 +43029,7 @@ 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.
-- 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 access tiers, and how to discover tools (tool.catalog) and show your human a markdown readout (agent.show_markdown). The tool catalog is configuration the builder reads; the tools do not execute yet.
+- 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 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.
 - Track goals: cascade-guide. Track measurables: signal-guide. File and resolve issues, tasks, escalations: friction-guide.
@@ -44063,7 +44067,7 @@ This worked document **omits** \`unanswered_boundaries\` and \`seat_type_recomme
     order: 43,
     title: "Agent builder guide",
     summary: "The full agent setup sequence on the CLI/MCP path \u2014 seat, steward, job, boundaries, tools, credentials, model, schedule, dry-run, go-live \u2014 with the structured model config and access tiers.",
-    version: "2026-06-16.1",
+    version: "2026-06-20.1",
     public: true,
     audiences: ["cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -44109,7 +44113,7 @@ Building teams of controlled agent workers is the product's core differentiator.
 2. **Steward** \u2014 every agent needs a human steward chain (invariant: no orphan agents). Set \`steward_seat_id\` so the chain resolves to a human; without it the occupancy is blocked.
 3. **Job** \u2014 what the seat owns. On \`agent.create_custom\` this is the operational answers (what it owns, what success looks like, what it must never do alone); for a strong contract, submit the full Charter directly via \`charter.update_draft\` (see the charter-authoring deep-dive).
 4. **Boundaries** \u2014 the Charter's \`decision_authority\` (can-do / must-ask / never / escalate), \`escalation_rules\`, and \`budget\`. Conservative by default: send/spend/irreversible actions are approval-gated or escalated.
-5. **Tools** \u2014 pick from the discoverable catalog (\`{{cli}} tools list\`); each tool has a default scope tier and access policy. Connect or decline via \`agent.configure_tools\`. **The catalog is configuration the builder reads \u2014 the tools do not execute yet** (real tool execution is a separate, deferred capability).
+5. **Tools** \u2014 pick from the discoverable catalog (\`{{cli}} tools list\`); each tool has a default scope tier and access policy. Connect or decline via \`agent.configure_tools\`. Selecting a tool records permission; live handlers execute later only behind the signed manifest, server guard, required credential or binding, and connector-specific approval boundary.
 6. **Credentials** \u2014 a tool that needs access declares a credential-ingress request (provider, scope, secret name). The secret itself flows through the vault-backed ingress command as a vault ref \u2014 never paste a secret into a builder command.
 7. **Operating instructions** \u2014 the runtime composes the agent's context from its Charter; you do not write a system prompt.
 8. **Model** \u2014 select the structured model config (see below).
@@ -45939,7 +45943,7 @@ ${lines.join("\n")}`;
 }, toolsUsage(context.binName));
 function toolsUsage(bin) {
   return `Usage: ${bin} tools list [--provider <name>] [--json]
-  ${bin} tools list \u2014 the discoverable tool catalog the builder reads. Configuration only; the tools do not execute yet.`;
+  ${bin} tools list \u2014 the discoverable tool catalog the builder reads; live handlers execute only behind signed manifests, guards, credentials, and bindings.`;
 }
 var compassWrapper = (context, args) => dispatch(context, "compass", args, {
   show: (ctx, rest) => {