@odla-ai/cli 0.25.22 → 0.26.1

package/README.md

@@ -156,15 +156,36 @@ therefore compares that verified expectation with the Worker answering now and
 reports `matched`, `drifted`, or `unknown`; an empty or unavailable receipt
 ledger degrades instead of silently treating observed health as intended state.
 
+Platform maintainers can rotate the built-in Discussion responder without
+minting an unrestricted app key or exposing the replacement in argv/output:
+
+```bash
+npx @odla-ai/cli platform chat-credentials rotate \
+  --wrangler-config packages/chat-agent/wrangler.jsonc \
+  --expected-version <deployed-chat-version-id> \
+  --email <odla-admin-account> \
+  --yes --json
+```
+
+The command requests only `platform:chat:credential:write`, mints an
+`agent_odla` key restricted to the Discussion namespaces and write envelope,
+pipes the nested `ODLA_BOT_TOKENS` map to Wrangler over stdin, and succeeds only
+after the service-binding health bridge advances from the pre-rotation Worker
+version to a healthy secret-change deployment. `--expected-version` fences the
+pre-rotation version before any credential is minted. Superseded keys are
+revoked separately after that health proof.
+
 For repository-managed settings, compare checked-in intent with the live
 owner-visible Registry projection before provisioning:
 
 ```bash
 npx odla-ai config diff --json
-npx odla-ai config plan --json
+npx odla-ai config plan --json > .odla/config-plan.json
+npx odla-ai config apply --plan .odla/config-plan.json --json
+npx odla-ai operations wait <operation-id> --json
 ```
 
-Both commands are read-only and request only a short-lived,
+`diff` and `plan` are read-only and request only a short-lived,
 owner-approvable `app:config:read` capability. It opens only exact-id
 `GET /registry/apps/<appId>` reads for apps the approver owns; app listing,
 writes, PM, Discussions, directory access, data-plane delegation, and every
@@ -174,14 +195,33 @@ status, field provenance, and a bounded coverage declaration. Runtime auth or
 links omitted from project config stay visible as `unmanaged` rather than
 being silently overwritten.
 
-`plan` freezes those revisions plus ordered actions into a stable plan digest.
+`plan` v2 freezes those content revisions, the monotonic Registry
+`registry:<number>` revision, and ordered actions into a stable digest.
 Enable/configure actions are dependency-first; proposed disablements are
-dependent-first, high-risk, approval-required, and Studio-only. Conditional,
-resumable `config apply` is intentionally not exposed yet. The plan names the
-existing provision, rename, and Studio steps that can be reviewed separately,
-and explicitly excludes schema, rules, integration seeds, credentials, vault
-or Worker secrets, OAuth connection state, and opaque controller-assigned
-service fields rather than claiming whole-system convergence.
+dependent-first, high-risk, approval-required, and Studio-only.
+
+`config apply` accepts only that saved JSON plan. Before requesting authority it
+recomputes the digest, verifies the selected app/platform, confirms checked-in
+intent has not changed, and rejects every production, destructive,
+approval-marked, high-risk, Studio, auth, creation, or disable action. The
+short-lived `app:config:write` grant reaches only this app's operation
+reserve/resume/read routes; it cannot enumerate apps or call direct mutation
+routes. A deterministic default idempotency key makes retrying the same plan
+resume the same durable journal entry, while the Registry CAS revision rejects
+stale state.
+
+Apply prints the operation receipt, including ordered step attempts and its
+canonical environment-settings recovery URL. Studio preserves the exact
+operation id in that URL and renders the matching
+`operations get <id> --json` recovery command. Plans that require Studio now
+link to the explicit app/environment settings scope instead of an ambiguous
+app-level Settings page. `operations get` reads one exact id without replaying it;
+`operations wait` polls that id for 60 seconds by default (`--timeout` and
+`--interval` are explicit seconds). A still-running bounded wait exits 75 after
+printing its last receipt. Every terminal receipt is independently
+digest-verified by the CLI before success. Schema, rules, integration seeds,
+credentials, vault or Worker secrets, OAuth connection state, and opaque
+controller-assigned service fields remain outside this boundary.
 
 **Runbooks are procedure; JSDoc is API.** What a function takes, returns, and
 guarantees is documented on the export itself, ships in the installed
@@ -210,7 +250,10 @@ npx @odla-ai/cli runbook edit db --note "retract replaced the null write"
 
 Platform runbook edits need admin or the `platform:runbook:write` capability,
 which the CLI requests for you; a plain handshake token is never admin by
-design, and `odla-ai whoami` reports what this terminal actually holds.
+design. `odla-ai whoami` reports the actual credential-bound principal by
+friendly name, handle, and kind; an agent's manager; the credential kind; and
+the accountable human owner separately. Manager metadata explains organization
+but never grants authority.
 
 **Is the corpus itself still true?**
 
@@ -284,7 +327,10 @@ npx odla-ai setup
 npx odla-ai init --app-id my-app --name "My App"
 npx odla-ai doctor
 npx odla-ai config diff --json
-npx odla-ai config plan --json
+npx odla-ai config plan --json > .odla/config-plan.json
+npx odla-ai config apply --plan .odla/config-plan.json --json
+npx odla-ai operations get <operation-id> --json
+npx odla-ai operations wait <operation-id> --timeout 60 --json
 npx odla-ai calendar status --env dev
 npx odla-ai calendar calendars --env dev
 npx odla-ai calendar connect --env dev
@@ -483,6 +529,10 @@ claimable Studio request, and the public start/poll shape intentionally does not
 reveal whether an account exists. The signed-in matching user must explicitly
 review the exact code before it becomes pending, and only one claimed pending
 or approved-but-uncollected request can be active for that user.
+For an ordinary request, Studio also requires at least one exact project
+selection. The credential receives project metadata, PM, discussion, and
+brand-candidate editing grants only for those projects, never ambient owner
+access, app administration, or brand approval.
 
 Developer grants are tracked by id, owner, label, scopes, creation/expiry,
 last use, and revocation state. The plaintext token is delivered once to the