@rosthq/cli 0.5.30 → 0.5.32

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,CAmPnG;AA6cD,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,CAuPnG;AA+cD,wBAAgB,eAAe,CAAC,SAAS,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,GAAG,SAAS,GAAG,OAAO,CAUxF"}

package/dist/index.js

@@ -41637,7 +41637,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-20.2",
+    version: "2026-06-30.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["graph_design", "staffing"],
@@ -41684,6 +41684,8 @@ 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.
 
+Seat cards name their active occupants. When a seat has more than one occupant, the card shows the human/agent breakdown instead of only a count, and mixed human-plus-agent staffing is labelled. Use the occupants control on that card to open the detail panel, where each occupant is listed as either the human accountable for the seat or the agent executor, with the Steward chain shown for agent accountability.
+
 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.
@@ -41758,7 +41760,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-29.1",
+    version: "2026-06-30.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["charter_design", "staffing"],
@@ -41815,7 +41817,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 +42075,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 +42123,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.
 
@@ -42146,7 +42150,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-27.1",
+    version: "2026-06-30.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -42244,7 +42248,7 @@ Beyond each seat's own manifest, the company can set one ceiling on how much an
 
 ## What humans should review
 
-The Agents page shows fleet health first: live state, recent runs, failed runs, open held actions, last activity, cost, and the next operator action. It also shows configuration completeness for each staffed agent seat: Steward chain, lane or runtime substrate, vaulted credentials, granted tools, model config, sandbox dry run, and go-live state, each with a remediation link when incomplete. A seat's Trust Card drills into the same facts: run history, one-run detail, tool-call outcomes, product-visible errors, transcript references, loaded Skill versions, and held confirmations or escalations. Open confirmations stay visible until they are decided or expire, even when they are older than the default activity window. Approving or rejecting a held confirmation from the seat page is scoped to that seat; rejection can include a short reason.
+The Agents page shows fleet health first: live state, work evidence, failed runs, open held actions, cost, and the next operator action. Work evidence distinguishes fresh real runs, stale runs, no completed run yet, queued or running work orders, and recent failures. A failure link opens the failed run itself; queued or stale rows route the operator to the seat's agent operations instead of pretending there is a hidden run to inspect. The page also shows configuration completeness for each staffed agent seat: Steward chain, lane or runtime substrate, vaulted credentials, granted tools, model config, sandbox dry run, and go-live state, each with a remediation link when incomplete. A seat's Trust Card drills into the same facts: run history, one-run detail, tool-call outcomes, product-visible errors, transcript references, loaded Skill versions, and held confirmations or escalations. Open confirmations stay visible until they are decided or expire, even when they are older than the default activity window. Approving or rejecting a held confirmation from the seat page is scoped to that seat; rejection can include a short reason. For a live agent, the seat page's agent operations panel can queue one immediate governed run through the same \`agent.run_now\` command path used by CLI and MCP; it does not expand authority or change the saved schedule.
 
 Review the first dry runs, fleet overview, tool-call audit rows, escalations, deliverables, and Signal impact. A seat's completed-work area combines explicit deliverables, work-log evidence, and successful run summaries into one operator-facing trail with safe links labelled as internal, Linear, GitHub, or external. The fleet view at \`/agents\` shows every staffed agent seat at a glance; the agent-native equivalents are \`{{cli}} command agent.list_fleet --json '{}'\` / \`rost_list_agent_fleet\` for the compact overview, and \`{{cli}} agent fleet-digest --json\` / \`agent.fleet_digest\` / \`rost_get_dogfood_fleet_health_digest\` for the daily dogfood evidence bundle. The digest returns live/idle state, 24h/7d turns, 7d/30d spend, recent failed runs, unresolved product errors, failed notifications, and a next action per seat.
 
@@ -42399,7 +42403,7 @@ External connectors are being rolled out provider by provider, conservatively (r
     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-30.1",
+    version: "2026-06-30.3",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -42522,9 +42526,10 @@ 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>"\`. 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.
+- **Headless first company (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.
+- **Additional entitled company:** from an existing active company session, run \`{{cli}} tenant create --company "<name>" [--json]\`. This creates a clean additional company only when the account has an active \`tenant.create.additional\` entitlement. A denied attempt returns a clean refusal and creates no tenant row.
 
-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.
+If you run a tenant-scoped command before any company exists, the CLI tells you both first-company 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>\`.
 
 ## Install the CLI
 
@@ -42602,10 +42607,11 @@ This is the install/auth quickstart \u2014 it gets you logged in, MCP registered
 3. Create your company if you have none yet: \`{{cli}} signup --company "<name>"\` (no browser step)
 4. List tenants: \`{{cli}} tenants\`
 5. Select a tenant when needed: \`{{cli}} use <tenant-slug-or-id>\`
-6. Read the agent map: \`{{cli}} reference get agent-reference-map\` (the full canonical setup order lives here)
-7. Register MCP for the client (pick a scope \u2014 \`--scope\` is required): \`{{cli}} mcp install --client claude-code --scope tenant-admin\` for setup, or \`--scope seat --seat-id <id>\` for a narrower seat token
-8. Inspect onboarding: \`{{cli}} onboard status\`
-9. Get the guided agent prompt: \`{{cli}} onboard run\`
+6. For an entitled additional clean company, create it from an active company session: \`{{cli}} tenant create --company "<name>"\`
+7. Read the agent map: \`{{cli}} reference get agent-reference-map\` (the full canonical setup order lives here)
+8. Register MCP for the client (pick a scope \u2014 \`--scope\` is required): \`{{cli}} mcp install --client claude-code --scope tenant-admin\` for setup, or \`--scope seat --seat-id <id>\` for a narrower seat token
+9. Inspect onboarding: \`{{cli}} onboard status\`
+10. Get the guided agent prompt: \`{{cli}} onboard run\`
 
 Or use the one-shot helper: \`{{cli}} init\` logs in when needed, optionally selects a tenant, installs MCP, and prints the onboarding prompt. It does not run every numbered step above (it does not create your company or call \`onboard status\`) \u2014 it gets you logged in, registered, and handed the onboarding prompt. As the first-run helper it defaults to a **tenant-admin** token (no seats exist yet), so unlike a direct \`mcp install\` it does not need \`--scope\`; pass \`--scope seat --seat-id <id>\` if you already have a seat to scope it to:
 
@@ -42789,6 +42795,7 @@ These are the security posture rules for operating after install \u2014 a checkl
 | \`{{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>"] [--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}} tenant create --company "<name>" [--json]\` | Create an additional clean company from an existing active company session. Requires \`tenant.create.additional\`; denied attempts create no tenant. Add \`--json\` for machine-readable output. | Logged-in tenant owner with entitlement | \`{{cli}} tenant create --company "Acme East"\` |
 | \`{{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 +42855,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 +43014,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 +43561,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 +43621,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.
 
@@ -44076,7 +44083,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 +44112,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 +44127,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
 
@@ -47614,7 +47622,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");
@@ -47774,6 +47782,13 @@ var signupProvisionOutputSchema = external_exports.object({
   name: external_exports.string().min(1),
   created: external_exports.boolean()
 }).loose();
+var tenantCreateOutputSchema = signupProvisionOutputSchema.extend({
+  source_tenant_id: external_exports.string().min(1),
+  entitlement_id: external_exports.string().min(1),
+  accounting_event_id: external_exports.string().min(1),
+  active: external_exports.boolean(),
+  next_action: external_exports.string().min(1)
+}).loose();
 async function runSignupProvision(io, client, companyName, run2, options = {}) {
   const exitCode = await run2(io, client, "signup.provision_tenant", { company_name: companyName });
   if (exitCode.exitCode === 0) {
@@ -47800,6 +47815,40 @@ async function runSignupProvision(io, client, companyName, run2, options = {}) {
   }
   return exitCode.exitCode;
 }
+async function runTenantCreate(io, client, args, run2) {
+  const [action, ...rest] = args;
+  if (action !== "create") {
+    io.stderr.write(`Usage: ${cliBrand.binName} tenant create --company "<name>" [--json]
+`);
+    return 1;
+  }
+  const json2 = rest.includes("--json");
+  const companyIndex = rest.indexOf("--company");
+  const companyName = companyIndex === -1 ? void 0 : rest[companyIndex + 1];
+  if (!companyName || companyName.startsWith("--") || companyName.trim() === "") {
+    io.stderr.write(`--company requires a value, e.g. ${cliBrand.binName} tenant create --company "Acme Ops"
+`);
+    return 1;
+  }
+  const exitCode = await run2(io, client, "tenant.create", { company_name: companyName });
+  if (exitCode.exitCode === 0) {
+    const parsed = tenantCreateOutputSchema.safeParse(exitCode.output);
+    if (!parsed.success) {
+      io.stderr.write("tenant.create returned an unexpected response shape.\n");
+      return 1;
+    }
+    if (json2) {
+      io.stdout.write(`${JSON.stringify(parsed.data, null, 2)}
+`);
+      return exitCode.exitCode;
+    }
+    io.stdout.write(
+      `Company '${parsed.data.name}' is ready and active (${parsed.data.slug}). ${parsed.data.next_action}
+`
+    );
+  }
+  return exitCode.exitCode;
+}
 async function runSignup(io, appUrl2, openBrowser2 = tryOpenBrowser) {
   const url2 = signupUrl(appUrl2);
   await openBrowser2(url2);
@@ -48857,6 +48906,9 @@ Run ${cliBrand.binName} login --device again if the next command asks you to aut
   if (command === "signup") {
     return runSignupProvision(io, client, signupCompany, (signupIo, signupClient, commandId, body) => executeCommandWithResult(signupIo, signupClient, commandId, body), { json: signupJson });
   }
+  if (command === "tenant") {
+    return runTenantCreate(io, client, args, (tenantIo, tenantClient, commandId, body) => executeCommandWithResult(tenantIo, tenantClient, commandId, body));
+  }
   if (command === "whoami") {
     return printCommandOutput(io, client, "user.whoami");
   }
@@ -49253,7 +49305,7 @@ function parseJsonBody(args) {
   return JSON.parse(body);
 }
 function isCommand(value) {
-  return value === "login" || value === "logout" || value === "signup" || value === "whoami" || value === "tenants" || value === "use" || value === "command" || value === "onboard" || value === "mcp" || value === "skills" || value === "init" || value === "docs" || value === "reference" || value === "doctor" || value === "help";
+  return value === "login" || value === "logout" || value === "signup" || value === "tenant" || value === "whoami" || value === "tenants" || value === "use" || value === "command" || value === "onboard" || value === "mcp" || value === "skills" || value === "init" || value === "docs" || value === "reference" || value === "doctor" || value === "help";
 }
 function printUsage(io) {
   io.stdout.write([
@@ -49261,6 +49313,7 @@ function printUsage(io) {
     `${cliBrand.binName} login --device`,
     `${cliBrand.binName} logout`,
     `${cliBrand.binName} signup [--company "<name>"]`,
+    `${cliBrand.binName} tenant create --company "<name>" [--json]`,
     `${cliBrand.binName} whoami`,
     `${cliBrand.binName} tenants`,
     `${cliBrand.binName} use <tenant>`,