@rosthq/cli 0.5.28 → 0.5.29

package/dist/index.js

@@ -42257,7 +42257,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-27.6",
+    version: "2026-06-29.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -42311,7 +42311,7 @@ The native Gmail handlers run inside the same broker boundary as the REST and Sl
 
 ## 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. Sheets agent tools remain configuration-only until their guarded handlers ship; connecting Google does not by itself let an agent edit a sheet.
+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.
 
 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.
 
@@ -42346,7 +42346,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-27.2",
+    version: "2026-06-29.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -42392,7 +42392,7 @@ 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 the Gmail handlers (\`gmail.read\`/\`gmail.draft\` autonomous-eligible, \`gmail.send\` held for approval) when Google is connected. 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. Other provider entries remain configuration-only until their connector ships, so nothing runs silently.`
   },
   {
     slug: "mcp-and-cli-guide",
@@ -43911,7 +43911,7 @@ Stop before: approving a Charter, signing a manifest, connecting a tool or crede
     order: 72,
     title: "Settings guide",
     summary: "How to use Settings as the control plane for company access, channels, providers, tokens, and operating defaults.",
-    version: "2026-06-27.1",
+    version: "2026-06-29.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -43950,7 +43950,7 @@ When a settings source is temporarily unavailable, the app keeps the route open
 
 ## Integration health
 
-\`integration.list\` lists connector metadata for CLI and MCP operators, \`integration.readiness\` returns the setup checklist, \`integration.status\` reads one provider or integration id, and \`integration.test\` runs the installed provider-specific health check. These commands return account labels, scopes, capabilities, timestamps, checklist status, DER-coded next actions, and health only; they never return vault references, access tokens, refresh tokens, client secrets, or raw provider responses. Google's test refreshes the vaulted OAuth credential and reads the Gmail profile as the minimal live check. Settings exposes the same Google readiness facts and test action beside Connect/Reconnect, showing whether OAuth env, callback registration, tenant connection, scopes, tests, Google verification/CASA, and Gmail/Sheets handler slices are ready or still waiting on DER-880, DER-881, DER-866, DER-867, or DER-869.
+\`integration.list\` lists connector metadata for CLI and MCP operators, \`integration.readiness\` returns the setup checklist, \`integration.status\` reads one provider or integration id, and \`integration.test\` runs the installed provider-specific health check. These commands return account labels, scopes, capabilities, timestamps, checklist status, DER-coded next actions, and health only; they never return vault references, access tokens, refresh tokens, client secrets, or raw provider responses. Google's test refreshes the vaulted OAuth credential and reads the Gmail profile as the minimal live check. Settings exposes the same Google readiness facts and test action beside Connect/Reconnect, showing whether OAuth env, callback registration, tenant connection, scopes, tests, Google verification/CASA, and Gmail/Sheets handlers are ready or still waiting on DER-880, DER-881, DER-866, or DER-867.
 
 Reconnects keep historical rows for audit, but provider status in Settings, CLI, and MCP prefers the current connected row first, then the latest error or disconnected row.
 
@@ -47552,7 +47552,8 @@ var deliverableWrapper = (context, args) => dispatch(context, "deliverable", arg
       title: requireValue2(parsed, "title")
     }, {
       summary: optionalValue(parsed, "summary"),
-      content: optionalValue(parsed, "content")
+      content: optionalValue(parsed, "content"),
+      delivered_at: optionalValue(parsed, "delivered-at")
     });
     return execute(ctx, parsed, "deliverable.create", body, formatDeliverableWrite);
   },
@@ -47575,7 +47576,7 @@ function deliverableUsage(bin) {
   return `Usage: ${bin} deliverable list|get|create|attach [--json]
   ${bin} deliverable list --seat-id <id>
   ${bin} deliverable get --seat-id <id> --deliverable-id <id>
-  ${bin} deliverable create --title <text> [--kind brief|work_evidence|artifact|report|other] [--summary <text>] [--content <text>]
+  ${bin} deliverable create --title <text> [--kind brief|work_evidence|artifact|report|other] [--summary <text>] [--content <text>] [--delivered-at <iso>]
   ${bin} deliverable attach --title <text> [--run-id <id>] [--task-id <id>] [--work-order-id <id>] [--kind brief|work_evidence|artifact|report|other] [--summary <text>] [--content <text>]`;
 }
 function formatSystemHealth(output) {