@rosthq/cli 0.7.153 → 0.7.154

package/dist/index.js

@@ -54336,7 +54336,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-08-04.1",
+    version: "2026-08-04.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -54973,7 +54973,7 @@ The signed-in app exposes the same Skill command surface at **Skills**, linked f
 | \`{{cli}} deliverable list|get|create|attach\` | \`deliverable.list\`, \`deliverable.get\`, \`deliverable.create\`, \`deliverable.attach\` | List, get, create, or attach agent deliverables for a seat. Deliverables are durable work outputs visible across UI, CLI, and MCP. | Tenant (list/get), Seat (create/attach) | \`{{cli}} deliverable list --seat-id <id> --json\`; \`{{cli}} deliverable create --title "Brief" --kind brief\` |
 | \`{{cli}} graph show\` | \`graph.get\` | Print a table view of the Responsibility Graph with explicit \`seat_id\` and \`parent_seat_id\` columns. | Tenant | \`{{cli}} graph show\` |
 | \`{{cli}} seat list|get|create|create-complete|rename|reparent|decommission\` | \`graph.get\`, \`seat.get\`, \`seat.create\`, \`seat.create_complete\`, \`seat.rename\`, \`seat.reparent\`, \`seat.decommission\`, \`seat.decommission_preview\` | Work with seats as first-class CLI primitives. The existing \`{{cli}} seat list|get|create|rename|reparent|decommission\` help surface remains available. \`seat create-complete --input '<json>'\` stages one atomic complete-Seat proposal and stops at one owner confirmation; any agent remains dry-run. \`seat decommission --dry-run\` previews affected occupancies, agents, Charters, tokens, credentials, work orders, and schedules before the human-gated teardown. | Tenant / Seat for targeted mutations | \`{{cli}} seat create-complete --schema\`; \`{{cli}} seat decommission --seat-id <id> --dry-run\` |
-| \`{{cli}} forge project-create|project-list|request-create|request-list|request-show|request-pause|request-cancel|request-resume\` | \`software_factory.project.create\`, \`software_factory.project.list\`, \`software_factory.request.create\`, \`software_factory.request.list\`, \`software_factory.request.show\`, \`software_factory.request.pause\`, \`software_factory.request.cancel\`, \`software_factory.request.resume\` | Create/list Forge projects, open/read governed Forge build requests, and control request lifecycle. Request create/list/show return \`scheduler_state\`: \`queued\` when a runner work order exists, \`parked\` when the Forge team is staffed but no paired online runner can claim it, when the owning seat's charter manifest is not signed (\`charter_manifest_not_signed\`), or when the owning seat has no active charter (\`charter_missing\`), and \`not_configured\` when the runner-lane Forge Seat is missing. Request list/show also return a \`failure\` record (what failed, why, and the one action to unblock) when a request is blocked by a fault \u2014 a stalled or crashed phase driver, a failed phase, an incomplete plan, an exhausted budget, or missing/unsigned charter authority \u2014 so a stopped build reads as failed with a retry or fix-and-resume action instead of an indefinite running state. Request detail also surfaces the signed, expiring dispatch preview with included order, held items, dependencies, estimated turns, runner requirements, and authority budget envelope. Parked runner-availability and not-configured states link to \`/settings/runners/setup\`, and runner pairing or the repair sweep re-enqueues the same pending intake idempotently; charter-authority parks (\`charter_manifest_not_signed\`, \`charter_missing\`) carry no runner-setup link and unblock by signing the manifest (\`charter.sign_manifest\`) or restoring an active charter, then resuming the request. Project creation plus pause/cancel/resume are tenant-admin, entitlement-gated, and human-gated; reads and request creation require the Forge add-on. | Tenant / Tenant-admin for create and lifecycle controls | \`{{cli}} forge project-create --name "Leiluna app" --base-branch main\`; \`{{cli}} forge request-create --project <slug-or-name> --title "Add invoice export"\` (accepts \`--software-project-id <id>\` instead of \`--project\` too); \`{{cli}} forge request-pause --build-request-id <id> --reason "Operator hold"\` |
+| \`{{cli}} forge project-create|project-list|request-create|request-list|request-show|request-pause|request-cancel|request-resume\` | \`software_factory.project.create\`, \`software_factory.project.list\`, \`software_factory.request.create\`, \`software_factory.request.list\`, \`software_factory.request.show\`, \`software_factory.request.pause\`, \`software_factory.request.cancel\`, \`software_factory.request.resume\` | Create/list Forge projects, open/read governed Forge build requests, and control request lifecycle. Request create/list/show return \`scheduler_state\`: \`queued\` when a runner work order exists, \`parked\` when the Forge team is staffed but no paired online runner can claim it, when the owning seat's charter manifest is not signed (\`charter_manifest_not_signed\`), or when the owning seat has no active charter (\`charter_missing\`), and \`not_configured\` when the runner-lane Forge Seat is missing. Request list/show also return a \`failure\` record (what failed, why, and the one action to unblock) when a request is blocked by a fault \u2014 a stalled or crashed phase driver, a failed phase, an incomplete plan, an exhausted budget, or missing/unsigned charter authority \u2014 so a stopped build reads as failed with a retry or fix-and-resume action instead of an indefinite running state. Request detail also surfaces the signed, expiring dispatch preview with included order, held items, dependencies, estimated turns, runner requirements, and authority budget envelope. Parked runner-availability and not-configured states link to \`/settings/runners/setup\`, and runner pairing or the repair sweep re-enqueues the same pending intake idempotently; charter-authority parks (\`charter_manifest_not_signed\`, \`charter_missing\`) carry no runner-setup link and unblock by signing the manifest (\`charter.sign_manifest\`) or, when no active charter exists, creating or replacing a draft with \`charter.set\` (or \`charter.draft\` followed by \`charter.update_draft\`), approving it with \`charter.approve\`, and then resuming the request. Project creation plus pause/cancel/resume are tenant-admin, entitlement-gated, and human-gated; reads and request creation require the Forge add-on. | Tenant / Tenant-admin for create and lifecycle controls | \`{{cli}} forge project-create --name "Leiluna app" --base-branch main\`; \`{{cli}} forge request-create --project <slug-or-name> --title "Add invoice export"\` (accepts \`--software-project-id <id>\` instead of \`--project\` too); \`{{cli}} forge request-pause --build-request-id <id> --reason "Operator hold"\` |
 
 Skills wrapper help:
 
@@ -55297,7 +55297,7 @@ Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`
 | \`rost_create_a_forge_vercel_preview_deployment\` | \`software_factory.vercel.deploy_preview\` | Create a Vercel preview deployment for a linked project after Forge deploy-preview authority, the Vercel OAuth vault-ref connection, and required preview secret/config grants are verified. | Tenant | Call with \`{"software_project_id":"<project-id>","commit_sha":"<sha>","git_ref":"feature/example","seat_id":"<seat-id>"}\`; returns deployment metadata, not tokens. |
 | \`rost_list_forge_runner_capacity\` | \`software_factory.capacity.list\` | List Forge runner capacity observations (advisory scheduling input only, never an authority input). Read-only; requires the Forge add-on. | Tenant | Call with \`{}\` or \`{"runner_id":"<runner-id>"}\`. |
 
-The web Forge control room at \`/forge\` uses the same command path for project selection, build request creation/list/detail reads, request pause/cancel/resume controls, runner capacity, configuration status, and Developer Team install. Request cards and detail pages surface \`scheduler_state\` directly: queued work shows its work-order state, parked work explains why it is parked \u2014 no paired online runner is available, the owning seat's charter manifest is not signed (\`charter_manifest_not_signed\`, blocked until the manifest is signed with \`charter.sign_manifest\` and the request is resumed), or the owning seat has no active charter (\`charter_missing\`, blocked until the seat has an active charter and the request is resumed) \u2014 and not-configured work sends the operator to \`/settings/runners/setup\`. A request detail page also shows phase history, open gates, plan progress, loop/time/cost ceilings, and latest plan-review questions from \`software_factory.request.show\`; answering a clarification, approving a plan, rejecting it, pausing, canceling, or resuming calls the same Forge commands exposed over CLI/MCP. Lifecycle controls deliberately stage pending confirmations before changing runner state. The install button also stages a pending confirmation before durable seats, Skills, authority grants, or live agent activation are applied; the install page states plainly that approving activates the 7 agents at a pull-request-only, observe-first posture and surfaces the company autonomy ceiling.
+The web Forge control room at \`/forge\` uses the same command path for project selection, build request creation/list/detail reads, request pause/cancel/resume controls, runner capacity, configuration status, and Developer Team install. Request cards and detail pages surface \`scheduler_state\` directly: queued work shows its work-order state, parked work explains why it is parked \u2014 no paired online runner is available, the owning seat's charter manifest is not signed (\`charter_manifest_not_signed\`, blocked until the manifest is signed with \`charter.sign_manifest\` and the request is resumed), or the owning seat has no active charter (\`charter_missing\`, blocked until a draft is created or replaced with \`charter.set\` (or \`charter.draft\` + \`charter.update_draft\`), approved with \`charter.approve\`, and the request is resumed) \u2014 and not-configured work sends the operator to \`/settings/runners/setup\`. A request detail page also shows phase history, open gates, plan progress, loop/time/cost ceilings, and latest plan-review questions from \`software_factory.request.show\`; answering a clarification, approving a plan, rejecting it, pausing, canceling, or resuming calls the same Forge commands exposed over CLI/MCP. Lifecycle controls deliberately stage pending confirmations before changing runner state. The install button also stages a pending confirmation before durable seats, Skills, authority grants, or live agent activation are applied; the install page states plainly that approving activates the 7 agents at a pull-request-only, observe-first posture and surfaces the company autonomy ceiling.
 
 #### Forge GitHub App access
 
@@ -56709,7 +56709,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-07-20.5",
+    version: "2026-08-03.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -56767,7 +56767,7 @@ AICOS runner chat uses the same runner process but not the scheduled work-order
 
 ## Forge scheduler work
 
-When the Forge add-on is enabled, Forge phase work uses the same runner work-order lane and the same shared agent-readiness projection as ordinary production work. A Forge phase is linked to a normal \`work_orders\` row only when its owning runner agent is \`execution_ready\` and the projection selects a compatible paired Runner. Otherwise the phase stays pending/parked with a machine-readable reason such as \`agent_not_execution_ready\` or \`runner_not_paired\`; Runner setup remediation points to \`/settings/runners/setup\`, while other readiness reasons must be repaired on the owning agent Seat. Pairing a Runner or the repair sweep re-evaluates readiness and re-enqueues the same pending phase idempotently, so operators do not get duplicate intake rows or silent expiring work orders. Two parked reasons are deliberate exceptions to that re-enqueue: \`charter_manifest_not_signed\` and \`charter_missing\` mean the owning seat's charter authority is missing, and re-enqueueing while unsigned would fail-loop \u2014 they unblock by signing the manifest (\`charter.sign_manifest\`) or restoring an active charter and then resuming the request, which mints a fresh work order. The runner claims queued work, starts it, reports the result, and the server advances the linked phase. There is no separate local lease store.
+When the Forge add-on is enabled, Forge phase work uses the same runner work-order lane and the same shared agent-readiness projection as ordinary production work. A Forge phase is linked to a normal \`work_orders\` row only when its owning runner agent is \`execution_ready\` and the projection selects a compatible paired Runner. Otherwise the phase stays pending/parked with a machine-readable reason such as \`agent_not_execution_ready\` or \`runner_not_paired\`; Runner setup remediation points to \`/settings/runners/setup\`, while other readiness reasons must be repaired on the owning agent Seat. Pairing a Runner or the repair sweep re-evaluates readiness and re-enqueues the same pending phase idempotently, so operators do not get duplicate intake rows or silent expiring work orders. Two parked reasons are deliberate exceptions to that re-enqueue: \`charter_manifest_not_signed\` and \`charter_missing\` mean the owning seat's charter authority is missing, and re-enqueueing while unsigned would fail-loop \u2014 they unblock by signing the manifest (\`charter.sign_manifest\`) or, when no active charter exists, creating or replacing a draft with \`charter.set\` (or \`charter.draft\` followed by \`charter.update_draft\`), approving it with \`charter.approve\`, and then resuming the request, which mints a fresh work order. The runner claims queued work, starts it, reports the result, and the server advances the linked phase. There is no separate local lease store.
 
 A build request decomposes into changesets and tasks tracked as queryable execution state. A changeset is the pull-request boundary and the revert unit (default one per request; additional changesets only on a named split criterion such as risk isolation or a reviewability-size budget). A task is one coding session inside a changeset, carrying its own verification and a per-task checkpoint that is the safe resume and pause boundary. Plan-conformance findings loop a changeset back to implementation; a finding can only be accepted, rather than resolved, through a recorded human decision.