@odla-ai/cli 0.27.7 → 0.27.9

package/dist/index.js

@@ -57,7 +57,7 @@ import {
   startHostedSecurityJob,
   surfacePaths,
   validateInvocation
-} from "./chunk-MZSU4YQL.js";
+} from "./chunk-LT56MKDK.js";
 export {
   AGENT_HARNESSES,
   CAPABILITIES,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@odla-ai/cli",
-  "version": "0.27.7",
+  "version": "0.27.9",
   "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

@@ -115,6 +115,7 @@ guessing which platform/credential steps need manual work. Then:
    `--wait <seconds>`); exit code 75 means still pending: the handshake is
    persisted, so once the human approves, re-run the same command and it
    resumes the same code and collects the token. It creates the app,
+   consuming a one-time exact-id reservation when the approved app is new,
    enables services, issues or reuses configured credentials (db key + o11y
    ingest token when enabled), composes declared integration schema/rules and
    guarded seeds, writes `.dev.vars`, and
@@ -314,5 +315,5 @@ code, paste a publishable key, run a command) — and wait for a nod.
   across credential expiry, linked worktrees, and non-odla-ai projects without
   copying a token or widening project authority.
 - `references/co-owners.md` — sharing one app's db and tooling across a team:
-  `app owners add/list/remove`, and how each co-owner self-provisions their own
+  signed-in Studio ownership changes, and how each co-owner self-provisions their own
   credentials (dev and the shared prod database) without any secret handoff.

package/skills/odla/references/agent-identity.md

@@ -112,8 +112,15 @@ permanent authority.
 - Wrong handle requested: decline it and correct the project/SDK request before
   starting a fresh handshake. If already approved, revoke the new credential in
   Studio; do not rename or merge principals by editing local metadata.
-- Missing project after reconnect: start a new reviewed handshake and select the
-  exact project; never widen to all projects.
+- Missing project on first provision: approve the exact id. Collection records
+  a one-time reservation plus the explicit `app.manage` provision capability;
+  the credential creates only that app, Registry binds the grant to its new
+  incarnation, and provision may continue through non-lifecycle configuration.
+  Never pre-create a substitute or widen to all projects. Ownership and
+  lifecycle operations still require the direct human session.
+- Approval returns 404: treat it as a Registry routing regression, not a missing
+  project outcome. Preserve the code and pending state, report the incident,
+  and retry the same request after Registry is healthy.
 - Project ownership/lifecycle changed after approval: collection expires the
   unusable replacement while preserving the current credential and grant set.
   Restore the intended project state, then start and review a fresh handshake.

package/skills/odla/references/build.md

@@ -55,7 +55,8 @@ The email is an account identifier, never a password or session credential.
 Prints a short device code and a link. ⏸ That same account opens the link, signs
 in, explicitly reviews the exact code, and approves it — loading the URL alone
 does not claim access, and no secret passes through the chat. Provision then:
-creates the app, enables its services, issues or reuses the db key (and the
+creates the app (consuming the approved one-time exact-id reservation when it
+is new), enables its services, issues or reuses the db key (and the
 o11y ingest token when o11y is enabled), pushes the composed app + integration
 schema/rules, creates missing guarded seeds, writes
 `.dev.vars`, and transfers configured Worker secrets through Wrangler stdin.
@@ -64,6 +65,15 @@ Local credential files are `0600` and gitignored. Verify with
 anything unset. `--push-secrets` preflights the Wrangler config and login before
 issuing or rotating a shown-once credential.
 
+If Studio shows an unknown exact app id, that is a valid first provision: the
+human approves the id and explicit `app.manage` provision capability, the
+collected credential creates only that app, and the grant becomes bound to its
+new incarnation. It may then finish non-lifecycle service configuration and
+tenant administration. Do not pre-create a substitute app or broaden the
+request. A 404 from **Approve** is a platform regression; capture the code and
+retry only after Registry is healthy. Ownership, rename/category, and lifecycle
+mutations remain direct-human operations.
+
 Calendar adds a second ⏸ checkpoint after the odla device approval: provision
 prints/opens a state-bound Google URL issued by the platform and waits while
 the human grants the booking scopes in a browser. The CLI never receives the

package/skills/odla/references/co-owners.md

@@ -13,16 +13,11 @@ records who co-owns an app; the db honors any co-owner when they provision.
 
 ## Onboarding a co-owner
 
-1. **The primary owner adds them** (they must already be a signed-up odla
-   member — an admin invites them first if not):
-
-   ```cmd
-   npx @odla-ai/cli app owners add teammate@example.com
-   npx @odla-ai/cli app owners list
-   ```
-
-   (`npx @odla-ai/cli app owners remove teammate@example.com` revokes it. The
-   primary owner can't be removed. Studio's app **Settings** does the same.)
+1. **The primary owner adds them in signed-in Studio app Settings** (they must
+   already be a signed-up odla member — an admin invites them first if not).
+   Ownership mutation requires a direct human session. Do not tell an agent to
+   run `app owners add`: a device-handshake token intentionally receives
+   `human_session_required` on that route. The primary owner cannot be removed.
 
 2. **The co-owner provisions as themselves.** They clone the repo (which carries
    `odla.config.mjs` but not the gitignored credentials) and run provision with
@@ -47,12 +42,15 @@ own key. Treat first-prod provision/deploy as the usual human checkpoint
 (`provision --dry-run` review, then `provision --yes --push-secrets`), and never
 rotate another owner's credentials on their behalf.
 
-## If provision says "you are not an owner"
+## If provision says the credential lacks `app.manage`
 
 provision checks tenant admin access up front and aborts **before** anything is
 minted or written — no credential lands on disk, in the vault, or in a Worker.
-It means the registry doesn't list you as an owner yet: ask an existing owner
-to run `npx @odla-ai/cli app owners add <your-email>`, then re-run provision.
+First rerun provision and approve its fresh exact-project `app.manage` request;
+the CLI does not reuse a baseline cached or pending handshake for this. If the
+human account itself is not an owner, ask an existing owner to add it in
+signed-in Studio app Settings, then rerun provision. An agent token cannot fix
+ownership and the CLI must not suggest that it can.
 
 ## If a co-owner loses their local key