@rosthq/cli 0.5.30 → 0.5.31

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-29.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.
 
@@ -42399,7 +42401,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.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -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.
 
@@ -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
 
@@ -47614,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");