@rosthq/cli 0.5.29 → 0.5.31

package/dist/index.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";AAMA,OAAO,EAAE,gBAAgB,EAAE,yBAAyB,EAAE,MAAM,WAAW,CAAC;AACxE,OAAO,EAAoB,mBAAmB,EAAE,MAAM,kBAAkB,CAAC;AACzE,OAAO,EAAoB,KAAK,UAAU,EAAE,MAAM,kBAAkB,CAAC;AAerE,KAAK,KAAK,GAAG;IACX,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC;IAC1C,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC;IAK1C,WAAW,CAAC,EAAE,OAAO,CAAC;CACvB,CAAC;AAEF,KAAK,WAAW,GAAG;IACjB,KAAK,CAAC,EAAE,UAAU,CAAC;IACnB,EAAE,CAAC,EAAE,KAAK,CAAC;IACX,KAAK,CAAC,EAAE,OAAO,gBAAgB,CAAC;IAChC,WAAW,CAAC,EAAE,OAAO,mBAAmB,CAAC;IACzC,cAAc,CAAC,EAAE,OAAO,yBAAyB,CAAC;CACnD,CAAC;AAEF,wBAAsB,IAAI,CAAC,IAAI,WAAwB,EAAE,OAAO,GAAE,WAAgB,GAAG,OAAO,CAAC,MAAM,CAAC,CAgPnG;AA+bD,wBAAgB,eAAe,CAAC,SAAS,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,GAAG,SAAS,GAAG,OAAO,CAUxF"}
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";AAMA,OAAO,EAAE,gBAAgB,EAAE,yBAAyB,EAAE,MAAM,WAAW,CAAC;AACxE,OAAO,EAAoB,mBAAmB,EAAE,MAAM,kBAAkB,CAAC;AACzE,OAAO,EAAoB,KAAK,UAAU,EAAE,MAAM,kBAAkB,CAAC;AAerE,KAAK,KAAK,GAAG;IACX,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC;IAC1C,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC;IAK1C,WAAW,CAAC,EAAE,OAAO,CAAC;CACvB,CAAC;AAEF,KAAK,WAAW,GAAG;IACjB,KAAK,CAAC,EAAE,UAAU,CAAC;IACnB,EAAE,CAAC,EAAE,KAAK,CAAC;IACX,KAAK,CAAC,EAAE,OAAO,gBAAgB,CAAC;IAChC,WAAW,CAAC,EAAE,OAAO,mBAAmB,CAAC;IACzC,cAAc,CAAC,EAAE,OAAO,yBAAyB,CAAC;CACnD,CAAC;AAEF,wBAAsB,IAAI,CAAC,IAAI,WAAwB,EAAE,OAAO,GAAE,WAAgB,GAAG,OAAO,CAAC,MAAM,CAAC,CAmPnG;AA6cD,wBAAgB,eAAe,CAAC,SAAS,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,GAAG,SAAS,GAAG,OAAO,CAUxF"}

package/dist/index.js

@@ -41758,7 +41758,7 @@ When operating through CLI or MCP, create fewer seats first and ask for confirma
     order: 30,
     title: "Charter design playbook",
     summary: "How to draft strong Charters that work for human, agent, and hybrid seats.",
-    version: "2026-06-20.1",
+    version: "2026-06-30.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["charter_design", "staffing"],
@@ -41815,7 +41815,9 @@ List and read first, then draft, then leave activation to a human.
 - Draft one: \`{{cli}} command charter.draft --json '{"seat_id":"<seat-id>"}'\` (scope: seat or tenant-admin); draft every eligible seat with \`charter.draft_all\` / \`rost_draft_all_charters\`. Draft commands are not gated \u2014 they produce a draft \`charter_version_id\`. \`charter.draft_all\` only drafts **active** seats and returns the real result: \`{ drafted, skipped, draft_ids, skipped_seats: [{ seat_id, reason }] }\` where \`reason\` is \`seat_not_active\` (the seat is still draft/vacant \u2014 confirm it first) or \`charter_exists\` (it already has a draft/active Charter). Read \`skipped_seats\` to see why a freshly-built graph drafted fewer Charters than it has seats.
 - Edit a draft: \`charter.update_draft\` / \`rost_update_charter_draft\` with the \`charter_version_id\` and the new \`doc\`.
 
-In the app, \`/charters\` is both a drafting queue and a governance library. It shows active Charters, draft amendments, seats missing Charters, unsigned manifests, and steward-review gaps. Opening a live Charter is a review mode: read the active version, inspect its governance state, and open an amendment draft when the job needs to change. Active Charter content is never silently edited in place.
+In the app, \`/charters\` is both a drafting queue and a governance library. It shows active Charters, draft amendments, seats missing Charters, unsigned manifests, and steward-review gaps. \`/charters/builder\` is the seat picker for Charter Builder: start there when you need to draft a missing Charter, continue an amendment, or review which seats are still missing operating contracts. Opening a live Charter is a review mode: read the active version, inspect its governance state, and open an amendment draft when the job needs to change. Active Charter content is never silently edited in place.
+
+Daily and weekly measurable rows can carry Signal metadata: unit, numeric target, direction, cadence, and source. When a human approves a Charter, those structured measurables materialize into tenant Signal definitions for that seat. Free-text, monthly, and quarterly measurable prose remains accountability text until a human converts it into a supported structured Signal or creates the Signal separately.
 
 ## When to stop for confirmation
 
@@ -42071,7 +42073,7 @@ The dry run is a real sandbox rehearsal, not a stamp. It executes a mock-provide
     order: 80,
     title: "Sync rhythm playbook",
     summary: "How Signal, Friction, Cascade, and Sync Briefs turn weekly meetings into decision time.",
-    version: "2026-06-20.2",
+    version: "2026-06-30.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -42119,7 +42121,7 @@ The Sync Brief should answer:
 
 On screen the brief reads in plain terms: Signal exceptions, goal progress, task review, ranked Friction, and agent activity. Where a section has no source data, it lists gaps to confirm \u2014 the missing inputs a human should know about before the meeting \u2014 rather than a blank section.
 
-Before the first brief exists, the Sync pages are readiness views. They show the next scheduled compile and the source areas that will feed it: Signal, Cascade, Tasks, Friction, and Agents. Use those links to add the missing source data; there is no manual compile button until the system has an idempotent persisted operation to run.
+Before the first brief exists, the Sync pages are readiness views. They show the next scheduled compile and the source areas that will feed it: Signal, Cascade, Tasks, Friction, and Agents. Use those links to add missing source data, or use Compile now to run the same idempotent persisted compile operation immediately when the company uses company-wide Sync Briefs. If the company is configured for per-cluster briefs, compile the target cluster from CLI or MCP with a cluster id until the UI offers a cluster selector. Once a brief exists, the page shows whether it covers the current period, when it was compiled, and which sections were omitted or compiled with gaps.
 
 The same readiness model appears around the meeting loop. Steward shows the governance loop even when no decision is waiting: which agent seats are stewarded, how many escalations are open, and recent raised/decided counts. Tasks explains when nothing is due and points to recently completed or agent-blocked work when it exists. The agent fleet shows configuration completeness per staffed agent seat \u2014 steward chain, lane/trigger/substrate, credentials, tools, model, dry run, and go-live \u2014 with links to the exact setup surface rather than a generic action button.
 
@@ -42257,7 +42259,7 @@ Use the lower-level commands after health names a finding: \`agent.get_run\` for
     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-29.1",
+    version: "2026-06-30.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -42307,15 +42309,15 @@ For an API with no dedicated connector, the generic REST tool lets a seat call a
 
 ## Gmail connector
 
-The native Gmail handlers run inside the same broker boundary as the REST and Slack connectors: every call passes the server guard and writes an audit row, and the vaulted Google OAuth token is bound only inside a credential closure \u2014 the agent never sees it, and both the access and refresh tokens are redacted from anything a handler returns. \`gmail.read\` (read scoped inbox) and \`gmail.draft\` (compose a draft, never send) are autonomous-eligible. \`gmail.send\` is approval-gated: it never sends autonomously \u2014 it holds the action for steward approval. A sandbox dry run previews the intended read/draft/held-send with no Gmail request and without opening the vault. Live external Gmail send stays gated on Google verification and domain cutover (DER-880 / DER-881); the draft and send-with-approval paths are live now.
+The native Gmail handlers run inside the same broker boundary as the REST and Slack connectors: every call passes the server guard and writes an audit row, and the vaulted Google OAuth token is bound only inside a credential closure \u2014 the agent never sees it, and both the access and refresh tokens are redacted from anything a handler returns. \`gmail.read\` (read scoped inbox) and \`gmail.draft\` (compose a draft, never send) are autonomous-eligible when a tenant has a connected Google credential. \`gmail.send\` is approval-gated: it never sends autonomously \u2014 it holds the action for steward approval. A sandbox dry run previews the intended read/draft/held-send with no Gmail request and without opening the vault. For partner demos before Google verification is complete, use sandbox dry runs, setup previews, and approval-held examples as the demo-safe substitute. Live external Gmail send stays gated on Google verification and domain cutover (DER-880 / DER-881).
 
 ## Google connector status
 
-Google can be connected from Settings once the workspace OAuth app is configured. The connection flow requests offline access for Gmail read/compose and Sheets, stores the returned credential in the vault, and records only account and scope metadata in the integration row. The test action refreshes the vaulted credential and performs a minimal Gmail profile read. Gmail read/draft, bounded Sheets read, and approval-held Sheets write handlers now run through the guarded broker; connecting Google still does not bypass the signed Charter manifest, tenant policy ceiling, credential vault, or tool-call audit. Sheet grants should use exact signed argument bindings for approved spreadsheet ids and ranges.
+Google can be connected from Settings once the workspace OAuth app is configured. The connection flow requests offline access for Gmail read/compose and Sheets, stores the returned credential in the vault, and records only account and scope metadata in the integration row. The test action refreshes the vaulted credential and performs a minimal Gmail profile read. Gmail read/draft, bounded Sheets read, and approval-held Sheets write handlers run through the guarded broker when Google is connected; connecting Google still does not bypass the signed Charter manifest, tenant policy ceiling, credential vault, or tool-call audit. Sheet grants should use exact signed argument bindings for approved spreadsheet ids and ranges.
 
 CLI and MCP can inspect connector readiness without seeing secrets: \`integration.list\` / \`rost_list_integrations\` lists connected providers and health metadata, \`integration.status\` / \`rost_get_integration_status\` reads one provider by id or name, and \`integration.test\` / \`rost_test_integration_connection\` runs the installed provider-specific health check. For Google, the test refreshes the vaulted OAuth credential and reads the Gmail profile, then records only account, scope, and health metadata.
 
-\`integration.readiness\` / \`{{cli}} integration readiness --provider google --json\` / \`rost_check_integration_readiness\` returns the same setup checklist Settings shows: OAuth env and callback status, tenant connection state, granted scopes, latest test state, external verification/CASA caveats, handler availability, and the next Linear issue or action. The checklist is metadata-only. It never returns access tokens, refresh tokens, client secrets, vault refs, or raw provider responses.
+\`integration.readiness\` / \`{{cli}} integration readiness --provider google --json\` / \`rost_check_integration_readiness\` returns the same setup checklist Settings shows: OAuth env and callback status, tenant connection state, granted scopes, latest test state, the demo-safe partner path, external verification/CASA caveats, handler availability, and the next Linear issue or action. The checklist is metadata-only. It never returns access tokens, refresh tokens, client secrets, vault refs, or raw provider responses.
 
 ## One write-only credential flow across every surface
 
@@ -42346,7 +42348,7 @@ There is exactly one way to give a connected tool its credential, and it is the
     order: 47,
     title: "Available tools guide",
     summary: "How to think about tool categories available to seats and what each category should be used for.",
-    version: "2026-06-29.1",
+    version: "2026-06-30.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -42392,14 +42394,14 @@ Agents should explain the job, the required tool category, the minimum permissio
 
 Every tool call passes the server-side guard first: the guard checks the call against the seat's signed permission manifest and records a tool-call audit row for **every** call \u2014 allowed, denied, or escalated. Tool selection is never authorization. Only an allowed call reaches its handler. A connected credential is bound into the handler for the duration of the call only; the secret never appears in the result, the audit summary, logs, or the model's context.
 
-External connectors are being rolled out provider by provider, conservatively (read and draft before send; write behind approval). A selected tool is only a permission until a live handler exists and the seat has the required credential or binding. Today the built-in execution path supports internal status reporting, the generic REST connector when a signed host/method/path allowlist and credential exist, \`slack.post_message\` for a bound Slack channel, and Google handlers for \`gmail.read\`, \`gmail.draft\`, \`sheets.read\`, and approval-held \`sheets.write\` when Google is connected. \`gmail.send\` remains held for approval and live external send stays gated on Google verification. Other provider entries remain configuration-only until their connector ships, so nothing runs silently.`
+External connectors are being rolled out provider by provider, conservatively (read and draft before send; write behind approval). A selected tool is only a permission until a live handler exists and the seat has the required credential or binding. Today the built-in execution path supports internal status reporting, the generic REST connector when a signed host/method/path allowlist and credential exist, \`slack.post_message\` for a bound Slack channel, and Google handlers for \`gmail.read\`, \`gmail.draft\`, \`sheets.read\`, and approval-held \`sheets.write\` when Google is connected. \`gmail.send\` remains held for approval and live external send stays gated on Google verification. Before that verification is complete, partner demos should show sandbox dry runs, setup previews, and approval-held examples rather than claim production Google readiness. Other provider entries remain configuration-only until their connector ships, so nothing runs silently.`
   },
   {
     slug: "mcp-and-cli-guide",
     order: 48,
     title: "CLI and MCP installation guide",
     summary: "Install the public CLI, register remote token-backed MCP clients, and find the full command and tool catalog.",
-    version: "2026-06-28.3",
+    version: "2026-06-30.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -42522,9 +42524,9 @@ Commands below use angle-bracket placeholders. The CLI prints the real, fully-re
 A {{brand}} **account** (the human identity) is created with Google sign-in \u2014 in the browser at \`/signup\`, or headlessly via \`{{cli}} login --device\` (a human approves the code in any browser). A **company** (tenant) can then be created either way:
 
 - **Browser:** at \`/signup\`, name your company, then return to the CLI.
-- **Headless (no browser step):** once logged in, run \`{{cli}} signup --company "<name>"\`. This provisions the company for your session and makes it your active tenant, so \`{{cli}} onboard status\` and every other tenant-scoped command work immediately. This is the recommended path for an autonomous agent setting up from scratch.
+- **Headless (no browser step):** once logged in, run \`{{cli}} signup --company "<name>"\`. If the account has no active company yet, this provisions the first company for your session and makes it active, so \`{{cli}} onboard status\` and every other tenant-scoped command work immediately. This is the recommended path for an autonomous agent setting up from scratch.
 
-If you run a tenant-scoped command before any company exists, the CLI tells you both options. You only get one company per signup; running \`{{cli}} signup --company\` again returns your existing company rather than creating a duplicate.
+If you run a tenant-scoped command before any company exists, the CLI tells you both options. \`{{cli}} signup --company\` is not a second-company creation command: running it again returns the active company, names the company you requested, and says that no new company was created. The default output is human-readable; add \`--json\` only when an automation needs the raw command output. To inspect or switch among companies you can already access, use \`{{cli}} tenants\` and \`{{cli}} use <tenant-slug-or-id>\`. Additional company creation is not exposed as a public self-serve CLI path in this milestone.
 
 ## Install the CLI
 
@@ -42788,7 +42790,7 @@ These are the security posture rules for operating after install \u2014 a checkl
 | \`{{cli}} login\` | Open browser login and store the CLI session. | User session | \`{{cli}} login\` |
 | \`{{cli}} login --device\` | Device-code login for a headless agent: prints a short code + URL, a human approves in any browser, the CLI polls until authorized \u2014 no browser session needed on the agent's machine. | User session | \`{{cli}} login --device\` |
 | \`{{cli}} logout\` | Clear the local CLI session. | Local session | \`{{cli}} logout\` |
-| \`{{cli}} signup [--company "<name>"]\` | With no flag, open/print the web signup page. With \`--company\`, create the company headlessly for the logged-in session (no browser step) \u2014 it becomes your active tenant. | Public (\`--company\` needs a login session) | \`{{cli}} signup --company "Acme"\` |
+| \`{{cli}} signup [--company "<name>"] [--json]\` | With no flag, open/print the web signup page. With \`--company\`, bootstrap the first company headlessly for the logged-in session. If one is already active, it returns that company and says no new company was created. Add \`--json\` for machine-readable output. | Public (\`--company\` needs a login session) | \`{{cli}} signup --company "Acme"\` |
 | \`{{cli}} whoami\` | Show the authenticated user, accessible tenant roles, and the active tenant (\`current_tenant_id\`). | User | \`{{cli}} whoami\` |
 | \`{{cli}} tenants\` | List tenants the user can access; the active one is marked \`current\`. | User | \`{{cli}} tenants\` |
 | \`{{cli}} use <tenant>\` | Select a tenant slug or id as the active tenant for the session. It persists, so a following \`{{cli}} whoami\` reports it as \`current_tenant_id\`. | User | \`{{cli}} use acme-ops\` |
@@ -42848,7 +42850,7 @@ The signed-in app exposes the same Skill command surface under **Skills** in the
 | \`{{cli}} escalation list|get|resolve|reject\` | \`escalation.list\`, \`escalation.get\`, \`escalation.resolve\`, \`escalation.reject\` | Work the steward escalation queue. | Steward | \`{{cli}} escalation list --json\` |
 | \`{{cli}} error list|resolve|supersede\` | \`error_log.list\`, \`error_log.resolve\`, \`error_log.supersede\` | List active, acknowledged, resolved, or superseded product error logs and let a human acknowledge, resolve, or supersede stale errors with evidence links. | Tenant | \`{{cli}} error list --resolved active --json\`; \`{{cli}} error resolve --error-log-id <id> --reason "Fixed in PR #123"\` |
 | \`{{cli}} sync brief|compile|complete\` | \`sync.brief.get\`, \`sync.brief.compile\`, \`sync.run.complete\` | Compile, read, and complete a weekly Sync. | Tenant | \`{{cli}} sync brief --json\` |
-| \`{{cli}} runner list|status|diagnose|repair|work-orders|revoke|serve\` | \`runner.list\`, \`runner.status\`, \`runner.diagnose\`, \`runner.repair\`, \`work_order.list\`, \`runner.revoke\`, runner endpoint APIs | Inspect runners and work orders, diagnose offline runners, get repair guidance, revoke a runner, or run the headless local runner loop. | Tenant | \`{{cli}} runner diagnose --runner-id <id> --json\`; \`{{cli}} runner serve --once\` |
+| \`{{cli}} runner list|status|diagnose|repair|work-orders|revoke|serve\` | \`runner.list\`, \`runner.status\`, \`runner.diagnose\`, \`runner.repair\`, \`work_order.list\`, \`runner.revoke\`, runner endpoint APIs | Inspect heartbeat and execute-readiness evidence, inspect work orders, diagnose offline runners, get repair guidance, revoke a runner, or run the headless local runner loop. | Tenant | \`{{cli}} runner diagnose --runner-id <id> --json\`; \`{{cli}} runner serve --once\` |
 | \`{{cli}} notification settings|test|errors\` | \`notification.settings.get\`, \`notification.test\`, \`notification.list_errors\` | Read notification settings, send a test, and list failed deliveries with linked product error source, seat id, and run id when available. | Tenant | \`{{cli}} notification errors --limit 10 --json\` |
 | \`{{cli}} integration list|readiness|status|test\` | \`integration.list\`, \`integration.readiness\`, \`integration.status\`, \`integration.test\` | List connector metadata, read the setup-readiness checklist, read one connector's health, and run the provider-specific connection test without exposing credentials. | Tenant | \`{{cli}} integration readiness --provider google --json\` |
 | \`{{cli}} system health\` | \`system.health\` | Read the scoped system-health snapshot across agent runs, unresolved errors, Signals, Cascade setup, work loop, integrations, runners, notifications, and Sync Brief readiness. | Tenant, member, or seat token | \`{{cli}} system health --json\`; \`{{cli}} system health --seat <id> --json\` |
@@ -43007,8 +43009,8 @@ Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`
 | \`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. |
 | \`rost_list_mcp_tokens\` | \`mcp_token.list\` | List MCP token metadata (never token material). | Tenant | Call with \`{}\` or \`{"include_revoked":true}\`. |
-| \`rost_list_runners\` | \`runner.list\` | List local runners and their online/offline/revoked state. | Tenant | Call with \`{}\`. |
-| \`rost_runner_status\` | \`runner.status\` | Read a single runner's capability and state. | Tenant | Call with \`runner_id\`. |
+| \`rost_list_runners\` | \`runner.list\` | List local runners with heartbeat health, execution readiness, queue counts, and recent result evidence. | Tenant | Call with \`{}\`. |
+| \`rost_runner_status\` | \`runner.status\` | Read a single runner's capability, heartbeat health, and execute-readiness state. | Tenant | Call with \`runner_id\`. |
 | \`rost_diagnose_runner\` | \`runner.diagnose\` | Return runner health, capabilities, and repair guidance without secrets. | Tenant | Call with \`runner_id\`; actionable repair guidance exposes restart, re-pair, or missing CLI steps. |
 | \`rost_runner_repair_guidance\` | \`runner.repair\` | Return focused repair steps for a runner: restart, re-pair, revoke stale, or install missing CLI runtime. | Tenant | Call with \`runner_id\` and optional \`issue\` (restart, re_pair, revoke_stale, missing_cli_runtime). |
 | \`rost_start_runner_pairing\` | \`runner.pairing.start\` | Open a runner pairing session and return the human pairing code. | Tenant-admin | Call with \`name\` and \`platform\`; owner/admin only. |
@@ -43554,7 +43556,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-28.1",
+    version: "2026-06-30.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -43614,7 +43616,7 @@ On \`/cascade\`, the screen renders the full goal depth, not just one or two lev
 
 ## Goal progress and at-risk goals
 
-A goal can carry a quantified progress (0-100) distinct from its on/off/done status. Report it with \`goal.set_progress\`; when an agent reports progress it lands as a proposal a human approves before the goal moves. \`goal.list_at_risk\` projects which goals are off pace by comparing progress against the elapsed fraction of the cycle window (deterministic date math, no forecast model). Off-pace goals surface on \`/cascade\`, on the owner home, in the weekly Sync Brief, and as a weekly owner alert. Status-only goals (no progress recorded) are simply excluded from the projection.
+A goal can carry a quantified progress (0-100) distinct from its on/off/done status. Report it with \`goal.set_progress\`; when an agent reports progress it lands as a proposal a human approves before the goal moves. \`goal.list_at_risk\` projects which goals are off pace by comparing progress against the elapsed fraction of the cycle window (deterministic date math, no forecast model). Off-pace goals surface on \`/cascade\`, on the owner home, in the weekly Sync Brief, and as a weekly owner alert. Status-only goals (no progress recorded) are excluded from the projection and render as pending measurement, not as proven on track.
 
 On human and function seat pages, goal visibility includes both direct goals and descendant seat goals from the Responsibility Graph subtree, so a manager can review team progress without double-owning the agent's work.
 
@@ -43709,7 +43711,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-20.1",
+    version: "2026-06-29.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -44076,7 +44078,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-21.1",
+    version: "2026-06-30.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -44105,10 +44107,10 @@ The local runner is for human-controlled local agent work. It should retrieve {{
 ## Inspect and control runners from CLI or MCP
 
 - Pair a new runner: \`runner.pairing.start\` / \`rost_start_runner_pairing\` with \`name\` and \`platform\` returns a human pairing code. This is owner/admin-only because it mints a short-lived runner pairing session that leads to machine credentials.
-- 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.
+- Inspect: \`{{cli}} runner list --json\` / \`runner.list\` / \`rost_list_runners\` shows heartbeat state plus execution readiness. A runner is execute-ready only when it has a live heartbeat, a detected local Claude or Codex runtime, and recent claim/result evidence or active queue processing. \`{{cli}} runner status\` / \`runner.status\` / \`rost_runner_status\` reads one runner with the same execution detail, due queue count, claimed/running counts, and recent result timestamps.
 - Diagnose (DER-949): \`{{cli}} runner diagnose --runner-id <id>\` / \`runner.diagnose\` / \`rost_diagnose_runner\` returns health, capabilities, and repair guidance without exposing secrets. Use when a runner is offline or stale to get actionable next steps.
 - Repair steps (DER-949): \`{{cli}} runner repair --runner-id <id> [--issue restart|re_pair|revoke_stale|missing_cli_runtime]\` / \`runner.repair\` / \`rost_repair_runner\` returns focused repair instructions. The optional \`issue\` flag narrows to a specific kind of repair (restart the app, re-pair, revoke a stale runner, or install a missing CLI runtime).
-- 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\`.
+- 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\`. The operator Settings page mirrors queued, claimed, running, and recent completed runner evidence so online does not imply can execute.
 - Revoke: \`{{cli}} runner revoke\` / \`runner.revoke\` / \`rost_revoke_runner\` so a runner can no longer authenticate.
 
 ## Owner-initiated headless pairing
@@ -44120,6 +44122,7 @@ Use this flow when a headless or desktop runner cannot use the interactive web c
 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.
+6. For a local smoke, run the headless runner in explicit one-shot execute mode: \`RUNNER_EXECUTE=1 RUNNER_ONCE=1 node apps/runner/scripts/headless-runner.mjs\`. It heartbeats once, claims at most one due read-only work order, reports the result, and exits nonzero if no executable work was claimed or result reporting failed. Without \`RUNNER_ONCE=1\`, the headless runner stays alive and continues heartbeating.
 
 ## When to stop for confirmation
 
@@ -44244,7 +44247,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-20.1",
+    version: "2026-06-29.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing", "operating_rhythm"],
@@ -44283,6 +44286,7 @@ Before calling a command that changes state, discover its exact shape so you do
 - Escalations are aging: read \`escalation.list\` / \`rost_list_escalations\`; a human resolves through the Steward queue.
 - MCP access fails: revoke and recreate the narrowest token after checking scope (\`mcp_token.revoke\` then \`{{cli}} mcp install --client <client> --scope seat --seat-id <seat-id>\`; standalone \`mcp install\` requires an explicit \`--scope\`).
 - Settings section unavailable: keep the route open, read which section is marked unavailable, and retry or fix that source directly. Do not treat a missing Settings panel as permission to write blind values; budget and Sync Brief settings stay read-only until their data loads.
+- Org-intake upload failed: read the safe parse status and reason, then ask the human for a better source file or continue by chat. Browser org intake accepts bounded CSV, text, PDF, DOCX, XLSX, PNG, and JPEG files; extraction failures are retryable and should not be worked around by pasting raw binary, stack traces, secrets, or full customer exports into a prompt.
 
 ## Surface-specific failures
 
@@ -44296,7 +44300,7 @@ Before calling a command that changes state, discover its exact shape so you do
 
 These are the common blockers when adding an agent (see the add-agents guide and the custom agents guide):
 
-- Missing Steward: an agent occupancy or go-live is blocked because no Steward chain resolves to a human. Name a human Steward on the seat, then retry. The no-orphan-agent rule is enforced server-side; do not route around it.
+- Missing Steward: an agent occupancy or go-live is blocked because no Steward chain resolves to a human. Use the inline steward-chain fix when the builder offers a human-occupied candidate, or name a human Steward on the seat, then retry. The no-orphan-agent rule is enforced server-side; do not route around it.
 - Failed dry run: the draft is kept and the failure reason is shown. Read it with \`agent.status\` / \`rost_get_agent_status\`, fix the Charter, manifest, or tool decision, then \`agent.run_dry_run\` again. A passed dry run is required before go-live.
 - Declined tool: declining a proposed tool updates the permission manifest and the dry-run task. If the agent then cannot complete the task, either grant a narrower tool or adjust the Charter so the work still routes safely or escalates.
 - Expired confirmation: a pending human gate expired before approval. Re-issue the gated command (for example \`agent.create_from_template\`, \`charter.sign_manifest\`, or \`agent.go_live\`) and approve the new confirmation; an agent never approves its own request.
@@ -44316,7 +44320,7 @@ Name the failing surface, collect evidence, recommend the smallest correction, a
     order: 78,
     title: "AI model data handling guide",
     summary: "How {{brand}} cloud agents, local MCP sessions, runners, BYOK, and connected tools handle model-bound data.",
-    version: "2026-06-22.1",
+    version: "2026-06-29.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing", "operating_rhythm"],
@@ -44341,27 +44345,27 @@ Name the failing surface, collect evidence, recommend the smallest correction, a
       {
         label: "OpenAI API data controls",
         url: "https://developers.openai.com/api/docs/guides/your-data",
-        note: "Official API data-use and retention controls verified 2026-06-22."
+        note: "Official API data-use and retention controls verified 2026-06-29."
       },
       {
         label: "OpenAI enterprise privacy",
         url: "https://openai.com/enterprise-privacy/",
-        note: "Official enterprise privacy and API retention summary verified 2026-06-22."
+        note: "Official enterprise privacy and API retention summary verified 2026-06-29."
       },
       {
         label: "OpenAI Codex with ChatGPT plan",
         url: "https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan",
-        note: "Official Codex plan data-control scope verified 2026-06-22."
+        note: "Official Codex plan data-control scope verified 2026-06-29."
       },
       {
         label: "Anthropic API and data retention",
         url: "https://platform.claude.com/docs/en/manage-claude/api-and-data-retention",
-        note: "Official Claude API ZDR, HIPAA, and retention scope verified 2026-06-22."
+        note: "Official Claude API ZDR, HIPAA, and retention scope verified 2026-06-29."
       },
       {
         label: "Claude Code data usage",
         url: "https://code.claude.com/docs/en/data-usage",
-        note: "Official local Claude Code data-flow, training, and retention summary verified 2026-06-22."
+        note: "Official local Claude Code data-flow, training, and retention summary verified 2026-06-29."
       },
       {
         label: "Reference corpus and docs spec",
@@ -44464,9 +44468,9 @@ If sensitive data appears by accident, stop, do not repeat it, and route cleanup
 
 ## Provider policy checkpoints
 
-For platform-managed \`cloud\` runs and BYOK Anthropic \`cloud\` runs, check the Anthropic account, workspace, model, and contract. As of 2026-06-22, official Anthropic Claude API documentation says retained API data is not used for model training without express permission, that some API features are ZDR-eligible while others are not, and that ZDR, HIPAA readiness, model-specific retention requirements, consumer products, Claude Code, and third-party integrations each have their own scope.
+For platform-managed \`cloud\` runs and BYOK Anthropic \`cloud\` runs, check the Anthropic account, workspace, model, and contract. As of 2026-06-29, official Anthropic Claude API documentation says retained API data is not used for model training without express permission, that some API features are ZDR-eligible while others are not, and that ZDR, HIPAA readiness, model-specific retention requirements, consumer products, Claude Code, and third-party integrations each have their own scope.
 
-For local OpenAI API-key clients running through \`mcp_session\` or \`runner\`, check the customer's OpenAI organization, project, endpoint, and API data controls. As of 2026-06-22, official OpenAI API documentation says API data is not used to train or improve OpenAI models unless the customer explicitly opts in, and default abuse-monitoring logs may retain customer content for up to 30 days unless approved controls apply. OpenAI says zero data retention is available only for eligible customers, endpoints, and use cases.
+For local OpenAI API-key clients running through \`mcp_session\` or \`runner\`, check the customer's OpenAI organization, project, endpoint, and API data controls. As of 2026-06-29, official OpenAI API documentation says API data is not used to train or improve OpenAI models unless the customer explicitly opts in, and default abuse-monitoring logs may retain customer content for up to 30 days unless approved controls apply. OpenAI says zero data retention is available only for eligible customers, endpoints, and use cases.
 
 For Codex specifically, first identify whether the operator is using Codex through a ChatGPT Free/Plus/Pro, Business, Enterprise, Edu, API, or other workspace path. Official OpenAI Codex help says ChatGPT training data controls apply to whether content processed through Codex may be used to improve OpenAI models when Codex is used with a ChatGPT plan, and that Pro and Plus conversations may be used unless training is disabled. Do not give a Codex user the OpenAI API answer unless they are actually using an API-governed Codex path.
 
@@ -44490,7 +44494,7 @@ When asked about AI data handling:
     order: 79,
     title: "Security model guide",
     summary: "How {{brand}} protects tenant data, credentials, tool calls, and human decisions across web, MCP, CLI, and agents.",
-    version: "2026-06-21.5",
+    version: "2026-06-29.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing", "operating_rhythm"],
@@ -44921,7 +44925,7 @@ This worked document **omits** \`unanswered_boundaries\` and \`seat_type_recomme
     order: 43,
     title: "Agent builder guide",
     summary: "The full agent setup sequence on the CLI/MCP path \u2014 seat, steward, job, boundaries, tools, credentials, model, schedule, dry-run, go-live \u2014 with the structured model config and access tiers.",
-    version: "2026-06-20.2",
+    version: "2026-06-29.1",
     public: true,
     audiences: ["cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -44969,13 +44973,15 @@ Building teams of controlled agent workers is the product's core differentiator.
 3. **Job** \u2014 what the seat owns. On \`agent.create_custom\` this is the operational answers (what it owns, what success looks like, what it must never do alone); for a strong contract, submit the full Charter directly via \`charter.update_draft\` (see the charter-authoring deep-dive).
 4. **Boundaries** \u2014 the Charter's \`decision_authority\` (can-do / must-ask / never / escalate), \`escalation_rules\`, and \`budget\`. Conservative by default: send/spend/irreversible actions are approval-gated or escalated.
 5. **Tools** \u2014 pick from the discoverable catalog (\`{{cli}} tools list\`); each tool has a default scope tier and access policy. Connect or decline via \`agent.configure_tools\`. Selecting a tool records permission; live handlers execute later only behind the signed manifest, server guard, required credential or binding, and connector-specific approval boundary.
-6. **Credentials** \u2014 a tool that needs access declares a credential-ingress request (provider, scope, secret name). The secret itself flows through the vault-backed ingress command as a vault ref \u2014 never paste a secret into a builder command.
+6. **Credentials and provider readiness** \u2014 a tool that needs access declares a credential-ingress request (provider, scope, secret name). The secret itself flows through the vault-backed ingress command as a vault ref \u2014 never paste a secret into a builder command. For Google-backed tools, inspect the provider readiness shown in Settings or the builder: not connected, connected but untested, connected and tested, or failed. Use \`integration.test\` / \`rost_test_integration_connection\` or the builder Test connection action to refresh the same safe status facts; do not infer authorization from a connected credential.
 7. **Operating instructions** \u2014 the runtime composes the agent's context from its Charter; you do not write a system prompt.
 8. **Model** \u2014 select the structured model config (see below). Read \`{{cli}} model list\` / \`model.catalog\` first when you are unsure; it returns the recommended default, effort, token price estimates, cost band, and best-fit work for each tier. If \`agent.create_custom\` omits \`model_config\`, {{brand}} recommends a tier from the supplied responsibility answers.
 9. **Heartbeat** \u2014 set the schedule (\`schedule_cron\`) for a recurring agent; a live scheduled agent must keep a steward chain.
 10. **Dry-run** \u2014 \`agent.run_dry_run\` rehearses in sandbox after the manifest is signed; it is ungated by human approval but requires a signed manifest.
 11. **Go-live** \u2014 \`agent.go_live\` is \`human_required\`. Prepare everything and surface the go-live to a human; never go live on a human's behalf.
 
+If \`agent_setup.get\` returns \`next_action: "set_steward"\`, use the returned steward-remediation candidates or choose an existing human-occupied seat with \`agent_setup.update --json '{"seat_id":"<agent-seat-id>","steward_seat_id":"<human-seat-id>"}'\`. If no human-occupied candidate exists, create or staff a human seat first. Do not bypass the no-orphan-agent guard; go-live remains blocked until the chain resolves to a person.
+
 ## Choosing the model (structured config)
 
 The agent's model is a structured object, not a bare string:
@@ -47611,7 +47617,7 @@ function formatSystemHealth(output) {
     `signals: off_track=${field(signals, "off_track_count")} pending=${field(signals, "pending_count")}`,
     `cascade: recommendations=${field(cascade, "recommendation_count")} warnings=${field(cascade, "warning_count")}`,
     `work_loop: open_issues=${field(workLoop, "open_issue_count")} friction_without_task=${field(workLoop, "friction_without_task_count")} open_or_stalled_tasks=${field(workLoop, "open_or_stalled_task_count")}`,
-    `connectivity: runners=${field(connectivity, "runner_count")} offline_runners=${field(connectivity, "offline_runner_count")} integrations=${field(connectivity, "integration_count")} disconnected_integrations=${field(connectivity, "disconnected_integration_count")} failed_notifications=${field(connectivity, "failed_notification_count")}`,
+    `connectivity: runners=${field(connectivity, "runner_count")} offline_runners=${field(connectivity, "offline_runner_count")} not_ready_runners=${field(connectivity, "not_execute_ready_runner_count")} integrations=${field(connectivity, "integration_count")} disconnected_integrations=${field(connectivity, "disconnected_integration_count")} failed_notifications=${field(connectivity, "failed_notification_count")}`,
     `sync: latest_brief=${field(sync, "latest_brief_at")} missing_latest_brief=${field(sync, "missing_latest_brief")} flagged_gaps=${field(sync, "flagged_gap_count")}`
   );
   return lines.join("\n");
@@ -47754,25 +47760,48 @@ function signupUrl(appUrl2) {
   return new URL("/signup", ensureTrailingSlash2(appUrl2)).toString();
 }
 function parseSignupCompany(args) {
+  const json2 = args.includes("--json");
   const index = args.indexOf("--company");
   if (index === -1) {
-    return { companyName: null };
+    return { companyName: null, json: json2 };
   }
   const value = args[index + 1];
   if (value === void 0 || value.startsWith("--") || value.trim() === "") {
     throw new Error(`--company requires a value, e.g. ${cliBrand.binName} signup --company "Acme"`);
   }
-  return { companyName: value };
+  return { companyName: value, json: json2 };
 }
-async function runSignupProvision(io, client, companyName, run2) {
+var signupProvisionOutputSchema = external_exports.object({
+  tenant_id: external_exports.string().min(1),
+  slug: external_exports.string().min(1),
+  name: external_exports.string().min(1),
+  created: external_exports.boolean()
+}).loose();
+async function runSignupProvision(io, client, companyName, run2, options = {}) {
   const exitCode = await run2(io, client, "signup.provision_tenant", { company_name: companyName });
-  if (exitCode === 0) {
+  if (exitCode.exitCode === 0) {
+    const parsed = signupProvisionOutputSchema.safeParse(exitCode.output);
+    if (!parsed.success) {
+      return exitCode.exitCode;
+    }
+    if (options.json === true) {
+      io.stdout.write(`${JSON.stringify(parsed.data, null, 2)}
+`);
+      return exitCode.exitCode;
+    }
+    if (!parsed.data.created) {
+      io.stdout.write(
+        `No new company was created. Your account already has active company '${parsed.data.name}' (${parsed.data.slug}); requested '${companyName}' was not provisioned. Run '${cliBrand.binName} tenants' to see companies or '${cliBrand.binName} use ${parsed.data.slug}' to keep working there.
+`
+      );
+      return exitCode.exitCode;
+    }
     io.stdout.write(
-      `Company '${companyName}' is ready and active. Run '${cliBrand.binName} onboard status' to continue setup.
+      `Company '${parsed.data.name}' is ready and active. Run '${cliBrand.binName} onboard status' to continue setup.
 `
     );
   }
-  return exitCode;
+  return exitCode.exitCode;
 }
 async function runSignup(io, appUrl2, openBrowser2 = tryOpenBrowser) {
   const url2 = signupUrl(appUrl2);
@@ -48717,9 +48746,12 @@ async function main(argv = process.argv.slice(2), options = {}) {
     return 0;
   }
   let signupCompany = null;
+  let signupJson = false;
   if (command === "signup") {
     try {
-      signupCompany = parseSignupCompany(args).companyName;
+      const signupOptions = parseSignupCompany(args);
+      signupCompany = signupOptions.companyName;
+      signupJson = signupOptions.json;
     } catch (error51) {
       io.stderr.write(`${redactForLog(error51 instanceof Error ? error51.message : String(error51))}
 `);
@@ -48826,7 +48858,7 @@ Run ${cliBrand.binName} login --device again if the next command asks you to aut
     await maybePrintSignupBootstrap(io, client, config2.appUrl);
   }
   if (command === "signup") {
-    return runSignupProvision(io, client, signupCompany, (signupIo, signupClient, commandId, body) => printCommandOutput(signupIo, signupClient, commandId, body));
+    return runSignupProvision(io, client, signupCompany, (signupIo, signupClient, commandId, body) => executeCommandWithResult(signupIo, signupClient, commandId, body), { json: signupJson });
   }
   if (command === "whoami") {
     return printCommandOutput(io, client, "user.whoami");
@@ -49159,6 +49191,14 @@ async function printCommandOutput(io, client, commandId, body = {}, format, opti
     return printCommandError2(io, error51);
   }
 }
+async function executeCommandWithResult(io, client, commandId, body = {}) {
+  try {
+    const result = await client.execute(commandId, body);
+    return { exitCode: 0, output: result.output };
+  } catch (error51) {
+    return { exitCode: printCommandError2(io, error51) };
+  }
+}
 function pendingConfirmationFromError2(error51) {
   if (!(error51 instanceof CommandClientError) || !error51.response || error51.response.ok || error51.response.error.code !== "COMMAND_CONFIRMATION_REQUIRED") {
     return null;