@odla-ai/cli 0.7.0 → 0.7.1

package/README.md

@@ -29,8 +29,8 @@ For a project you keep working in, install it as a dev dependency so the
 shorter `npx odla-ai` form works and the version is pinned by your lockfile:
 
 ```bash
-npm view @odla-ai/cli@0.7.0 version
-npm i -D --save-exact @odla-ai/cli@0.7.0
+npm view @odla-ai/cli@0.7.1 version
+npm i -D --save-exact @odla-ai/cli@0.7.1
 ```
 
 ## Prerequisites
@@ -127,7 +127,7 @@ when provisioning has not written `.odla/credentials.local.json`.
 
 The bundled build/migration skills add a passive pre-ship gate with
 `@odla-ai/security`: after the exact-version availability check, run
-`npm i -D --save-exact @odla-ai/security@0.2.0`, then
+`npm i -D --save-exact @odla-ai/security@0.2.1`, then
 `npx odla-security scan . --profile odla --out .odla/security/pre-ship --fail-on high --fail-on-candidates critical`.
 The passive scan remains a separate binary: it makes no model calls and does
 not execute target code. After explicit redacted-source approval,
@@ -145,10 +145,14 @@ never contacts a model-provider host; the odla.ai broker alone owns the typed
 security prompts/schemas and resolves the admin-selected route and vaulted
 credential. A cached or environment token is audience-bound and is never sent
 to a different `--platform` origin.
-Early-access run ceilings are rolling; a `429` includes the platform's safe
-retry hint, which the CLI surfaces without echoing arbitrary response text.
+Early-access run ceilings are rolling. A platform-ceiling `429` always carries
+a conservative `Retry-After`. A provider-side `429` uses the sanitized
+`provider_rate_limited` code after the provider SDK's bounded retries and
+carries a bounded `Retry-After` only when the upstream supplied one. The CLI
+does not echo arbitrary response text or silently change the admin-selected
+model.
 Before installing the exact release, require
-`npm view @odla-ai/security@0.2.0 version` to succeed before installation. An
+`npm view @odla-ai/security@0.2.1 version` to succeed before installation. An
 exact-version `E404` means the release is unavailable, not that the security
 preflight passed, and does not prove the package name is absent. odla's own
 engineering environment uses an equivalent internal gate; customer projects

package/llms.txt

@@ -31,8 +31,8 @@ For a project you keep working in, install it as a dev dependency so the
 shorter `npx odla-ai` form works and the version is pinned by your lockfile:
 
 ```bash
-npm view @odla-ai/cli@0.7.0 version
-npm i -D --save-exact @odla-ai/cli@0.7.0
+npm view @odla-ai/cli@0.7.1 version
+npm i -D --save-exact @odla-ai/cli@0.7.1
 ```
 
 ## Prerequisites
@@ -129,7 +129,7 @@ when provisioning has not written `.odla/credentials.local.json`.
 
 The bundled build/migration skills add a passive pre-ship gate with
 `@odla-ai/security`: after the exact-version availability check, run
-`npm i -D --save-exact @odla-ai/security@0.2.0`, then
+`npm i -D --save-exact @odla-ai/security@0.2.1`, then
 `npx odla-security scan . --profile odla --out .odla/security/pre-ship --fail-on high --fail-on-candidates critical`.
 The passive scan remains a separate binary: it makes no model calls and does
 not execute target code. After explicit redacted-source approval,
@@ -148,10 +148,14 @@ provider call, attribution, and receipt. Cached/environment tokens are bound to
 their canonical platform audience and are rejected before disclosure on a
 different origin. For a non-default platform, set the matching
 `ODLA_DEV_TOKEN_AUDIENCE` with `ODLA_DEV_TOKEN`.
-Early-access run ceilings are rolling; a `429` includes the platform's safe
-retry hint, which the CLI surfaces without echoing arbitrary response text.
+Early-access run ceilings are rolling. A platform-ceiling `429` always carries
+a conservative `Retry-After`. A provider-side `429` uses the sanitized
+`provider_rate_limited` code after the provider SDK's bounded retries and
+carries a bounded `Retry-After` only when the upstream supplied one. The CLI
+does not echo arbitrary response text or silently change the admin-selected
+model.
 Before installing the exact release, require
-`npm view @odla-ai/security@0.2.0 version` to succeed before installation. An
+`npm view @odla-ai/security@0.2.1 version` to succeed before installation. An
 exact-version `E404` means the release is unavailable, not that the security
 preflight passed, and does not prove the package name is absent. odla's own
 engineering environment uses an equivalent internal gate; customer projects
@@ -280,7 +284,7 @@ If schema is present and rules are omitted, `defaultRules: "deny"` generates
 deny-all rules for every schema entity. That is the safe default for Workers
 that mediate reads and writes with an app key.
 
-## API reference (generated from dist/index.d.ts, v0.7.0)
+## API reference (generated from dist/index.d.ts, v0.7.1)
 
 ```ts
 import { SecurityReport, PlatformSecurityRun } from '@odla-ai/security';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@odla-ai/cli",
-  "version": "0.7.0",
+  "version": "0.7.1",
   "description": "Agent-operable CLI for odla provisioning, scoped System AI administration, hosted security runs, Worker secrets, and smoke checks.",
   "license": "MIT",
   "homepage": "https://odla.ai/docs/packages/cli",
@@ -59,10 +59,10 @@
     "prepublishOnly": "npm run build && npm run gen:llms"
   },
   "dependencies": {
-    "@odla-ai/ai": "^0.3.2",
+    "@odla-ai/ai": "^0.3.3",
     "@odla-ai/apps": "^0.7.1",
     "@odla-ai/db": "^0.6.2",
-    "@odla-ai/security": "^0.2.0"
+    "@odla-ai/security": "^0.2.1"
   },
   "devDependencies": {
     "@types/node": "^22.10.0",

package/skills/odla/references/build.md

@@ -66,12 +66,12 @@ re-provision to push it, and retry.
 Install the passive harness and scan before any production secret or deploy:
 
 Before installing the exact release, first verify
-`npm view @odla-ai/security@0.2.0 version`. An exact-version `E404` means the
+`npm view @odla-ai/security@0.2.1 version`. An exact-version `E404` means the
 release is unavailable and blocks this preflight; it is not a clean scan and
 does not prove the package name is absent.
 
 ```
-npm i -D --save-exact @odla-ai/security@0.2.0
+npm i -D --save-exact @odla-ai/security@0.2.1
 npx odla-security scan . --profile odla --out .odla/security/pre-ship --fail-on high --fail-on-candidates critical
 ```
 
@@ -90,8 +90,10 @@ npx @odla-ai/cli security run . --env dev --ack-redacted-source
 Do not ask for Anthropic/OpenAI/Google keys. The CLI obtains app-owner auth;
 the platform fixes separate discovery/validation grants to the admin-configured
 routes, attributes usage to this app/env/run, and retains no source or prompts
-in its accounting ledger. If a rolling early-access ceiling returns `429`,
-surface the CLI's safe retry hint and do not loop or manufacture a provider key.
+in its accounting ledger. A rolling platform-ceiling `429` always carries a
+conservative retry hint. A provider-side `429` uses the sanitized
+`provider_rate_limited` code and carries a bounded hint only when the upstream
+supplied one. Surface either without looping or manufacturing a provider key.
 
 ## 6. Ship  ⏸ human checkpoint
 

package/skills/odla/references/sdks.md

@@ -70,12 +70,12 @@ Run the passive CLI in local/CI development; do not import it into the running
 Worker:
 
 Before installing the exact release, require
-`npm view @odla-ai/security@0.2.0 version` to succeed before installing it. An
+`npm view @odla-ai/security@0.2.1 version` to succeed before installing it. An
 exact-version `E404` means the release is unavailable, not that the preflight
 passed, and does not prove the package name is absent.
 
 ```
-npm i -D --save-exact @odla-ai/security@0.2.0
+npm i -D --save-exact @odla-ai/security@0.2.1
 npx odla-security scan . --profile odla --out .odla/security/pre-ship --fail-on high --fail-on-candidates critical
 ```
 

package/skills/odla-migrate/references/phase-2-db.md

@@ -10,8 +10,8 @@ in the browser in interactive terminals).
 
 ## Steps
 
-1. Require `npm view @odla-ai/cli@0.7.0 version` to succeed, then run
-   `npm i -D --save-exact @odla-ai/cli@0.7.0` and `npm i @odla-ai/db`.
+1. Require `npm view @odla-ai/cli@0.7.1 version` to succeed, then run
+   `npm i -D --save-exact @odla-ai/cli@0.7.1` and `npm i @odla-ai/db`.
 2. `npx @odla-ai/cli init --app-id <id> --name "<Name>" --env dev --services db`
    Review `odla.config.mjs`. Keep `envs: ["dev"]` — prod is Phase 5. Set
    `links.dev` to the URL the Phase 1 `wrangler deploy` **actually printed** —

package/skills/odla-migrate/references/phase-5-cutover.md

@@ -24,10 +24,10 @@ instance, never a second Clerk app per env; final go/no-go at each step.
    `secrets push --env prod --yes` only to retry the transfer (see
    references/secrets-map.md).
 3. Build, then run the passive pre-cutover security gate:
-   first require `npm view @odla-ai/security@0.2.0 version` to succeed. An
+   first require `npm view @odla-ai/security@0.2.1 version` to succeed. An
    exact-version `E404` means the release is unavailable and blocks cutover;
    it is not a clean scan and does not prove the package name is absent. Run
-   `npm i -D --save-exact @odla-ai/security@0.2.0` followed by
+   `npm i -D --save-exact @odla-ai/security@0.2.1` followed by
    `npx odla-security scan . --profile odla --out .odla/security/pre-cutover --fail-on high --fail-on-candidates critical`.
    Review `REPORT.md`; a candidate is a lead, not confirmation, and a baseline
    requires a concrete reason, owner, and expiry.