@rosthq/cli 0.5.0 → 0.5.1

package/dist/index.js

@@ -41585,11 +41585,11 @@ 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-13.1",
+    version: "2026-06-17.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["graph_design", "staffing"],
-    relatedCommandIds: ["seat.create", "seat.rename", "seat.reparent", "seat.set_type", "staffing.assign_user", "graph.get", "seat.get", "confirmation.approve", "confirmation.reject"],
+    relatedCommandIds: ["seat.create", "seat.rename", "seat.reparent", "seat.set_type", "seat.decommission", "staffing.assign_user", "graph.get", "seat.get", "confirmation.approve", "confirmation.reject"],
     legal: {
       publicRisk: "low",
       notes: [
@@ -41628,6 +41628,10 @@ Agent creation is a first-class graph action. From a seat in the Responsibility
 
 Each entry opens the same conservative setup flow \u2014 seat placement, Steward, draft Charter, manifest sign-off, sandbox dry run, and human go-live \u2014 with the graph seat prefilled as the parent and its Steward chain offered as the default Steward. In the public read-only demo the control is omitted; it never starts a write you cannot finish.
 
+## Read the graph in the app
+
+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.
+
 ## First-pass structure
 
 Start with the operating root, then major functions, then the few seats that own the most important recurring work. Do not over-model. A graph with eight clear seats is better than a graph with thirty vague boxes.
@@ -41666,9 +41670,19 @@ Then mutate with the smallest change. Create returns the new \`seat_id\`:
 
 Rename, reparent, and set-type take an existing \`seat_id\`. The MCP aliases are \`rost_create_seat\`, \`rost_rename_seat\`, \`rost_reparent_seat\`, \`rost_set_seat_type\`.
 
+## Decommission a seat
+
+Retiring a seat is a single audited action. In the app it is the \`Let go\` control on the seat page; on the CLI/MCP path it is the \`seat.decommission\` command:
+
+\`\`\`bash
+{{cli}} command seat.decommission --json '{"seat_id":"<seat-id>"}'
+\`\`\`
+
+It ends every occupancy, archives the seat's active Charter, revokes the seat's MCP tokens and credentials, cancels any agent schedules, and marks the agent and seat decommissioned with a tombstone event \u2014 one transaction, one audit row. It is \`human_required\` and no-orphan guarded: an interactive human runs it directly; an agent or non-interactive caller is deferred to a human confirmation, and if retiring the seat would leave another live agent without a human Steward chain, the whole change rolls back. To retire only the agent and keep the seat available for re-staffing, use \`agent.decommission\` (the seat-page agent operations panel) instead.
+
 ## When to stop for confirmation
 
-\`seat.create\`, \`seat.rename\`, \`seat.reparent\`, and \`seat.set_type\` are \`human_required\`. Over MCP they return a pending confirmation with an approve link instead of mutating; the human approves with \`confirmation.approve\`. Never approve your own structural change from an agent session \u2014 surface the pending confirmation to a human. See the confirmations guide.
+\`seat.create\`, \`seat.rename\`, \`seat.reparent\`, \`seat.set_type\`, and \`seat.decommission\` are \`human_required\`. Over MCP they return a pending confirmation with an approve link instead of mutating; the human approves with \`confirmation.approve\`. Never approve your own structural change from an agent session \u2014 surface the pending confirmation to a human. When a seat-targeted command does execute, its audit row is scoped to that seat (queryable by \`seat_id\`); on the deferred MCP path the executed audit is recorded against the human's \`confirmation.approve\`. See the confirmations guide.
 
 ## Agent guidance
 
@@ -41880,6 +41894,8 @@ Every mode ends at the same conservative gates, shown at each step:
 
 After creation and after go-live, the flow returns you to the graph with the new agent selected.
 
+Reopening the builder for a seat whose agent is already live shows its live state \u2014 the same active Charter and passed dry run the CLI and MCP report (\`agent.status\`, \`charter.get\`) \u2014 rather than a disabled draft go-live. If you have started a new revision, the builder shows "live charter vN active; draft vN+1 in progress" so the live agent and the amendment-in-flight are both visible. The web, CLI, and MCP surfaces always read the same charter for a seat.
+
 ## If something blocks you
 
 - No valid Steward: the draft is created, but occupancy and go-live stay blocked until a human Steward exists. Add one and continue. Naming a brand-new seat and adding an agent to it works even before you choose a Steward \u2014 a tenant owner can create the draft, and the Steward step comes next; go-live stays blocked until the Steward chain resolves to a real person.
@@ -41893,7 +41909,7 @@ In read-only or demo mode the **Add agent** affordance is disabled or routes to
     order: 42,
     title: "Design a custom agent",
     summary: "How to build a custom agent from operational questions through the Charter Builder, tools, dry run, and go-live without writing prompts.",
-    version: "2026-06-15.1",
+    version: "2026-06-17.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "charter_design"],
@@ -41935,7 +41951,7 @@ Lane and schedule stay advanced unless the work needs them.
 
 ## Configure tools and credentials
 
-Propose tools, then connect or decline each one. Declining updates the permission manifest and the dry-run task so the agent still operates safely or clearly explains the blocker. Credentials are entered through write-only credential ingress and stored as vault references; raw secrets never appear in prompts, logs, or tool arguments.
+Propose tools, then connect or decline each one. Declining updates the permission manifest and the dry-run task so the agent still operates safely or clearly explains the blocker. Credentials are entered through write-only credential ingress and stored as vault references; raw secrets never appear in prompts, logs, or tool arguments. When a connected tool needs a credential, you stage a request with a short credential *name* \u2014 a label only. The name and its scope are validated to reject pasted secret material, so a key can never reach the append-only event log; you provide the secret itself later through the vault-backed ingress flow.
 
 ## From CLI or MCP
 
@@ -41949,7 +41965,7 @@ The same path is command-backed:
 
 ## Dry run and go-live
 
-The agent rehearses a representative task in a sandbox and is expected to escalate where the Charter requires it. A failed dry run keeps the draft and shows the reason so you can edit and rerun. When the dry run passes, a human promotes the agent live.
+The agent rehearses a representative task in a sandbox and is expected to escalate where the Charter requires it. A failed dry run keeps the draft and shows the reason so you can edit and rerun. When the dry run passes, a human promotes the agent live. The dry run rehearses the specific model tier you chose, so once it passes the model is locked \u2014 changing the model requires re-running the dry run on the new model before go-live.
 
 ## When to stop for confirmation
 
@@ -41960,7 +41976,7 @@ The agent rehearses a representative task in a sandbox and is expected to escala
     order: 80,
     title: "Sync rhythm playbook",
     summary: "How Signal, Friction, Cascade, and Sync Briefs turn weekly meetings into decision time.",
-    version: "2026-06-13.1",
+    version: "2026-06-17.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -42005,6 +42021,8 @@ The Sync Brief should answer:
 - Which agent escalations are aging?
 - Which goals lack current evidence?
 
+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.
+
 ## During Sync
 
 Start with the exceptions, not a tour of every seat. Resolve the highest-value Friction first. Convert decisions into handoffs with owners and dates. Clarify Charters when ownership is ambiguous.
@@ -42215,7 +42233,7 @@ Agents should explain the job, the required tool category, the minimum permissio
     order: 48,
     title: "CLI and MCP installation guide",
     summary: "Install the public CLI, register remote token-backed MCP clients, and find the full command and tool catalog.",
-    version: "2026-06-16.2",
+    version: "2026-06-17.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -42394,9 +42412,9 @@ Tenant-admin tokens can run onboarding and tenant setup commands. Seat-scoped to
 | \`{{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}} whoami\` | Show the authenticated user and accessible tenant roles. | User | \`{{cli}} whoami\` |
-| \`{{cli}} tenants\` | List tenants the user can access. | User | \`{{cli}} tenants\` |
-| \`{{cli}} use <tenant>\` | Validate a tenant slug or id for the current user. | User | \`{{cli}} use acme-ops\` |
+| \`{{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\` |
 
 ### Reference and docs
 
@@ -42505,6 +42523,7 @@ These names are available to tenant-admin MCP tokens. They are aliases over the
 | \`rost_rename_seat\` | \`seat.rename\` | Rename a seat. | Seat or tenant-admin | Call with \`seat_id\` and \`name\`. |
 | \`rost_reparent_seat\` | \`seat.reparent\` | Move a seat under a new parent. | Seat or tenant-admin | Call with \`seat_id\` and \`parent_seat_id\`. |
 | \`rost_set_seat_type\` | \`seat.set_type\` | Set a seat type. | Seat or tenant-admin | Call with \`seat_id\` and \`seat_type\`. |
+| \`rost_decommission_seat\` | \`seat.decommission\` | Retire a seat: end occupancies, archive the Charter, revoke tokens/credentials, cancel schedules, tombstone event. No-orphan guarded. | Seat or tenant-admin | Call with \`{"seat_id":"<seat-id>"}\`; expect confirmation. |
 | \`rost_draft_charter\` | \`charter.draft\` | Create or fetch a draft Charter. | Seat or tenant-admin | Call with \`{"seat_id":"<seat-id>"}\`. |
 | \`rost_draft_all_charters\` | \`charter.draft_all\` | Draft Charters for every eligible seat. | Tenant | Call after initial graph creation. |
 | \`rost_update_charter_draft\` | \`charter.update_draft\` | Update a draft Charter document. | Seat or tenant-admin | Call with \`charter_version_id\` and the full \`doc\`. |