@odla-ai/cli 0.28.2 → 0.30.0

package/README.md

@@ -461,15 +461,29 @@ the previous bearer.
 - `src/odla/rules.mjs`
 - `.gitignore` entries for local credentials
 
-New configs contain only the `dev` environment. Add `prod` explicitly after
-the development flow is healthy; `provision` refuses to mutate `prod` or
-`production` without `--yes` and supports `--dry-run` for review.
+New configs contain only the `dev` environment. After the development flow is
+healthy, initialize the existing app's live instance without editing the config:
+
+```sh
+npx @odla-ai/cli provision --live --dry-run
+npx @odla-ai/cli provision --live --yes --push-secrets
+```
+
+`--live` targets only `prod`, enables every configured service, provisions its
+credentials/schema/integrations, and refuses to create an app when the sandbox
+does not exist yet. Add `prod` to `envs` only when normal provision runs should
+manage both environments. Calendar apps may predeclare
+`calendar.google.availabilityCalendars.prod` while `envs` remains dev-only;
+live still uses its own Google consent. Every production mutation requires
+`--yes`. Afterwards, explicit live operations such as `smoke --env prod`,
+`secrets push --env prod --yes`, and `app go-live` work while unqualified
+commands continue to default to the sandbox.
 
 `provision` performs the standard safe setup flow:
 
 When using `--push-secrets`, create the Worker and its Wrangler config first.
-The CLI checks that config and `wrangler whoami` before it issues or rotates a
-shown-once credential.
+The CLI checks that config and `wrangler whoami` before it issues a shown-once
+credential set.
 
 1. Gets an `odla_dev_...` token by email-bound device handshake, or reuses
    `ODLA_DEV_TOKEN` / `.odla/dev-token.json`. A fresh handshake requires
@@ -507,8 +521,9 @@ shown-once credential.
    reservation approved in step 1; it is not ambient project-creation authority.
 3. Enables configured services in every configured environment. Calendar
    config is normalized per env and fixed to Google read-only access.
-4. Mints or reuses each env's configured service credentials: an odla-db app
-   key for `db` and an ingest token for `o11y`.
+4. For local development, mints or reuses that developer's configured service
+   credentials. Multiple developers may hold independent DB/o11y credentials
+   for the same shared sandbox tenant.
 5. Collision-checks and merges declared integration schema/rule fragments,
    pushes the composed database contract, and creates integration seeds only
    when their natural-key rows are absent.
@@ -519,23 +534,40 @@ shown-once credential.
    exact Google OAuth endpoint (or a same-platform interstitial). The human completes consent there;
    provision follows the exact attempt through initial sync. OAuth codes and
    refresh tokens never enter the CLI, repo, chat, or app.
-8. Writes `.odla/credentials.local.json` with mode `0600`.
+8. Local-only provisioning writes `.odla/credentials.local.json` with mode
+   `0600`. A deployment run with `--push-secrets` does not write runtime
+   credential plaintext there.
 9. With `--write-dev-vars`, writes the local Worker values to `.dev.vars`; with
-   `--push-secrets`, transfers the configured service secrets to the matching
-   deployed Worker environment over Wrangler stdin.
-
-Plain reruns are idempotent. Pass `--rotate-o11y-token` only when deliberately
-invalidating and replacing the o11y token; combine it with `--push-secrets` so
-the replacement reaches the Worker in the same run. `--rotate-keys` remains the
-broader credential rotation. Production mutation or secret transfer requires
-`--yes`. Pass `--no-write-credentials` to skip writing the local credentials
-file; it cannot be combined with an operation that would issue a shown-once
-credential.
-
-Rotation and Wrangler secret replacement are not a distributed transaction.
-The CLI preflights Wrangler first and persists the replacement before pushing;
-if that final push still fails, follow the printed `secrets push --env ...`
-retry. Do not run the rotation flag again.
+   `--push-secrets`, binds a fresh additive credential set to the exact
+   Cloudflare account/script/environment, transfers both values in one
+   `wrangler secret bulk` stdin payload, and commits a receipt. A failed push
+   aborts the session and revokes partial issuance.
+
+Plain reruns are idempotent at the tenant/configuration layer. Each deployment
+receives new, independently revocable runtime credentials; it never rotates a
+sibling developer or Worker. `--rotate-o11y-token` remains a destructive legacy
+recovery operation for locally cached credentials, and `--rotate-keys` remains
+the broader local rotation. Neither rotation flag may be combined with
+`--push-secrets`. Production mutation or secret transfer requires
+`--yes`. `--no-write-credentials` is valid with `--push-secrets` because the
+deployment path is memory-only by design.
+
+Registry staging and Wrangler installation use a short-lived receipt protocol.
+The CLI preflights the exact target, issues additive credentials, sends one
+bulk payload, and commits only after Wrangler succeeds. Failure revokes staged
+credentials; retrying creates a new bounded session and never invalidates a
+working sibling runtime.
+
+Inventory and retire one successful deployment without disturbing any sibling:
+
+```sh
+npx @odla-ai/cli credentials list --env dev
+npx @odla-ai/cli credentials revoke <receipt-id>
+```
+
+The inventory contains only receipt, target, state, and timestamp metadata.
+Revocation uses the receipt's exact DB and o11y credential ids; no value is
+retrieved or rotated.
 
 ### Application capability integrations
 
@@ -783,9 +815,10 @@ in an agent's transcript. It preflights `wrangler whoami` and the presence of a
 wrangler config file. The env `prod`/`production` targets the top-level
 wrangler environment (no `--env` flag is passed to Wrangler) and requires
 `--yes`; every other env maps to `wrangler --env <name>`. `--dry-run` prints a
-redacted plan without spawning anything. For the normal path, use
-`provision --write-dev-vars --push-secrets` so service enablement, credential
-issuance, local config, and deployed secret transfer stay one composition.
+redacted plan without spawning anything. It is only for an already-saved local
+credential. For a new Worker or a lost local plaintext, use
+`provision --push-secrets`: the handshake authorizes new target-bound
+credentials and no local production cache is required.
 
 `secrets set <name> --env <env>` stores one named secret in that env's tenant
 vault — the same write-only slot Studio's Secrets panel fills (for example

package/REQUIREMENTS.md

@@ -28,6 +28,10 @@ Agnacl, but none should mention or special-case Agnacl.
 - Source semantics remain with the coding agent: package installation, Worker
   instrumentation, and application-specific signals/rules. Humans approve
   identity, production mutation, and explicit destructive rotation.
+- An existing dev-first sandbox app must be able to initialize only its live
+  environment with one explicit CLI mode. That mode enables the complete
+  configured service set, requires production consent, refuses to create a new
+  app, and must not make live part of later unqualified provision runs.
 
 ## Human Approval