@odla-ai/cli 0.27.8 → 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.8",
+  "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

@@ -315,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

@@ -113,10 +113,11 @@ permanent authority.
   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 on first provision: approve the exact id. Collection records
-  a one-time reservation; the credential creates only that app and Registry
-  binds the grant to its new incarnation. Never pre-create a substitute or
-  widen to all projects. The reservation does not bypass later service,
-  configuration, or administrative capability checks.
+  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.

package/skills/odla/references/build.md

@@ -66,12 +66,13 @@ 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, the collected credential creates only that app, and the
-grant becomes bound to its new incarnation. 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. This reservation covers only
-the exact app creation; service, configuration, and administrative mutations
-retain their ordinary capability and human-checkpoint requirements.
+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

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