@odla-ai/cli 0.27.5 → 0.27.7

package/README.md

@@ -589,7 +589,7 @@ For parity with a static Google Appointment Schedule embed/link, set the public
 `bookingPageUrl` per environment. Provision applies it through the owner-only
 calendar settings route; it is public configuration, not a credential.
 
-`calendar status` returns the safe connection/sync projection; add `--json` for
+`calendar status` returns the safe connection/bookability projection; add `--json` for
 agent automation. Once connected, `calendar calendars` lists ids visible to the
 Google identity so the checked-in selection can be refined. `calendar connect`
 applies the checked-in booking-page setting and starts consent when the
@@ -609,14 +609,15 @@ authorization code, client secret, access token, or refresh token.
 
 The SDK uses the existing server-side db values (`ODLA_ENDPOINT`,
 `ODLA_TENANT`, `ODLA_API_KEY`), so calendar adds no Worker secret. Never expose
-`ODLA_API_KEY` to a browser. Trusted Worker code can initialize
-`@odla-ai/calendar`; browser code reads `$bookings` through `@odla-ai/db/client`
-under explicit rules or imports pure helpers from `@odla-ai/calendar/client`.
-
-These commands operate the current read/embed reconciliation slice. The CLI has
-no native slot-picker or create/reschedule/cancel command, and exposes no
-rolling-window/age-out, quota-backoff, retention/purge, or provider-derived
-mutation-id control. Public health remains aggregate rather than per calendar.
+`ODLA_API_KEY` to a browser. Trusted Worker code initializes
+`@odla-ai/calendar` for live FreeBusy/upcoming reads and idempotent
+create/reschedule/cancel operations; browser code imports only pure helpers and
+public configuration from `@odla-ai/calendar/client`.
+
+These CLI commands manage the provider connection and its non-secret calendar
+selection. They intentionally do not create or mutate events: application
+backends do that through `@odla-ai/calendar`. Google is the source of truth and
+odla stores no event or attendee mirror.
 
 The bundled build/migration skills add a passive pre-ship gate with
 `@odla-ai/security`: install it with a normal development range, commit the

package/dist/bin.cjs

@@ -518,7 +518,7 @@ var SCOPE_PURPOSE = {
   "platform:status:read": "read the platform fleet health and deployment snapshot",
   "app:config:read": "compare checked-in intent with an exact-id app Registry configuration",
   "app:config:write": "apply or inspect one revision-bound configuration operation for an app you own",
-  "platform:runbook:write": "add or edit odla's operational runbooks",
+  "platform:runbook:write": "read and edit all of odla's operational runbooks, including admin-visible content",
   "platform:ai:policy:write": "change System AI model routing",
   "platform:ai:policy:read": "read System AI model routing",
   "platform:ai:credential:write": "replace a stored AI provider key",
@@ -12067,8 +12067,13 @@ async function whoamiCommand(parsed, deps = {}) {
   out.log(`admin:      ${identity.admin ? "yes" : "no"}`);
   if (identity.scopes.length) out.log(`scopes:     ${identity.scopes.join(", ")}`);
   if (!identity.admin) {
-    out.log("\nYou can read platform runbooks but not edit them. A handshake-minted");
-    out.log("device token never carries admin \u2014 sign in to Studio as an admin to edit.");
+    if (identity.scopes.includes("platform:runbook:write")) {
+      out.log("\nThis exact scope can read and edit all platform runbook content.");
+      out.log("The device token is not ambient admin and cannot change visibility.");
+    } else {
+      out.log("\nYou can read operator-visible platform runbooks but not edit them.");
+      out.log("Use a platform-admin-approved runbook write request to edit.");
+    }
   }
 }