@rosthq/cli 0.5.6 → 0.5.7

package/dist/index.js

@@ -41486,7 +41486,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.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "graph_design", "charter_design", "staffing", "operating_rhythm"],
@@ -41584,14 +41584,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.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["graph_design", "staffing"],
@@ -41688,7 +41688,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,7 +41769,7 @@ 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-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -41824,7 +41824,7 @@ Two creation paths, both draft-first. Read the stock-agents guide for templates
 
 ## 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\`. 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.
 
 ## Non-negotiables
 
@@ -41915,7 +41915,7 @@ In read-only or demo mode the **Add agent** affordance is disabled or routes to
     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.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "charter_design"],
@@ -41971,18 +41971,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 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 +42041,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 +42052,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-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -42123,7 +42123,7 @@ 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.
 
 ## What humans should review
 
@@ -42134,7 +42134,7 @@ Review the first dry runs, tool-call audit rows, escalations, and Signal impact.
     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-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -42185,13 +42185,13 @@ 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",
@@ -42241,7 +42241,7 @@ Agents should explain the job, the required tool category, the minimum permissio
     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-18.10",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -42755,6 +42755,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. |
@@ -42791,7 +42793,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 \`{}\`. |
@@ -42859,7 +42861,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,7 +42912,7 @@ Never guess a command's JSON shape. Before calling a command that changes state,
 - List every callable command: {{cli}} command list (CLI) or rost_list_commands (MCP)
 - Read one command's exact input/output schema, help pointer, and a worked example: {{cli}} command schema <id> (CLI) or rost_describe_command with {"command_id":"<id>"} (MCP)
 - List the tool catalog the agent builder reads (id, scope tiers, credential requirement, access policy \u2014 configuration only; the tools do not execute yet): {{cli}} tools list (CLI) or rost_list_tool_catalog (MCP)
-- 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.
 
@@ -42978,7 +42980,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 +43034,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 +43045,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.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -43093,7 +43095,7 @@ Avoid vanity numbers, manual-only status fields, and metrics nobody can act on.
 
 ## 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. An agent records readings with evidence; a human corrects when a value is wrong.
 
 ## Agent guidance
 
@@ -43104,7 +43106,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 +43160,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 +43176,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.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -43214,7 +43216,7 @@ Read the seat, Charter, evidence, and recommended action. Decide the narrow ques
 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 +43232,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 +43256,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
 
@@ -43396,7 +43400,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-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -43431,7 +43435,7 @@ The local runner is for human-controlled local agent work. It should retrieve {{
 
 ## 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\` 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.
 
 ## Guardrails
 
@@ -43552,7 +43556,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 +43615,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 +43854,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 +43898,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 +44950,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 +45681,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) => {