@odla-ai/cli 0.5.0 → 0.7.0

package/README.md

@@ -7,9 +7,11 @@
 
 Project-neutral provisioning CLI for odla apps. It creates and validates an
 `odla.config.mjs`, then uses that config to register an app, enable services,
-push odla-db schema/rules, configure platform AI, configure Clerk auth, record
+push odla-db schema/rules, configure per-app BYOK AI, configure Clerk auth, record
 deployment links, provision o11y ingest credentials, and transfer local or
-deployed Worker secrets without printing them.
+deployed Worker secrets without printing them. It also gives platform admins a
+scoped System AI control surface and gives app owners a provider-key-free
+hosted security command.
 
 It does not know about any specific app. App identity, environments, services,
 schema, rules, auth, AI provider, and links all come from config.
@@ -27,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.5.0 version
-npm i -D --save-exact @odla-ai/cli@0.5.0
+npm view @odla-ai/cli@0.7.0 version
+npm i -D --save-exact @odla-ai/cli@0.7.0
 ```
 
 ## Prerequisites
@@ -57,6 +59,14 @@ npx odla-ai provision --dry-run
 npx odla-ai provision --write-dev-vars --push-secrets
 npx odla-ai smoke --env dev
 npx odla-ai secrets push --env dev
+npx odla-ai security run . --env dev --ack-redacted-source
+npx odla-ai admin ai show
+npx odla-ai admin ai models
+npx odla-ai admin ai set security --discovery-provider anthropic --discovery-model claude-opus-4-8 --validation-provider openai --validation-model gpt-5.5 --enabled
+npx odla-ai admin ai credentials
+npx odla-ai admin ai credential set anthropic --from-env ANTHROPIC_API_KEY
+npx odla-ai admin ai usage --app-id my-app --env prod --limit 50
+npx odla-ai admin ai audit --limit 25
 npx odla-ai skill install
 npx odla-ai version
 ```
@@ -117,17 +127,56 @@ 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.1.0`, then
+`npm i -D --save-exact @odla-ai/security@0.2.0`, then
 `npx odla-security scan . --profile odla --out .odla/security/pre-ship --fail-on high --fail-on-candidates critical`.
-This is a separate binary, not a hidden `odla-ai` subcommand; it makes no model
-calls and does not execute target code.
+The passive scan remains a separate binary: it makes no model calls and does
+not execute target code. After explicit redacted-source approval,
+`odla-ai security run . --env dev --ack-redacted-source` adds hosted discovery
+and independent validation. The CLI obtains/reuses app-owner auth and the
+platform supplies bounded role grants; it never requests provider keys.
+The hosted run accounts for both immutable role ceilings: discovery reserves
+one call for recon, caps first-pass hunts to what remains, and uses only
+residual calls for retries; validation reviews the highest-risk candidates
+first. The console and artifacts show used/skipped calls, and a budget-limited
+run is `incomplete` unless explicitly reviewed with `--allow-incomplete`.
+All hosted-security network calls target the configured odla platform origin
+(`/registry/security/runs`, `/registry/ai/extract`, and completion). The CLI
+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.
 Before installing the exact release, require
-`npm view @odla-ai/security@0.1.0 version` to succeed before installation. An
+`npm view @odla-ai/security@0.2.0 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
 should use the published `odla-security` command above.
 
+`admin ai show|models|set|credentials|credential set|usage|audit` manages platform-funded System
+AI (`o11y.triage`, `security.discovery`, `security.validation`). It uses a
+separate, mode-`0600` `.odla/admin-token.local.json` cache. Studio displays the
+exact scope, only an admin can approve it, and it expires after ~15 minutes;
+policy, credential, and usage capabilities are separate and cannot act as the
+approver on ordinary app/db/o11y routes. `admin ai models` reads the server
+catalog. `admin ai set security` updates discovery and independent validation
+together with expected revisions; a concurrent edit returns 409 and reloads
+instead of being overwritten. `admin ai usage` requests its own read-only
+capability and lists metadata-only events and status aggregates; narrow it with
+`--app-id`, `--env`, `--run-id`, and `--limit`, or use `--json` for automation.
+`admin ai audit` separately reads immutable metadata-only policy and credential
+change events with actor attribution; credential values never enter that trail.
+It never returns prompts, repository source, model output, reports, or provider
+credentials. Credential writes accept only
+`--from-env <NAME>` or `--stdin` and never place the value in argv, output, or
+the cache. System AI and each app's BYOK AI are separate vault/funding paths.
+Discovery and validation provider/model settings are authoritative server
+policy: a security command has no field that can override either route. Admin
+bounds can only narrow the hard ceilings of 64 calls per role/run and, for each
+call, 512 KiB input and 32,768 output tokens. For a non-default platform, environment credentials
+must also declare the matching `ODLA_ADMIN_TOKEN_AUDIENCE`.
+
 `secrets push --env <env>` is the narrower recovery/retry command. It moves the
 configured env's odla-db key and/or o11y ingest token from
 `.odla/credentials.local.json` into the deployed Worker by piping each value
@@ -149,7 +198,8 @@ agent owns application semantics: installing `@odla-ai/o11y`, wrapping the
 Worker with `withObservability`, and choosing useful spans, metrics, errors, and
 LLM-usage records. The human owns the device approval, production consent, and
 explicit destructive rotation. Studio is where people view telemetry and
-perform manual recovery; its token control is not the normal setup path.
+perform manual recovery, configure System AI, and inspect app/run-attributed
+platform usage; its o11y token control is not the normal setup path.
 Run `npx odla-ai capabilities` for the human-readable contract or add `--json`
 when an agent or tool needs to branch on it without scraping prose.