@rosthq/cli 0.5.6 → 0.5.8

package/dist/index.js

@@ -27867,6 +27867,11 @@ var marketingUrl = process.env.NEXT_PUBLIC_MARKETING_URL ?? "";
 var BRAND = {
   name: "ROST",
   legalName: "ROST, Inc.",
+  // The legal entity that operates the product and publishes the privacy policy
+  // / terms (the data controller). Distinct from the product brand name — the
+  // operating company is not subject to brand/trademark renaming. Set via env
+  // (e.g. "SKBD LLC"); falls back to the product legal name when unset.
+  operatingEntity: process.env.NEXT_PUBLIC_LEGAL_ENTITY?.trim() || "ROST, Inc.",
   tagline: "Mission control for humans and AI.",
   categoryDescriptor: "The agentic operating system for hybrid companies.",
   domain: domainFromUrl(marketingUrl),
@@ -41486,7 +41491,7 @@ var referenceDocuments = [
     order: 10,
     title: "{{brand}} implementation method",
     summary: "The staged operating-system setup path used by humans, CLI sessions, MCP clients, and in-app agents.",
-    version: "2026-06-16.1",
+    version: "2026-06-18.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "graph_design", "charter_design", "staffing", "operating_rhythm"],
@@ -41554,6 +41559,10 @@ Build the Responsibility Graph from functions and seats first. Do not start by a
 
 The first graph should be small enough to understand. Start with the top operating seat, then major functions, then the first operational seats that carry measurable work. Add detail only when it clarifies ownership.
 
+### Solo founders and small flat teams
+
+If it is just you, or a small flat team of four or fewer people, declare that at the start of org intake. Setup skips the org-chart upload and the "who reports to you" question, and instead asks which functions the company needs covered today. It proposes a standard small-company function tree \u2014 company leadership, revenue, sales, marketing, delivery and operations, finance and admin \u2014 that you occupy, then pivots straight to which functions to staff with agents. Because there is no one to invite, the team-invite step is skipped. You can still invite people later from settings.
+
 ## Stage 3: Convert seats into Charters
 
 A Charter is the executable job description for a seat. It should define purpose, responsibilities, autonomous scope, approval scope, must-escalate conditions, measurables, and tool permissions.
@@ -41584,14 +41593,14 @@ The Compass is drafted, then activated by a human through supersession.
 
 ## When to stop for confirmation
 
-\`onboarding.advance_step\`, \`onboarding.finish\`, \`onboarding.create_invite\`, \`compass.approve_version\`, \`compass.reject_draft\`, \`compass.answer_gap\`, and \`compass.set\` are \`human_required\`. Attaching a reference document (\`onboarding.attach_reference\`) and drafting a Compass are safe for an agent; approving a version (a supersession) is a human act. The agent drafts and surfaces the approve link. See the confirmations guide.`
+\`onboarding.finish\`, \`compass.approve_version\`, \`compass.reject_draft\`, and \`compass.set\` are \`human_required\`. \`onboarding.advance_step\`, \`onboarding.create_invite\`, \`onboarding.attach_reference\`, \`compass.answer_gap\`, and drafting a Compass are \`none\` \u2014 none of them returns a pending confirmation. \`none\` is not the same as "agent-callable", though: \`onboarding.create_invite\` and \`compass.answer_gap\` record the human who ran them, so they run as a person, not from an agent session, while advancing a step, attaching a reference, and drafting a Compass are safe for an agent. Approving a version (a supersession) is a human act. The agent drafts and surfaces the approve link. See the confirmations guide.`
   },
   {
     slug: "responsibility-graph-playbook",
     order: 20,
     title: "Responsibility Graph playbook",
     summary: "How to build a functions-first graph with seats, owners, Stewards, vacancies, and clean authority.",
-    version: "2026-06-17.1",
+    version: "2026-06-18.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["graph_design", "staffing"],
@@ -41638,6 +41647,13 @@ Each entry opens the same conservative setup flow \u2014 seat placement, Steward
 
 The graph canvas fits the whole structure into the frame when it opens and refits whenever the frame changes \u2014 opening a side panel, resizing the window, or rotating a phone. Zoom moves between three altitudes: a constellation of seat dots when zoomed out, seat cards at the working zoom, and charter detail when zoomed in. Seat cards stay legible on small screens, and the canvas is the one always-dark surface in the otherwise light app. Search the toolbar to fly to any seat by name.
 
+The graph is also where you land after onboarding \u2014 it is the mission control for the company, not a separate dashboard. Switch lenses from the toolbar to recolour the same structure four ways:
+
+- **Structure** \u2014 seat type and reporting lines.
+- **Cascade** \u2014 whether each seat's goal branch is on track.
+- **Signal** \u2014 the worst measurable state per seat.
+- **Scoreboard** \u2014 two live numbers on every seat: work done (agent runs) and cost over the last 30 days. A seat whose cost is a clear outlier above the rest of the fleet is flagged as cost drift (labelled, not colour-only). Human seats and seats with no runs read calmly as no agent cost rather than a bare zero. For a small fleet the Scoreboard also leads with a two-tile summary \u2014 total work and total cost \u2014 framed as the single question that matters: is it earning its keep.
+
 ## First-pass structure
 
 Start with the operating root, then major functions, then the few seats that own the most important recurring work. Do not over-model. A graph with eight clear seats is better than a graph with thirty vague boxes.
@@ -41688,7 +41704,7 @@ It ends every occupancy, archives the seat's active Charter, revokes the seat's
 
 ## When to stop for confirmation
 
-\`seat.create\`, \`seat.rename\`, \`seat.reparent\`, \`seat.set_type\`, and \`seat.decommission\` are \`human_required\`. Over MCP they return a pending confirmation with an approve link instead of mutating; the human approves with \`confirmation.approve\`. Never approve your own structural change from an agent session \u2014 surface the pending confirmation to a human. When a seat-targeted command does execute, its audit row is scoped to that seat (queryable by \`seat_id\`); on the deferred MCP path the executed audit is recorded against the human's \`confirmation.approve\`. See the confirmations guide.
+\`seat.reparent\`, \`seat.set_type\`, and \`seat.decommission\` are \`human_required\`; \`seat.create\` and \`seat.rename\` are \`none\`, so an agent can add and rename seats directly. The structural commands return a pending confirmation with an approve link over MCP instead of mutating; the human approves with \`confirmation.approve\`. Never approve your own structural change from an agent session \u2014 surface the pending confirmation to a human. When a seat-targeted command does execute, its audit row is scoped to that seat (queryable by \`seat_id\`); on the deferred MCP path the executed audit is recorded against the human's \`confirmation.approve\`. See the confirmations guide.
 
 ## Agent guidance
 
@@ -41769,11 +41785,11 @@ Drafting can be assisted by agents. Activation is a human decision. When authori
     order: 40,
     title: "Agent staffing playbook",
     summary: "How to decide whether a seat should be human, agent, or hybrid, and how to go live safely.",
-    version: "2026-06-13.1",
+    version: "2026-06-19.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
-    relatedCommandIds: ["staffing.assign_user", "staffing.assign_agent_dry_run", "agent.go_live", "agent.status", "mcp_token.create", "agent_template.list", "agent.create_from_template", "agent_setup.start", "agent_setup.get", "agent_setup.update", "agent.update_schedule", "agent.decommission", "agent.create_custom", "agent.configure_tools", "agent.run_dry_run", "confirmation.approve"],
+    relatedCommandIds: ["staffing.assign_user", "staffing.assign_agent_dry_run", "agent.go_live", "agent.status", "agent.run_now", "agent.list_runs", "agent.list_tool_calls", "mcp_token.create", "agent_template.list", "agent.create_from_template", "agent_setup.start", "agent_setup.get", "agent_setup.update", "agent.update_schedule", "agent.decommission", "agent.create_custom", "agent.configure_tools", "agent.run_dry_run", "confirmation.approve"],
     legal: {
       publicRisk: "low",
       notes: [
@@ -41814,6 +41830,12 @@ A seat can be human, agent, or hybrid. The staffing decision should follow the w
 5. Review Signal, Friction, and tool-call audit rows.
 6. Human approves go-live.
 
+## In the onboarding funnel
+
+Staffing your first agent is a step in onboarding, right before the finish step. Its content is the stock-template gallery: pick a template to staff an agent seat, and you continue on the agents surface to name the Steward, sign the manifest, and run the sandbox dry run \u2014 the same draft-first path described below, not a separate one. Staffing the first agent is the activation moment, so the funnel asks for it before exit.
+
+Working solo, or staffing later? Skip the step with intent and finish onboarding without an agent. Nothing is forced: you can staff an agent any time from the agents surface, and the staffing decision still follows the work, the risk, and the measurable.
+
 ## Create and stage an agent from CLI or MCP
 
 Two creation paths, both draft-first. Read the stock-agents guide for templates and the how-agents-work guide for the operating loop.
@@ -41821,10 +41843,12 @@ Two creation paths, both draft-first. Read the stock-agents guide for templates
 - From a template: list with \`agent_template.list\` / \`rost_list_agent_templates\`, then \`agent.create_from_template\` / \`rost_create_agent_from_template\` with \`seat_id\` and \`template_slug\`. Returns a draft agent and draft Charter only.
 - Custom: \`agent_setup.start\` / \`rost_start_agent_setup\` (returns a \`setup_id\`), iterate with \`agent_setup.get\` and \`agent_setup.update\`, then \`agent.create_custom\` / \`rost_create_custom_agent\`. Stage tools with \`agent.configure_tools\` (vault refs only) and sandbox with \`agent.run_dry_run\`.
 - Inspect runtime: \`agent.status\` / \`rost_get_agent_status\` with \`{"seat_id":"<seat-id>"}\` returns lane, live state, steward chain, dry-run result, and Runner availability.
+- Run on demand: \`{{cli}} agent run-now --seat-id <seat-id>\` / \`agent.run_now\` / \`rost_run_agent_now\` queues an immediate live run without changing the saved schedule. Cloud agents dispatch to the Inngest executor; runner agents queue work for the paired runner. The command is ungated but still requires a live staffed agent and the normal server-side tool guard.
+- Audit what an agent did (Trust Card): \`{{cli}} command agent.list_runs --json '{"seat_id":"<seat-id>"}'\` / \`rost_list_agent_runs\` returns the seat's run history with per-run tool-call and guard-held counts; \`{{cli}} command agent.list_tool_calls --json '{"seat_id":"<seat-id>"}'\` / \`rost_list_agent_tool_calls\` returns the tool-call ledger with each call's guard result. Both include a \`denied_tool_call_count\` rollup \u2014 the actions held because they exceeded the charter. Pass \`{"seat_id":"<seat-id>","held_only":true}\` to \`agent.list_tool_calls\` for only the held calls. The web seat page shows the same facts as a Trust Card.
 
 ## When to stop for confirmation
 
-\`agent.create_from_template\`, \`agent.create_custom\`, \`agent.configure_tools\`, \`staffing.assign_user\`, \`agent.go_live\`, \`agent.update_schedule\`, and \`agent.decommission\` are \`human_required\`; \`mcp_token.create\` and \`credential.ingress\` are \`dangerous\`. An agent may draft, configure (with vault refs), and dry-run; the human approves go-live, credentials, schedule changes, and decommission. \`run_dry_run\` is ungated by human approval, but it is **precondition-gated**: the seat's permission manifest must be signed first (\`charter.sign_manifest\`). Attempting a dry run before sign-off returns a clean \`COMMAND_PRECONDITION_FAILED\` naming \`charter.sign_manifest\`, not a generic failure. Go-live after a passed dry run is \`human_required\`. See the confirmations guide.
+\`agent.create_from_template\`, \`agent.create_custom\`, \`staffing.assign_user\`, \`agent.go_live\`, \`agent.update_schedule\`, and \`mcp_token.create\` are \`human_required\`; \`agent.configure_tools\` and \`credential.ingress\` are \`credential_flow\` (both gate through the vault-backed credential path with human approval; \`agent.configure_tools\` stages the request and only \`credential.ingress\` takes the raw secret, as a vault reference); \`agent.decommission\` is \`dangerous\`. \`agent.run_now\` is not human-gated because it does not expand authority or change the schedule; it only queues an immediate run for an already-live agent. An agent may draft, configure (with vault refs), dry-run, and request an on-demand run; the human approves go-live, credentials, schedule changes, and decommission. \`run_dry_run\` is ungated by human approval, but it is **precondition-gated**: the seat's permission manifest must be signed first (\`charter.sign_manifest\`). Attempting a dry run before sign-off returns a clean \`COMMAND_PRECONDITION_FAILED\` naming \`charter.sign_manifest\`, not a generic failure. Go-live after a passed dry run is \`human_required\`. See the confirmations guide.
 
 ## Non-negotiables
 
@@ -41835,7 +41859,7 @@ 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-15.2",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["human", "in_app_agent"],
     stages: ["staffing"],
@@ -41908,14 +41932,14 @@ 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 is disabled or routes to sign-up rather than attempting a change.`
+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.`
   },
   {
     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-17.1",
+    version: "2026-06-18.4",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "charter_design"],
@@ -41945,15 +41969,23 @@ Begin from the agents surface (**Design a custom agent**) or from the CLI/MCP. T
 
 From your answers, the Charter Builder drafts responsibilities, decision authority, Signals, handoffs, and escalation rules. Review and edit every clause. Keep the autonomous scope tight at first; you can grant more authority later once dry runs and evidence justify it.
 
-## Choose a lane
+## Choose a lane and a trigger
+
+Pick where the agent runs and what starts it. Both lead with a safe default, so a non-technical operator never has to write a raw schedule or reason about an internal lane name.
 
 A custom agent runs on one of three lanes:
 
-- **Cloud agent** \u2014 the {{brand}}-managed runtime using the tenant model key.
+- **Cloud agent** (recommended) \u2014 the {{brand}}-managed runtime using the tenant model key. It needs no local machine, pairing, or token, so it is the default if you are unsure.
 - **External MCP agent** \u2014 a Claude Code, Codex, or Cursor agent that connects to {{brand}} as the seat.
 - **Local Runner** \u2014 scheduled local execution through a paired Runner.
 
-Lane and schedule stay advanced unless the work needs them.
+Then choose one of three named triggers:
+
+- **On demand** (default) \u2014 runs only when you or a teammate start it. No schedule.
+- **Scheduled** \u2014 runs on a recurring cadence you pick (every weekday morning, every morning, weekly, hourly). No cron to write.
+- **Event** \u2014 runs in response to work routed to it, like a sync or a mention, rather than on a clock.
+
+Open **Advanced** for the explicit lane select and a raw cron expression when you need a custom cadence. The same schedule presets appear on the agent's seat page after go-live (Agent operations \u2192 Run schedule).
 
 ## Configure tools and credentials
 
@@ -41971,18 +42003,18 @@ The same path is command-backed:
 
 ## Dry run and go-live
 
-The agent rehearses a representative task in a sandbox and is expected to escalate where the Charter requires it. A failed dry run keeps the draft and shows the reason so you can edit and rerun. When the dry run passes, a human promotes the agent live. The dry run rehearses the specific model tier you chose, so once it passes the model is locked \u2014 changing the model requires re-running the dry run on the new model before go-live.
+The dry run is a real sandbox rehearsal, not a stamp. It executes a mock-provider run derived from the Charter \u2014 the agent works against sandbox data only and is expected to escalate where the Charter's must-escalate clause requires it. The same rehearsal works on all three lanes: cloud, external MCP, and local Runner. External MCP dry runs require an active seat-scoped MCP token; Runner dry runs require a paired Runner. Missing substrate returns a typed precondition error, not a generic failure. The recorded run keeps the agent's actual lane, so the evidence you review matches the lane you selected. The result is earned: a run that escalates the must-escalate boundary passes; a run that acts on that boundary instead of escalating fails. A failed dry run keeps the draft and shows the reason so you can edit and rerun. The rehearsal returns a transcript \u2014 the steps the agent took and the escalation it raised \u2014 shown step by step in the builder and printed by the CLI, so you can see the governance model working before anything goes live. When the dry run passes, a human promotes the agent live. The dry run rehearses the specific model tier you chose, so once it passes the model is locked \u2014 changing the model requires re-running the dry run on the new model before go-live.
 
 ## When to stop for confirmation
 
-\`agent.create_custom\`, \`agent.configure_tools\`, \`charter.sign_manifest\`, \`staffing.assign_user\`, and \`agent.go_live\` are \`human_required\`; \`credential.ingress\` is \`dangerous\`. \`agent.run_dry_run\` is ungated by human approval but **requires a signed manifest first** \u2014 a dry run before \`charter.sign_manifest\` returns a clean \`COMMAND_PRECONDITION_FAILED\` pointing at \`charter.sign_manifest\`. The go-live after a passed dry run is \`human_required\`. An agent may draft, configure (with vault refs), and dry-run; only a human approves the Charter, manifest, credentials, and go-live. A seat token can never create or approve its own setup. See the confirmations guide.`
+\`agent.create_custom\`, \`charter.sign_manifest\`, \`staffing.assign_user\`, and \`agent.go_live\` are \`human_required\`; \`agent.configure_tools\` and \`credential.ingress\` are \`credential_flow\` (both gate through the vault-backed credential path with human approval; \`agent.configure_tools\` stages the request and only \`credential.ingress\` takes the raw secret, as a vault reference). \`agent.run_dry_run\` is ungated by human approval but **requires a signed manifest first** \u2014 a dry run before \`charter.sign_manifest\` returns a clean \`COMMAND_PRECONDITION_FAILED\` pointing at \`charter.sign_manifest\`. The go-live after a passed dry run is \`human_required\`. An agent may draft, configure (with vault refs), and dry-run; only a human approves the Charter, manifest, credentials, and go-live. A seat token can never create or approve its own setup. See the confirmations guide.`
   },
   {
     slug: "sync-rhythm-playbook",
     order: 80,
     title: "Sync rhythm playbook",
     summary: "How Signal, Friction, Cascade, and Sync Briefs turn weekly meetings into decision time.",
-    version: "2026-06-17.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -42041,7 +42073,7 @@ Start with the exceptions, not a tour of every seat. Resolve the highest-value F
 
 ## When to stop for confirmation
 
-\`sync.run.start\`, \`sync.run.complete\`, and \`sync.item.assign\` are \`human_required\`; \`sync.brief.compile\` and \`sync.brief.get\` are not gated. Compiling the brief is safe for an agent to do before the meeting; starting, completing, and assigning follow-ups are human acts. An agent prepares the brief and proposed assignments and stops.
+\`sync.brief.compile\`, \`sync.brief.get\`, \`sync.run.start\`, \`sync.run.complete\`, and \`sync.item.assign\` are all \`none\`, so a tenant-admin seat runs the weekly rhythm directly without a per-action human gate. An agent can compile the brief and propose assignments ahead of the meeting; the human still owns the meeting and the decisions made in it, but {{brand}} does not force a confirmation on these commands themselves.
 
 ## After Sync
 
@@ -42052,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-13.1",
+    version: "2026-06-19.4",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -42060,6 +42092,7 @@ Decisions should be recorded as human decisions. Handoffs should attach to seats
       "staffing.assign_agent_dry_run",
       "agent.go_live",
       "agent.status",
+      "agent.list_fleet",
       "agent_setup.get",
       "agent_setup.update",
       "agent.decommission",
@@ -42123,18 +42156,29 @@ A seat-scoped MCP token or the CLI runs the hand-shaped protocol. The server sti
 
 A seat-scoped MCP token already carries the seat, so its tools (\`rost_get_tasks\`, \u2026) need no seat argument. A tenant or owner CLI **session** does not, so pass \`--seat <seat-id>\` on seat-operating wrappers (an owner can target any seat in the tenant; a member only a seat they occupy). See "Seat scope" below.
 
-\`task.accept\`, \`task.decline\`, and \`task.complete\` are \`human_required\` for the acting human on the seat; \`status.record\`, \`work.log\`, and \`escalation.raise\` are not gated. An agent never approves a confirmation on behalf of a human.
+\`task.accept\`, \`task.decline\`, \`task.complete\`, \`status.record\`, \`work.log\`, and \`escalation.raise\` are all \`none\` \u2014 a seat operates its own queue and reports its own work directly. None of these carry a confirmation gate. An agent still never approves a human's confirmation on another seat's behalf; these are simply the acting seat's own reversible actions.
+
+## How a tool call is executed
+
+The model is only ever offered the tools the seat's manifest grants \u2014 a denied tool is never even shown to it \u2014 and each tool carries its real input schema, so the model knows exactly what shape an action takes. Some model runtimes see SDK-safe aliases such as \`rost_report_status\`; the server maps those back to the canonical manifest name such as \`rost.report_status\` before guard checks, handler execution, and audit. Tool outcomes return to the model as structured tool-result blocks tied to the provider tool-use id, so retries and transcripts stay reconstructible. When the model proposes a tool call:
+
+1. The manifest guard runs first and decides: allowed, denied, or must-escalate. A denied or must-escalate call never runs the action; an escalation is raised for a human.
+2. For an allowed call, the proposed input is validated against the tool's schema. Malformed input fails closed \u2014 the action does not run, and the model is told to correct it.
+3. The action runs bound to the seat's vaulted credential. The secret stays inside the call and never reaches the result, the audit row, the logs, or the model.
+4. Every call \u2014 allowed, denied, escalated, or invalid \u2014 writes a tool-call audit row you can review.
+
+Before an agent goes live, the sandbox dry run rehearses this against fake data and returns a per-tool preview: for each tool the agent would touch, whether it would run it, would be blocked, or would escalate \u2014 no external side effect. Review that preview before you approve go-live.
 
 ## What humans should review
 
-Review the first dry runs, tool-call audit rows, escalations, and Signal impact. 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. 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-13.1",
+    version: "2026-06-19.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -42174,6 +42218,14 @@ Tool access belongs to the seat, not to a person or a chat session. A tool shoul
 
 Connecting a tool is a human-controlled step. The agent can recommend a tool, explain why it is useful, and draft the manifest. A human approves the tool connection and any credentials.
 
+## Generic REST connector
+
+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.
+
+## 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.
+
 ## What to check before connecting a tool
 
 - The seat has an active or ready-to-approve Charter.
@@ -42185,20 +42237,20 @@ Connecting a tool is a human-controlled step. The agent can recommend a tool, ex
 ## Connect tools and credentials from CLI or MCP
 
 - Stage tools on a draft agent: \`agent.configure_tools\` / \`rost_configure_agent_tools\` \u2014 connect or decline proposed tools and stage credential-ingress requests. Pass vault references, never raw secret material.
-- Store a secret: \`credential.ingress\` / \`rost_store_credential\` (scope: seat) persists only a vault reference. This command is \`dangerous\` \u2014 it returns a pending confirmation and runs only with a real human-provided secret.
+- Store a secret: \`credential.ingress\` / \`rost_store_credential\` (scope: seat) persists only a vault reference. \`credential.ingress\` is \`credential_flow\` \u2014 it returns a pending confirmation and runs only with a real human-provided secret, captured as a vault reference. (Because it redacts that secret, the pending confirmation also shows a high-risk badge \u2014 see the confirmations guide for badge-versus-level.)
 - Sign the manifest: \`charter.sign_manifest\` / \`rost_sign_charter_manifest\` requests human confirmation for the seat's permission manifest.
-- Mint local access: prefer \`{{cli}} mcp install\` for users; \`mcp_token.create\` is \`dangerous\` and returns the token once. List metadata with \`mcp_token.list\` (never token material); revoke with \`mcp_token.revoke\`.
+- Mint local access: prefer \`{{cli}} mcp install\` for users; \`mcp_token.create\` is \`human_required\` and returns the token once. List metadata with \`mcp_token.list\` (never token material); revoke with \`mcp_token.revoke\`.
 
 ## When to stop for confirmation
 
-\`credential.ingress\` and \`mcp_token.create\` are \`dangerous\`; \`charter.sign_manifest\`, \`agent.configure_tools\`, and \`mcp_token.revoke\` are \`human_required\`. Connecting a tool, storing a credential, or minting a token is a human-approved act. An agent drafts and explains; a human approves through the confirmation flow. Secrets never appear in prompts, logs, tool arguments, or an \`args_summary\`. See the confirmations guide.`
+\`credential.ingress\` and \`agent.configure_tools\` are \`credential_flow\`; \`charter.sign_manifest\`, \`mcp_token.create\`, and \`mcp_token.revoke\` are \`human_required\`. Connecting a tool, storing a credential, or minting a token is a human-approved act. An agent drafts and explains; a human approves through the confirmation flow. Secrets never appear in prompts, logs, tool arguments, or an \`args_summary\`. See the confirmations guide.`
   },
   {
     slug: "available-tools-guide",
     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-13.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -42234,14 +42286,20 @@ Start from the seat's responsibility, not the tool list. If a tool does not dire
 
 ## How agents should request tools
 
-Agents should explain the job, the required tool category, the minimum permission needed, and the escalation boundary. Humans approve or decline the request.`
+Agents should explain the job, the required tool category, the minimum permission needed, and the escalation boundary. Humans approve or decline the request.
+
+## How a tool actually runs
+
+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.`
   },
   {
     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-18.8",
+    version: "2026-06-19.3",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -42275,7 +42333,10 @@ Agents should explain the job, the required tool category, the minimum permissio
       "agent.configure_tools",
       "agent.run_dry_run",
       "agent.go_live",
-      "agent.status"
+      "agent.status",
+      "agent.list_fleet",
+      "agent.list_runs",
+      "agent.list_tool_calls"
     ],
     legal: {
       publicRisk: "low",
@@ -42651,7 +42712,7 @@ These ergonomic wrappers (including the \`{{cli}} agent\` group) require **{{cli
 | \`{{cli}} notification settings|test\` | \`notification.settings.get\`, \`notification.test\` | Read notification settings; send a test. | Tenant | \`{{cli}} notification settings --json\` |
 | \`{{cli}} settings get|update\` | \`settings.get\`, \`settings.update\` | Read tenant settings; update budget caps. | Tenant | \`{{cli}} settings get --json\` |
 | \`{{cli}} member invite|update|remove\` | \`member.invite\`, \`member.update\`, \`member.remove\` | Manage tenant members. | Tenant | \`{{cli}} member invite --email ops@example.com --role member\` |
-| \`{{cli}} agent templates|create|setup|tools|dry-run|go-live|status|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.show_markdown\` | Run the full agent setup 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, 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 templates --json\` |
+| \`{{cli}} agent templates|create|setup|tools|dry-run|go-live|status|run-now|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.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, 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 templates --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}} 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\` |
@@ -42748,6 +42809,10 @@ 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_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_list_agent_tool_calls\` | \`agent.list_tool_calls\` | Read a seat's tool-call ledger (tool name, guard result, manifest clause, outcome) with the held-action count as the hero metric. Never returns argument summaries or secret material. | Seat or tenant-admin | Call with \`{"seat_id":"<seat-id>"}\`; pass \`held_only: true\` for only guard-held calls. |
 | \`rost_list_agent_templates\` | \`agent_template.list\` | List stock agent templates and metadata. | Tenant | Call with \`{}\`. |
 | \`rost_create_agent_from_template\` | \`agent.create_from_template\` | Create a draft stock agent and draft Charter from a template (draft-only; occupancy needs a human steward). | Tenant | Call with \`seat_id\` and \`template_slug\`; expect human confirmation. |
 | \`rost_start_agent_setup\` | \`agent_setup.start\` | Start an agent setup draft for template, custom, or existing mode. | Tenant | Call with \`mode\` and seat placement. |
@@ -42755,6 +42820,8 @@ Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`
 | \`rost_update_agent_setup\` | \`agent_setup.update\` | Update parent, steward, lane, schedule, or answers on a setup draft. | Tenant | Call with \`setup_id\` and the fields to change. |
 | \`rost_update_agent_schedule\` | \`agent.update_schedule\` | Update a draft or live agent's scheduled execution. | Tenant | Call with \`agent_id\` and \`schedule_cron\`; expect human confirmation. |
 | \`rost_decommission_agent\` | \`agent.decommission\` | Retire an agent occupancy safely (no-orphan guarded). | Tenant | Call with \`agent_id\`; expect human confirmation. |
+| \`rost_pause_agent\` | \`agent.pause\` | Pause a live agent so it stops scheduled and on-demand runs; reversible. | Tenant | Call with \`seat_id\`; expect human confirmation. |
+| \`rost_resume_agent\` | \`agent.resume\` | Resume a paused agent back to live (no-orphan guarded). | Tenant | Call with \`seat_id\`; expect human confirmation. |
 | \`rost_create_custom_agent\` | \`agent.create_custom\` | Create a draft custom agent shell and draft Charter seed from operational answers. | Tenant | Call with \`seat_id\` and operational answers; expect human confirmation. |
 | \`rost_configure_agent_tools\` | \`agent.configure_tools\` | Connect or decline proposed tools and stage credential-ingress requests (vault refs only). | Seat or tenant-admin | Never send raw secrets; expect a credential confirmation. |
 | \`rost_run_agent_dry_run\` | \`agent.run_dry_run\` | Run the sandbox dry run for a draft agent; durable and idempotent per Charter version. | Seat or tenant-admin | Call after the manifest is signed; ungated by human approval, but precondition-gated on a signed manifest. |
@@ -42781,6 +42848,7 @@ Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`
 | \`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>"}\`. |
 | \`rost_correct_signal_reading\` | \`signal.correct_reading\` | Overwrite a reading with a human-confirmed value. | Seat or tenant-admin | Manual correction; expect confirmation. |
+| \`rost_add_a_measurable\` | \`measurable.create\` | Add a measurable a seat owns (name, unit, direction, target, cadence). | Seat or tenant-admin | Call with \`{"seat_id":"<id>","name":"...","unit":"...","direction":"up_good","target":0,"cadence":"weekly"}\`. |
 | \`rost_list_cascade_goals\` | \`goal.list\` | List Cascade goals, optionally by cycle or seat. | Seat or tenant-admin | Call with \`{}\` or \`{"cycle_id":"<id>"}\`. |
 | \`rost_create_cascade_goal\` | \`goal.create\` | Create a cycle goal under an objective. | Tenant | Call with cycle, seat, parent, title, definition of done. |
 | \`rost_update_cascade_goal\` | \`goal.update\` | Update a goal's title or definition of done. | Tenant | Call with \`goal_id\` and the changed fields. |
@@ -42791,7 +42859,7 @@ Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`
 | \`rost_update_friction_issue_status\` | \`friction.update_status\` | Move a non-terminal issue between open and diagnosing. | Seat or tenant-admin | Call with \`issue_id\` and \`status\`. |
 | \`rost_resolve_friction_issue\` | \`friction.resolve\` | Resolve an issue with a root cause and remediation task. | Tenant | Human decision; expect confirmation. |
 | \`rost_link_task_to_friction_issue\` | \`friction.link_task\` | Attach an existing task as an issue's action task. | Seat or tenant-admin | Call with \`issue_id\` and \`task_id\`. |
-| \`rost_create_task\` | \`task.create\` | Create a task (a commitment between seats). | Seat or tenant-admin | Agent proposals land in draft for confirmation. |
+| \`rost_create_task\` | \`task.create\` | Create a task (a commitment between seats). | Seat or tenant-admin | \`none\` \u2014 created directly; the owning seat accepts or declines. |
 | \`rost_compile_sync_brief\` | \`sync.brief.compile\` | Compile the weekly Sync Brief (idempotent per period). | Tenant | Call with \`{}\`. |
 | \`rost_get_sync_brief\` | \`sync.brief.get\` | Read the latest or a specific Sync Brief and agenda. | Seat or tenant-admin | Call with \`{}\` or \`{"sync_brief_id":"<id>"}\`. |
 | \`rost_start_sync_run\` | \`sync.run.start\` | Ensure a Sync Brief exists so the meeting can begin. | Tenant | Call with \`{}\`. |
@@ -42850,6 +42918,7 @@ These rows are quick, at-a-glance triage. For deeper auth, tenant, scope, confir
 - Revoked, **expired**, or invalid MCP token: run \`{{cli}} mcp install --client <client> --scope <tenant-admin|seat>\` again to mint and register a fresh one (a direct install requires \`--scope\`; or rotate the old token in place with \`--rotate <old-token-id>\`, which inherits its scope). Tokens minted by \`mcp install\` default to a 90-day expiry \u2014 check \`expires_in_days\` in \`{{cli}} command mcp_token.list\`; mint with \`--expires-in <days>\` or \`--no-expiry\` to change it.
 - Confirmation required: a human approves from the \`approveVia\` web link or runs the \`{{cli}} command confirmation.approve --json ...\` command shown in the CLI error output (an agent never approves its own request \u2014 see the confirmations-guide).
 - Command denied by scope or manifest: switch to a tenant-admin token for setup, or ask a human Steward to update the seat Charter and permission manifest.
+- Inference budget hard cap reached (a run stops with a budget precondition error): raise the tenant hard cap with \`{{cli}} settings update --hard-cap-usd <amount>\` (command \`settings.update\`), then retry. A new company starts at a $0 hard cap, so managed-inference runs are blocked until it is set. The sandbox dry run is free and is never blocked by the cap, so you can charter, dry-run, and go live before setting a budget.
 - Need command guidance: run \`{{cli}} docs\`, \`{{cli}} reference search "onboarding"\`, or \`{{cli}} reference get agent-reference-map\`.
 - Need MCP guidance: call \`rost_reference_get\` with \`{"slug":"agent-reference-map"}\`.
 `
@@ -42859,7 +42928,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-13.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "graph_design", "charter_design", "staffing", "operating_rhythm"],
@@ -42910,9 +42979,13 @@ 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)
-- Show a Compass, Charter, or agent setup as a markdown card to review with your human: {{cli}} compass show --markdown, {{cli}} charter show <seat> --markdown, {{cli}} agent show <seat> --markdown
+- 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, or a dry run that has not passed) returns COMMAND_PRECONDITION_FAILED with a help pointer, not an opaque internal error.
+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.
+
+## Inference budget
+
+Agents that run on {{brand}}-managed inference draw against a tenant inference budget. A new company starts with a hard cap of $0, so a real managed-inference run is blocked until a human raises the cap with settings.update ({{cli}} settings update --hard-cap-usd <amount>). Hitting the cap returns a typed COMMAND_PRECONDITION_FAILED whose details.reason is budget.hard_cap_exceeded, with a help pointer naming that exact next command \u2014 not a generic internal error. The sandbox dry run is free and is never blocked by the cap, so an agent can be chartered, dry-run, and taken live before any budget is set; only real runs are gated. See settings-guide.
 
 ## Standard setup order
 
@@ -42978,7 +43051,7 @@ Retrieve the narrowest relevant guide before making a setup recommendation. Pref
     order: 60,
     title: "Cascade guide",
     summary: "How to connect company goals to seat-level work without turning {{brand}} into a project-management tool.",
-    version: "2026-06-13.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -43032,7 +43105,7 @@ Do not put every task into Cascade. Small errands, private notes, and work with
 
 ## When to stop for confirmation
 
-\`goal.create\`, \`goal.set_status\`, \`goal.reparent\`, and \`goal.drop\` are \`human_required\`. Moving or dropping a goal changes how the company reads its own progress, so it returns a pending confirmation over MCP. An agent proposes the branch and surfaces the approve link; a human decides.
+\`goal.reparent\` and \`goal.drop\` are \`human_required\`; \`goal.create\`, \`goal.set_status\`, and \`goal.update\` are \`none\`, so a seat can add goals and update their status directly. Moving or dropping a goal changes how the company reads its own progress, so it returns a pending confirmation over MCP. An agent proposes the branch and surfaces the approve link; a human decides.
 
 ## Agent guidance
 
@@ -43043,7 +43116,7 @@ Agents can suggest commitments and report progress. They should not create a new
     order: 61,
     title: "Signal guide",
     summary: "How to define and read measurables so the company runs on evidence instead of status theater.",
-    version: "2026-06-13.1",
+    version: "2026-06-18.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -43054,7 +43127,8 @@ Agents can suggest commitments and report progress. They should not create a new
       "signal.list",
       "signal.get",
       "signal.confirm_reading",
-      "signal.correct_reading"
+      "signal.correct_reading",
+      "measurable.create"
     ],
     legal: {
       publicRisk: "low",
@@ -43088,12 +43162,17 @@ Avoid vanity numbers, manual-only status fields, and metrics nobody can act on.
 ## Operate Signal from CLI or MCP
 
 - Read: \`{{cli}} signal list --json\` / \`signal.list\` / \`rost_list_signals\` returns measurables with their latest reading and on/off-track state. \`signal.get\` / \`rost_get_signal\` returns one measurable's full reading history.
+- Add a measurable: \`measurable.create\` (scope: seat) defines a measurable a seat owns \u2014 name, unit, direction, target, cadence. The seat owns it; readings attach to it afterward.
 - Record a reading: \`{{cli}} status record --measurable-id <id> --value <n>\` (\`status.record\`, scope: seat) writes a status event with the reading. This is not gated.
 - Confirm a reading: \`{{cli}} signal confirm\` / \`signal.confirm_reading\` / \`rost_confirm_signal_reading\` marks a reading human-verified. \`signal.correct_reading\` / \`rost_correct_signal_reading\` overwrites a reading with a human-confirmed value.
 
+## Run Signal without an agent
+
+A human can run the whole loop from the Signal page. Each measurable has a "Log this period's number" control that records a human reading (the same \`signal.correct_reading\` path), and an "Add a measurable" form creates one against a seat (the \`measurable.create\` path). You do not need an agent to keep Signal current.
+
 ## When to stop for confirmation
 
-\`signal.confirm_reading\` and \`signal.correct_reading\` are \`human_required\` \u2014 verifying or overwriting a measurable is a human judgment. An agent records readings with evidence; a human confirms or corrects.
+\`signal.correct_reading\` is \`human_required\`; overwriting a recorded measurable is a human judgment. \`signal.confirm_reading\` is \`none\`, so a seat can confirm its own readings directly. \`measurable.create\` is \`none\` \u2014 defining a measurable is not gated. An agent records readings with evidence; a human corrects when a value is wrong.
 
 ## Agent guidance
 
@@ -43104,7 +43183,7 @@ Agents may record readings when the Charter allows it. Agent-reported readings s
     order: 62,
     title: "Friction guide",
     summary: "How to capture issues with evidence, rank them, and resolve them without losing ownership.",
-    version: "2026-06-13.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -43158,12 +43237,12 @@ Agents should file Friction when a measurable breaks, a tool fails, a repeated e
 Friction, tasks, and escalations are the issue-to-action loop. A seat files, a task carries the work, and an escalation routes a decision a seat cannot make alone.
 
 - File and triage: \`{{cli}} friction file ...\` / \`friction.file_issue\` (seat) / \`rost_file_issue\`; list with \`{{cli}} friction list --status open --json\` / \`friction.list\` / \`rost_list_friction_issues\`; move between open and diagnosing with \`friction.update_status\` / \`rost_update_friction_issue_status\`.
-- Carry the work as a task: \`task.create\` / \`rost_create_task\` (a commitment between seats; agent proposals land in draft for confirmation). A seat runs its queue with \`{{cli}} task list|accept|decline|complete\` (\`task.list\`, \`task.accept\`, \`task.decline\`, \`task.complete\`). Link a task to an issue with \`friction.link_task\` / \`rost_link_task_to_friction_issue\`.
+- Carry the work as a task: \`task.create\` / \`rost_create_task\` (a commitment between seats). \`task.create\` is \`none\` (no confirmation gate), so an agent can file one directly; an agent's task lands as a **draft** proposal (\`origin: agent_proposal\`) for a human to review and hand off \u2014 not a live offer in the owning seat's accept/decline queue. A seat runs its queue with \`{{cli}} task list|accept|decline|complete\` (\`task.list\`, \`task.accept\`, \`task.decline\`, \`task.complete\`). Link a task to an issue with \`friction.link_task\` / \`rost_link_task_to_friction_issue\`.
 - Route a decision: \`escalation.raise\` (seat) / \`rost_escalate\` sends approval-scope or must-escalate work to the Steward queue. Reads are \`escalation.list\` / \`escalation.get\`. See the steward queue guide for resolution.
 
 ## When to stop for confirmation
 
-\`friction.resolve\`, \`friction.link_task\`, \`task.create\`, \`task.accept\`, \`task.decline\`, and \`task.complete\` are \`human_required\`; \`friction.update_status\`, \`escalation.raise\`, \`friction.file_issue\`, and \`friction.list\` are not gated. Resolving an issue or creating a cross-seat commitment is a human decision. An agent files Friction, proposes the task, and escalates; a human resolves and accepts.
+\`friction.resolve\` is \`human_required\`; resolving an issue is a human decision. \`friction.link_task\`, \`task.create\`, \`task.accept\`, \`task.decline\`, and \`task.complete\` are \`none\`, so a seat files issues, creates commitments, and runs its own task queue directly. \`friction.update_status\`, \`escalation.raise\`, \`friction.file_issue\`, and \`friction.list\` are also not gated. An agent files Friction, proposes the task, and escalates; a human resolves.
 
 ## Resolution rule
 
@@ -43174,7 +43253,7 @@ Resolving Friction should produce one of four outcomes: a decision, a task, a Ch
     order: 70,
     title: "Steward queue guide",
     summary: "How Stewards review escalations, approve agent boundaries, and keep agents accountable.",
-    version: "2026-06-13.1",
+    version: "2026-06-18.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -43209,12 +43288,14 @@ A Steward is the human accountable for an agent seat. The Steward queue is where
 
 Read the seat, Charter, evidence, and recommended action. Decide the narrow question first. If the same escalation repeats, revise the Charter rather than answering the same question forever.
 
+In the app, the evidence is shown as a legible card, not raw data: a proposed tool call lists the tool and its summarized arguments, and any attached context shows as labeled fields. Values that read like credentials are redacted, so you can decide without seeing secret material.
+
 ## Work the queue from CLI or MCP
 
 The Steward reads the queue from any surface but decides as a human.
 
 - Read: \`{{cli}} escalation list --json\` / \`escalation.list\` / \`rost_list_escalations\` (own steward chain for humans, own seat for agents). Read one with \`{{cli}} escalation get\` / \`escalation.get\` / \`rost_get_escalation\` \u2014 evidence, recommendation, and decision state.
-- Decide: \`{{cli}} escalation resolve\` / \`escalation.resolve\` and \`{{cli}} escalation reject\` / \`escalation.reject\`. These commands are \`human_required\` and are deliberately NOT exposed over MCP \u2014 \`decisions.decided_by\` must be a human, so there is no \`rost_resolve_escalation\` tool. The CLI runs them as the authenticated human; an agent session must hand the decision to a person.
+- Decide: \`{{cli}} escalation resolve\` / \`escalation.resolve\` and \`{{cli}} escalation reject\` / \`escalation.reject\`. \`escalation.resolve\` and \`escalation.reject\` are \`none\` at the confirmation layer, but they are deliberately NOT exposed over MCP \u2014 \`decisions.decided_by\` must be a human, so there is no \`rost_resolve_escalation\` tool. They are kept human-only by that MCP exclusion plus the human-only \`decided_by\`, not by a confirmation gate. The CLI runs them as the authenticated human; an agent session must hand the decision to a person.
 - Approve gated requests: when an escalation or Charter change produces a pending confirmation, the human approves with \`confirmation.approve\` (or rejects with \`confirmation.reject\`). Go-live runs through \`agent.go_live\`.
 
 ## When to stop for confirmation
@@ -43230,7 +43311,7 @@ Keep agent scope tight at first. Approve more autonomy only after evidence. Use
     order: 71,
     title: "Confirmations and human gates guide",
     summary: "How {{brand}} routes authority-changing work through human confirmation, and why agents never approve their own requests.",
-    version: "2026-06-15.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["graph_design", "charter_design", "staffing", "operating_rhythm"],
@@ -43254,10 +43335,12 @@ Keep agent scope tight at first. Approve more autonomy only after evidence. Use
 
 ## Confirmation levels
 
-- \`none\`: safe to run directly. Reads and reversible drafts (graph reads, \`charter.draft\`, \`status.record\`, \`sync.brief.compile\`).
-- \`human_required\`: a human must approve. Structural, staffing, resolution, and go-live commands (\`seat.create\`, \`charter.approve\`, \`goal.reparent\`, \`friction.resolve\`, \`agent.go_live\`, \`escalation.resolve\`).
-- \`dangerous\`: a human must approve and the request is flagged high-risk because it touches secrets or tokens (\`credential.ingress\`, \`mcp_token.create\`, \`tenant.anthropic_key.save\`, \`confirmation.approve\` itself).
-- \`credential_flow\`: routes through the vault-backed credential path so a secret is captured as a vault reference, never stored or logged in the clear.
+- \`none\`: no confirmation gate \u2014 the command never returns a pending confirmation. Most are reads or reversible drafts an agent can run directly, including over MCP (graph reads, \`charter.draft\`, \`status.record\`, \`sync.brief.compile\`, \`sync.run.start\`, \`task.complete\`). A few \`none\` commands still require a human actor or an interactive channel \u2014 \`confirmation.approve\` is \`none\` (approving a gate cannot itself be gated) yet runs only as a human in the UI or CLI \u2014 so \`none\` means "no confirmation gate", not always "agent-callable".
+- \`human_required\`: a human must approve. Structural, staffing, resolution, and go-live commands (\`seat.reparent\`, \`charter.approve\`, \`goal.reparent\`, \`friction.resolve\`, \`agent.go_live\`, \`mcp_token.create\`).
+- \`credential_flow\`: routes through the vault-backed credential path so a secret is captured as a vault reference, never stored or logged in the clear (\`credential.ingress\`, \`tenant.anthropic_key.save\`; \`agent.configure_tools\` is \`credential_flow\` too \u2014 it stages credential-ingress requests through the same path without ever taking raw secret material).
+- \`dangerous\`: the highest-risk human gate. Only two commands carry it \u2014 \`settings.update\` and \`agent.decommission\`.
+
+The \`dangerous\` confirmation **level** is rare and is not the same as the **risk badge** a pending confirmation can display. The badge shows "dangerous" whenever a command's confirmation level is \`dangerous\` **or** the command redacts secrets (its audit redaction is \`secret_strict\`), so a \`credential_flow\` command such as \`credential.ingress\` shows the dangerous badge while still gating through the credential path \u2014 not the \`dangerous\` level. Read the badge as "handle with care" and the confirmation level as "who must approve". \`confirmation.approve\` and \`confirmation.reject\` are themselves \`none\` \u2014 approving a gate cannot itself require approval.
 
 ## What a gated command returns over MCP
 
@@ -43283,7 +43366,7 @@ Stop before: approving a Charter, signing a manifest, connecting a tool or crede
     order: 72,
     title: "Settings guide",
     summary: "How to use Settings as the control plane for company access, channels, providers, tokens, and operating defaults.",
-    version: "2026-06-16.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -43319,6 +43402,14 @@ Start with members and invites, then provider and channel connections, then MCP
 
 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.
 
+## 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.
+
 ## Agent guidance
 
 Agents may explain which setting is needed and why. They should not ask users to paste secrets into chat or tool arguments. When credentials are required, route the user to the vault-backed setup flow.`
@@ -43396,7 +43487,7 @@ Every notification should include the seat, cause, evidence, and requested decis
     order: 75,
     title: "Local runner guide",
     summary: "How local agent sessions and runner surfaces should operate through {{brand}} without bypassing Charters or audit.",
-    version: "2026-06-13.1",
+    version: "2026-06-19.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -43426,12 +43517,22 @@ The local runner is for human-controlled local agent work. It should retrieve {{
 
 - Pair a new runner: \`runner.pairing.start\` / \`rost_start_runner_pairing\` with \`name\` and \`platform\` returns a human pairing code.
 - Inspect: \`{{cli}} runner list --json\` / \`runner.list\` / \`rost_list_runners\` shows online/offline/revoked state; \`{{cli}} runner status\` / \`runner.status\` / \`rost_runner_status\` reads one runner.
-- Work orders: \`{{cli}} runner work-orders\` / \`work_order.list\` / \`rost_list_work_orders\`; queue with \`work_order.enqueue\` / \`rost_enqueue_work_order\` for a live scheduled agent; cancel with \`work_order.cancel\` / \`rost_cancel_work_order\`.
+- Work orders: \`{{cli}} runner work-orders\` / \`work_order.list\` / \`rost_list_work_orders\`; queue with \`work_order.enqueue\` / \`rost_enqueue_work_order\` for a live scheduled agent, or use \`agent.run_now\` / \`rost_run_agent_now\` when an operator wants the product to queue and dispatch an immediate live run from a seat id; cancel with \`work_order.cancel\` / \`rost_cancel_work_order\`.
 - Revoke: \`{{cli}} runner revoke\` / \`runner.revoke\` / \`rost_revoke_runner\` so a runner can no longer authenticate.
 
+## Owner-initiated headless pairing
+
+Use this flow when a headless or desktop runner cannot use the interactive web confirmation flow.
+
+1. The owner runs \`runner.pairing.start\` or \`rost_start_runner_pairing\` with the runner \`name\` and \`platform\`.
+2. The owner gives the returned \`user_code\` to the runner through a trusted out-of-band channel.
+3. The runner calls \`POST /api/runner/pairing/claim\` with \`{"user_code":"ABCD-2345"}\`.
+4. The response returns \`runner_id\`, \`runner_secret\`, \`name\`, and \`platform\`. Store the runner secret only on the runner machine.
+5. The runner sends heartbeats with \`Authorization: Bearer <runner_secret>\` and then claims work orders.
+
 ## When to stop for confirmation
 
-\`runner.pairing.start\`, \`runner.revoke\`, \`work_order.enqueue\`, and \`work_order.cancel\` are \`human_required\`; list and status reads are not gated. Pairing, revoking, and queuing or cancelling work are human-approved. An agent inspects runner state and proposes the action.
+\`runner.revoke\` and \`work_order.cancel\` are \`human_required\`; \`runner.pairing.start\`, \`work_order.enqueue\`, and \`agent.run_now\` are \`none\`, so an operator can pair a runner and queue work directly. List and status reads are not gated. Revoking a runner or cancelling work is the human-approved act. An agent inspects runner state and proposes the action.
 
 ## Guardrails
 
@@ -43552,7 +43653,7 @@ Templates may draft. Humans approve. A stock agent should not go live until a hu
     order: 77,
     title: "Troubleshooting guide",
     summary: "How users and agents should diagnose common setup, tool, Signal, Friction, and MCP problems.",
-    version: "2026-06-18.3",
+    version: "2026-06-18.4",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing", "operating_rhythm"],
@@ -43611,7 +43712,7 @@ These are the common blockers when adding an agent (see the add-agents guide and
 
 ## When to stop for confirmation
 
-Most reads are safe to run while diagnosing. Any fix that changes authority, credentials, go-live state, or a durable decision is \`human_required\` or \`dangerous\` and routes through \`confirmation.approve\`. Diagnose freely; stop before approving.
+Most reads are safe to run while diagnosing. Any fix that changes authority, credentials, go-live state, or a durable decision is gated \u2014 \`human_required\`, \`credential_flow\`, or \`dangerous\` \u2014 and routes through a human confirmation (\`confirmation.approve\`). Diagnose freely; stop before approving.
 
 ## Agent guidance
 
@@ -43850,7 +43951,7 @@ A consultancy's purpose might be "Make expert tax guidance affordable for first-
     order: 31,
     title: "Charter authoring deep-dive",
     summary: "The full Charter document contract field by field \u2014 decision authority, escalation, measurables, budget, permissions \u2014 with worked examples for human, agent, and hybrid seats.",
-    version: "2026-06-16.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["cli", "mcp", "in_app_agent"],
     stages: ["charter_design", "staffing"],
@@ -43894,7 +43995,7 @@ A Charter is a seat's executable operating contract. On the CLI and MCP path you
 - **decision_authority** \u2014 the heart of the contract, split three ways:
   - **autonomous** \u2014 what the seat may do without asking. Each item is \`{ action, condition, rationale, unanswered_boundary }\`. Only reversible, low-risk, in-scope actions belong here. An autonomous item must have \`unanswered_boundary: false\` \u2014 the schema rejects an autonomous item with an unanswered boundary (push it to escalate instead).
   - **approval** \u2014 the can-do-with-a-yes set: durable, money-moving, external-send, staffing, or policy actions that require explicit human approval. Name the **threshold** in the \`condition\` (e.g. "before posting or sending," "over $5,000").
-  - **escalate** (1+) \u2014 the must-ask set: ambiguous authority, irreversible actions, credentials, legal or financial exposure, customer-impacting exceptions. At least one escalate item must carry \`unanswered_boundary: true\` so unresolved boundaries default conservative.
+  - **escalate** (1+) \u2014 the must-ask set: ambiguous authority, irreversible actions, credentials, legal or financial exposure, customer-impacting exceptions. At least one escalate item should carry \`unanswered_boundary: true\` so unresolved boundaries default conservative. The submit schema does not strictly require it, but the direct submit path (\`charter.update_draft\` / \`charter.set\`) does not add one for you \u2014 it only records the boundaries you flag \u2014 so include one whenever a boundary is unresolved.
 - **escalation_rules** (1+) \u2014 plain-language rules that trigger escalation, beyond the structured authority items. "Escalate any invoice over $5,000 or from a vendor not already in the ledger."
 - **measurables** (1+) \u2014 each \`{ name, target, cadence, source }\`. A measurable must measure the accountability, not vanity. \`cadence\` is \`daily|weekly|monthly|quarterly\`; \`source\` is \`human|agent|integration\`. Agent-sourced readings are unconfirmed until a human confirms them.
 - **permission_manifest** \u2014 each \`{ tool, scope, granted, rationale }\`. Map each accountability to the narrowest tool scope that performs it. Prefer draft/read scopes; a send or spend scope is a deliberate, justified grant. The manifest is what the tool-guard enforces and what a human signs.
@@ -44946,6 +45047,20 @@ function field(record2, key) {
   }
   return String(value);
 }
+function formatDryRunTranscript(value) {
+  const transcript = asRecord(value);
+  const steps = asArray(transcript.steps);
+  if (steps.length === 0) {
+    return "";
+  }
+  const lines = steps.map((step) => {
+    const record2 = asRecord(step);
+    const kind = field(record2, "kind");
+    const guard = record2.guard === null || record2.guard === void 0 ? "" : ` [${field(record2, "guard")}]`;
+    return `  ${kind}: ${field(record2, "text")}${guard}`;
+  });
+  return ["rehearsal:", ...lines].join("\n");
+}
 function markdownLine(output) {
   const markdown = asRecord(output).markdown;
   return typeof markdown === "string" ? markdown : JSON.stringify(output, null, 2);
@@ -45663,8 +45778,9 @@ var agentWrapper = (context, args) => dispatch(context, "agent", args, {
     };
     return execute(ctx, parsed, "agent.run_dry_run", body, (output) => {
       const record2 = asRecord(output);
-      return `dry run for seat ${field(record2, "seat_id")} (charter ${field(record2, "charter_version_id")}): ${field(record2, "status")} (reused=${field(record2, "reused")})
+      const header = `dry run for seat ${field(record2, "seat_id")} (charter ${field(record2, "charter_version_id")}): ${field(record2, "status")} (reused=${field(record2, "reused")})
 ${field(record2, "summary")}`;
+      return [header, formatDryRunTranscript(record2.transcript)].filter((part) => part.length > 0).join("\n");
     });
   },
   "go-live": (ctx, rest) => {
@@ -45686,6 +45802,16 @@ ${field(record2, "summary")}`;
       return `agent seat ${field(record2, "seat_id")}  status=${field(record2, "status")}  live=${field(record2, "live")}  lane=${field(record2, "lane")}`;
     });
   },
+  "run-now": (ctx, rest) => {
+    const parsed = parseFlags(rest);
+    const body = withOptional({ seat_id: requireValue2(parsed, "seat-id") }, {
+      task_id: optionalValue(parsed, "task-id")
+    });
+    return execute(ctx, parsed, "agent.run_now", body, (output) => {
+      const workOrder = asRecord(asRecord(output).work_order);
+      return `queued ${field(workOrder, "lane")} work order ${field(workOrder, "id")} for agent ${field(workOrder, "agent_id")} (${field(workOrder, "status")})`;
+    });
+  },
   // DER-787 (H8): markdown readout for a seat's agent setup. `--markdown` (or
   // default) prints the composed card; `--json` returns the { markdown } object.
   show: (ctx, rest) => {
@@ -45712,7 +45838,7 @@ function agentConfigureTools(ctx, rest, decision) {
   });
 }
 function agentUsage(bin) {
-  return `Usage: ${bin} agent templates|create|setup|tools|dry-run|go-live|status|show [--json]
+  return `Usage: ${bin} agent templates|create|setup|tools|dry-run|go-live|status|run-now|show [--json]
   ${bin} agent templates
   ${bin} agent create --seat-id <id> --template <slug> [--expected-version <v>]
   ${bin} agent create --seat-id <id> --custom [--steward-seat-id <id>] [--lane cloud|mcp_session|runner] [--model triage|balanced|complex|hardest|<id>] [--effort low|medium|high|xhigh|max] [--owns <text>] [--success <text>] [--never-alone <text>]
@@ -45722,6 +45848,7 @@ function agentUsage(bin) {
   ${bin} agent dry-run --seat-id <id> --charter-version-id <id>
   ${bin} agent go-live --seat-id <id> --charter-version-id <id>
   ${bin} agent status --seat-id <id>
+  ${bin} agent run-now --seat-id <id> [--task-id <id>]
   ${bin} agent show --seat-id <id> [--markdown]`;
 }
 function agentSetupUsage(bin) {
@@ -45863,7 +45990,7 @@ function operationUsageLines(bin) {
     `${bin} notification settings|test`,
     `${bin} settings get|update`,
     `${bin} member invite|update|remove`,
-    `${bin} agent templates|create|setup|tools|dry-run|go-live|status|show`,
+    `${bin} agent templates|create|setup|tools|dry-run|go-live|status|run-now|show`,
     `${bin} tools list`,
     `${bin} compass show`,
     `${bin} charter show`