@odla-ai/cli 0.7.1 → 0.9.0

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.1 version
-npm i -D --save-exact @odla-ai/cli@0.7.1
+npm view @odla-ai/cli@0.9.0 version
+npm i -D --save-exact @odla-ai/cli@0.9.0
 ```
 
 ## Prerequisites
@@ -59,7 +59,15 @@ 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 secrets set clerk_webhook_secret --env dev --stdin
+npx odla-ai secrets set-clerk-key --env dev --from-env CLERK_SECRET_KEY
 npx odla-ai security run . --env dev --ack-redacted-source
+npx odla-ai security github connect --env dev # infers owner/name from git origin
+npx odla-ai security plan --env dev
+npx odla-ai security sources --env dev
+npx odla-ai security run --source <source-id> --ref main --env dev --plan-digest <digest-from-security-plan> --ack-redacted-source
+npx odla-ai security status <job-id>
+npx odla-ai security report <job-id>
 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
@@ -127,7 +135,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.1`, then
+`npm i -D --save-exact @odla-ai/security@0.2.2`, 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,
@@ -152,12 +160,74 @@ 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.1 version` to succeed before installation. An
+`npm view @odla-ai/security@0.2.2 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.
 
+For a server-side, commit-pinned review, connect one repository through the
+source-read-only odla GitHub App. The CLI infers `owner/name` from a safe GitHub HTTPS
+or SSH `origin`; pass `--repo owner/name` when it cannot. It opens GitHub's
+installation/authorization page and polls that exact odla attempt:
+
+```bash
+npx odla-ai security github connect --env dev
+npx odla-ai security plan --env dev
+npx odla-ai security sources --env dev
+npx odla-ai security run --source <source-id> --ref main --env dev --plan-digest <digest-from-security-plan> --ack-redacted-source
+```
+
+`security plan` is the owner-readable disclosure preflight. It shows the exact
+admin-selected discovery and validation provider/model, immutable policy
+versions, per-route call/input/output bounds, prompt bundle,
+redaction/report contracts, credential readiness, provider independence,
+report retention, the no-target-execution boundary, and a digest covering that
+complete processing contract.
+`security sources` includes the same plan (and returns `{ plan, sources }` with
+`--json`). A source run fetches it again and refuses to enqueue while either
+route is disabled, lacks a usable platform credential, or is not independently
+routed. Copy the displayed digest into `--plan-digest`; the CLI requires it in
+addition to `--ack-redacted-source` and refuses to let a generic acknowledgement
+silently approve a refetched plan. The enqueue request carries the plan digest
+and both expected policy versions. After verifying the user-supplied plan
+digest, the CLI fetches and prints odla.ai's exact source/ref/profile execution
+intent. A second server-computed digest binds that selection, the redacted
+disclosure, and the plan digest; the CLI sends it as
+`expectedExecutionDigest`. A concurrent selection or admin change returns
+`intent_conflict`, `plan_conflict`, `policy_conflict`, or `security_ai_not_ready` instead of
+silently switching providers or models. Fetch and review a fresh `security
+plan`, then explicitly acknowledge its new digest.
+An omitted `--ref` is previewed as the source's explicit current default-branch
+name. If that default changes before enqueue, odla.ai rejects the stale intent;
+it never defers the choice to GitHub HEAD at Workflow execution time.
+
+The source job defaults to follow, renders the normalized report, and applies
+the same `--fail-on high`, `--fail-on-candidates critical`, and incomplete
+coverage gate; use `--no-follow` only to enqueue. `security status <job-id>` and
+`security report <job-id>` recover or inspect a prior job. `security github
+disconnect --source <source-id> --env dev --yes` revokes odla's saved source
+without requiring a GitHub-side uninstall.
+
+The client sends only the opaque odla `sourceId`, ref, profile, and explicit
+`sourceDisclosure: "redacted"`; it has no PAT, GitHub installation id, provider
+key, provider, or model flag. odla.ai verifies repository access, resolves the
+ref to an immutable commit SHA, fetches the bounded snapshot server-side, and
+routes bounded best-effort credential-pattern-redacted snippets through the admin-selected System AI discovery
+and independent-validation models. GitHub read authorization is **not** source
+disclosure consent, which is why `--ack-redacted-source` remains required.
+The retained schema has no archive, file-body, explicit source-excerpt, context
+packet, raw provider-response, execution-trace, or reproduction-output field.
+The private normalized report does retain bounded best-effort credential-pattern-redacted
+model-derived prose and repository-relative paths for up to 90 days, so treat
+it as sensitive because that prose can reveal source semantics or an
+unrecognized secret. GitHub and
+provider retention/residency terms remain separate. GitHub
+Checks contain counts/coverage and link to the authenticated Studio report.
+Target code is not executed, and even complete coverage is not proof of
+security; unscheduled, shallow, blocked, budget-exhausted, and projection-
+truncated work stays visible.
+
 `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
@@ -193,6 +263,22 @@ 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.
 
+`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
+`clerk_webhook_secret` for synced auth). The value may come only from
+`--from-env <NAME>` or `--stdin`, so a producer command pipes straight into the
+vault without the secret ever appearing on argv, in output, or in an agent's
+transcript; it is encrypted at rest and readable back only by that tenant's
+app API key, never by the CLI, Studio, or the developer token. `$`-prefixed
+names are platform-reserved. `secrets set-clerk-key --env <env>` stores the
+app's Clerk secret key in the reserved `$clerk_secret` slot so the platform can
+resolve the app's users (invites, member lookups); reserved secrets are never
+readable by app keys. It refuses an `sk_test_` key for a prod-named env and
+requires `--yes` to put an `sk_live_` key into a non-prod env, since live users
+would sync into a non-prod tenant. Both commands authenticate with the
+developer token (`$ODLA_DEV_TOKEN`, the cached token, or a fresh device
+approval), and prod-named envs require `--yes`, matching `secrets push`.
+
 ## Who does what
 
 If a change is deterministic from `odla.config.mjs`, the CLI owns it: app and