@odla-ai/cli 0.25.21 → 0.25.22

package/README.md

@@ -150,8 +150,38 @@ 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. Expected release and drift stay `unknown` until durable
-deployment receipt reads are added.
+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
@@ -253,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`,