@rosthq/cli 0.5.7 → 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-18.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.
@@ -41591,7 +41600,7 @@ The Compass is drafted, then activated by a human through supersession.
     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-18.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.
@@ -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-18.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\`, \`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\`. 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-18.2",
+    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,7 +42003,7 @@ The same path is command-backed:
 
 ## Dry run and 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 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.
+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
 
@@ -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-18.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",
@@ -42125,16 +42158,27 @@ A seat-scoped MCP token already carries the seat, so its tools (\`rost_get_tasks
 
 \`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-18.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.
@@ -42198,7 +42250,7 @@ Connecting a tool is a human-controlled step. The agent can recommend a tool, ex
     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.10",
+    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. |
@@ -42783,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. |
@@ -42852,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"}\`.
 `
@@ -42914,7 +42981,11 @@ Never guess a command's JSON shape. Before calling a command that changes state,
 - 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-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
 
@@ -43045,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-18.1",
+    version: "2026-06-18.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -43056,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",
@@ -43090,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.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. An agent records readings with evidence; a human corrects when a value is wrong.
+\`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
 
@@ -43176,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-18.1",
+    version: "2026-06-18.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -43211,6 +43288,8 @@ 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.
@@ -43287,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"],
@@ -43323,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.`
@@ -43400,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-18.1",
+    version: "2026-06-19.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -43430,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.revoke\` and \`work_order.cancel\` are \`human_required\`; \`runner.pairing.start\` and \`work_order.enqueue\` 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.
+\`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
 
@@ -45705,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) => {
@@ -45731,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>]
@@ -45741,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) {
@@ -45882,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`