@odla-ai/cli 0.29.0 → 0.30.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@odla-ai/cli",
-  "version": "0.29.0",
+  "version": "0.30.0",
   "description": "Agent-operable CLI for odla provisioning, calendar consent and connection lifecycle, System AI administration, Worker secrets, security jobs, and smoke checks.",
   "license": "MIT",
   "homepage": "https://odla.ai/docs/packages/cli",

package/skills/odla/SKILL.md

@@ -178,7 +178,10 @@ project id.
 Before project-mutating work, confirm the request aligns to an open goal and
 propose/refine a **task** in Backlog. Ready is a planner handoff: an ordinary
 managed-agent grant has `pm.execute`, so a human owner or `pm.plan` agent must
-approve the Ready contract before the executor claims its reviewed revision.
+approve the Ready contract before an unattended executor claims work discovered
+through PM. A direct request from the user actively directing the coding
+session is already authority: record it, but do not stop and ask that user to
+repeat approval by moving the task to Ready.
 Record a **decision** the moment you make one (with what it rules out), and file
 a **bug** the moment you notice one. A decision you don't record is one the next
 agent re-litigates. Full command set, conventions, and recovery procedure:

package/skills/odla/references/pm-work-intake.md

@@ -43,9 +43,11 @@ An agent must not create a convenient goal merely to authorize itself.
 Ready is a durable planner-to-executor handoff. A human project owner or an
 agent holding `pm.plan` may refine the task and mark it Ready. Ordinary managed
 agent handshakes receive `pm.execute`, not `pm.plan`: they may create a Backlog
-proposal or file a bug, but must ask the user/planner to review the contract and
-perform the Ready transition. Do not treat a 403 as a reason to widen or bypass
-the grant.
+proposal or file a bug. Require the Ready transition only when PM/watch supplied
+the work or the agent is operating unattended. In an interactive coding session,
+the user's direct request is already execution authority; record it in PM and
+continue without asking the same user for a duplicate board click. Do not treat
+a 403 as a reason to widen the grant.
 
 Create/refine the task with one alignment source, an actionable description,
 acceptance criteria, and execution mode:

package/skills/odla/references/pm.md

@@ -106,6 +106,10 @@ Human project owners retain planning authority through ownership. Legacy
 `pm.write` grants remain executable so existing claims are not stranded, but do
 not gain planning authority.
 
+This split coordinates unattended work; it is not an interactive approval
+gate. When a user directly requests work in the active coding session, record
+the request in PM but do not require them to repeat it with a Ready transition.
+
 ## Working with it
 
 **At the start of a session**, resolve the exact project and read before you

package/skills/odla-migrate/references/secrets-map.md

@@ -25,26 +25,26 @@ not ask the human for Anthropic/OpenAI/Google keys for hosted security.
 
 ## Moving the db key (+ o11y token) into the Worker (never through the transcript)
 
-Normal provisioning owns the complete sequence — issuance, mode-0600 local
-storage, `.dev.vars`, and redacted Wrangler stdin transfer. It pushes
-`ODLA_API_KEY` and, when the app enabled o11y, `ODLA_O11Y_TOKEN` too:
+Normal deployment provisioning owns the complete sequence. The handshake
+authorizes one exact Cloudflare target; Registry stages additive DB/o11y
+credentials, the CLI holds plaintext only in memory, and one Wrangler bulk
+stdin call installs `ODLA_API_KEY` plus `ODLA_O11Y_TOKEN`:
 
-    npx @odla-ai/cli provision --write-dev-vars --push-secrets
-    npx @odla-ai/cli provision --yes --push-secrets  # Phase 5; includes prod consent
+    npx @odla-ai/cli provision --push-secrets
+    npx @odla-ai/cli provision --live --yes --push-secrets  # Phase 5; prod only
 
-Use the narrower command only to retry one environment's already-saved
-credential transfer:
+Each developer and Worker may have a different credential for the same sandbox
+tenant. Revocation is targeted and never rotates siblings. Use
+`credentials list` and `credentials revoke <receipt-id>` to inventory or retire
+one deployed runtime. Use the narrower command below only to transfer an
+already-saved local-development credential:
 
     npx @odla-ai/cli secrets push --env dev
     npx @odla-ai/cli secrets push --env prod --yes
 
-Manual fallback (identical mechanics, if the CLI is unavailable):
-
-    node -e 'const c=require("./.odla/credentials.local.json");process.stdout.write(c.envs.dev.dbKey)' \
-      | npx wrangler secret put ODLA_API_KEY --env dev
-
-(For prod, use `c.envs.prod.dbKey` and drop `--env` — the top-level
-wrangler env is prod.)
+There is intentionally no production manual-copy fallback. If the CLI is
+unavailable, repair the CLI or Registry session path rather than exporting a
+production key into shell history or chat.
 
 ## Moving a tenant-vault secret (never through the transcript)
 
@@ -68,11 +68,11 @@ Clerk dashboard between two browser tabs). Prod-named envs require `--yes`.
 - Before every commit: read `git status`; the files above and the build
   output dir must not be staged. `odla-ai init` gitignores them — trust
   but verify.
-- If a secret value ever does land in the conversation or a committed
-  file: tell the human immediately, treat it as burned, and rotate it
-  (`provision --rotate-keys` for the broad credential set, or
-  `provision --rotate-o11y-token --push-secrets` for o11y only — with explicit
-  human approval; provider dashboard for LLM/Clerk values).
-- Studio's o11y token control is manual recovery only. It invalidates the live
-  token immediately and does not update `.odla/credentials.local.json`; prefer
-  the CLI rotation above so the saved and deployed values move together.
+- If a secret value ever does land in the conversation or a committed file:
+  tell the human immediately and treat it as burned. For a receipt-backed
+  Worker, use `credentials revoke <receipt-id>` and run
+  `provision --push-secrets` for a fresh independent set. For a legacy local
+  credential, use `provision --rotate-keys` or `--rotate-o11y-token` only with
+  explicit human approval; use the provider dashboard for LLM/Clerk values.
+- Studio's o11y token control is destructive legacy recovery. Prefer an
+  additive deployment credential so unrelated runtimes remain live.

package/skills/odla-migrate/references/troubleshooting.md

@@ -86,14 +86,12 @@ smoke.
 
 ## Provision reports an existing o11y token but no local credential
 
-Cause: the shown-once token was issued elsewhere, or the local credentials file
-was lost. Plain provision refuses to invalidate a deployed Worker just to
-recover plaintext.
-Fix: after explicit human approval, run
-`npx @odla-ai/cli provision --rotate-o11y-token --push-secrets` (add `--yes`
-when production is in the plan). This persists the replacement before moving it
-to the Worker. Do not use the Studio button for routine recovery; it cannot sync
-the repository's credential file.
+Cause: an older CLI expected one o11y token per tenant. Current o11y credentials
+are additive, so another developer or Worker's token is not an obstacle.
+Fix: run `npx @odla-ai/cli provision --push-secrets` (add `--yes` when production
+is in the plan). The approved handshake stages a new target-bound token and DB
+key, installs them without a local plaintext cache, and leaves every sibling
+credential intact. Use destructive rotation only for an actual compromise.
 
 ## Clerk-verified requests return no email
 
@@ -118,14 +116,14 @@ Never rotate a key or rewrite the route merely to defeat a cached response.
 
 ## Re-running provision — is it safe?
 
-Yes: plain re-runs are idempotent (existing app registration and configured db
-and o11y credentials are reused; schema/rules re-push). Destructive rotation is
-always explicit: `--rotate-o11y-token` replaces only o11y, while
-`--rotate-keys` is the broader credential rotation. Use either only on explicit
-human request, and pair rotation with `--push-secrets` so the Worker receives
-the replacement in the same run. This is not atomic: if the final Wrangler
-transfer fails, the new value is already in the private credentials file. Run
-the printed `secrets push --env ...` retry and do not rotate again.
+Yes: plain local re-runs are idempotent (existing app registration and saved db
+and o11y credentials are reused; schema/rules re-push). Each `--push-secrets`
+run intentionally creates a new receipt-backed set for that exact Worker.
+Retire an older deployment with `credentials list` followed by
+`credentials revoke <receipt-id>`. Destructive legacy local rotation is always
+explicit: `--rotate-o11y-token` replaces only o11y, while `--rotate-keys` is
+broader. Rotation flags cannot be combined with `--push-secrets`; a failed
+Wrangler bulk operation automatically revokes its staged set.
 
 ## Something not covered here