@odla-ai/cli 0.25.20 → 0.25.22

package/README.md

@@ -79,6 +79,7 @@ ODLA_DEV_TOKEN=... npx @odla-ai/cli pm handoff --app <appId>
 ODLA_DEV_TOKEN=... npx @odla-ai/cli discuss list --app <appId> --json
 ODLA_DEV_TOKEN=... npx @odla-ai/cli o11y status --app <appId> --env prod --json
 ODLA_DEV_TOKEN=... npx @odla-ai/cli whoami --json
+npx @odla-ai/cli platform status --context production --json
 npx @odla-ai/cli pm handoff --context production --json
 npx @odla-ai/cli runbook new deploy --context production --title Deploy --file deploy.md
 ```
@@ -141,6 +142,47 @@ jobs, missing canary configuration, stale probes, and partial
 socket-reconciliation coverage remain explicit fields. Authentication progress
 is stderr-only, so stdout is a single JSON document.
 
+For platform-wide operations, `platform status --json` requests only the
+short-lived, admin-approved `platform:status:read` capability and reads the
+same `odla.platform-status/v1` snapshot as Studio. It works outside a project
+checkout, derives its complete six-Worker inventory from the deployment
+catalog, probes private services over bindings, and joins observed release
+identity with retained Cloudflare request/error/CPU/wall-time/memory evidence.
+Unavailable health, credentials, versions, or provider snapshots remain
+explicit rather than becoming zero; the document includes stable reason codes
+and exact next actions. The latest successful main deployment persists its
+normalized receipt in Registry D1 after exact-version probes pass. Fleet status
+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.
+
+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
+```
+
+Both commands 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
+other Registry route remain closed. `diff` emits separate SHA-256 revisions for
+desired and observed state, explicit `in_sync`, `different`, or `unmanaged`
+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.
+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.
+
 **Runbooks are procedure; JSDoc is API.** What a function takes, returns, and
 guarantees is documented on the export itself, ships in the installed
 `.d.ts`, and renders per package at <https://odla.ai/docs>. A runbook will tell
@@ -241,6 +283,8 @@ npx odla-ai whoami
 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 calendar status --env dev
 npx odla-ai calendar calendars --env dev
 npx odla-ai calendar connect --env dev

package/REQUIREMENTS.md

@@ -12,6 +12,12 @@ Agnacl, but none should mention or special-case Agnacl.
 - The CLI must validate that contract without network calls.
 - The CLI must show a dry-run plan before creating platform state or writing
   credentials.
+- The CLI must compare checked-in Registry intent with live owner-visible
+  state through a short-lived exact read capability, emit separate stable
+  desired/observed revisions and provenance, distinguish unmanaged runtime
+  settings from drift, and freeze ordered secret-free actions into a plan
+  digest. It must disclose data-plane and secret coverage gaps and must not
+  expose apply until writes are conditional and resumable.
 - The CLI must treat platform registry and odla-db as separate endpoints. They
   may be the same in some deployments, but generated configs must not imply it.
 - If a platform or credential change is deterministic from `odla.config.mjs`,