@odla-ai/cli 0.27.7 → 0.27.8

package/README.md

@@ -466,7 +466,10 @@ shown-once credential.
    Studio shows the immutable project-derived agent handle, project, and
    capability request without mutation controls. The owner approves that exact
    request or declines it with an explanation which the CLI returns to the
-   calling agent; a different identity or access set requires a new request.
+   calling agent; a different identity or access set requires a new request. If
+   the exact project id does not exist yet, approval reserves that id for this
+   credential instead of failing: the credential may create only that app once,
+   and Registry binds its reviewed grant to the new app incarnation.
    Every real CLI handshake prints exactly one canonical `/studio?code=…` URL
    and attempts to open it — including from CI, SSH, display-less, scripted,
    and agent-driven shells. Only `--no-open` suppresses the attempt. Browser
@@ -477,7 +480,8 @@ shown-once credential.
    Outside an interactive terminal the approval wait is capped (90 seconds by
    default; `--wait <seconds>` overrides), and a still-pending handshake exits
    with code 75 — approve at the URL, then re-run to collect the token.
-2. Creates the platform app if needed.
+2. Creates the platform app if needed. For a new id, this consumes the exact-id
+   reservation approved in step 1; it is not ambient project-creation authority.
 3. Enables configured services in every configured environment. Calendar
    config is normalized per env and fixed to Google read-only access.
 4. Mints or reuses each env's configured service credentials: an odla-db app
@@ -554,7 +558,13 @@ or approved-but-uncollected request can be active for that user.
 For an ordinary request, Studio also requires at least one exact project
 selection. The credential receives project metadata, PM, discussion, and
 brand-candidate editing grants only for those projects, never ambient owner
-access, app administration, or brand approval.
+access, app administration, or brand approval. A selected id that does not yet
+exist is a one-time bootstrap reservation: the credential may create that exact
+app, after which the grant is bound to its new lifetime. A 404 from the approve
+action is a routing regression; missing, archived, foreign, changed, or raced
+requests must produce a specific conflict or denial. The reservation authorizes
+only that bootstrap creation; later service, configuration, and administrative
+mutations still require their normal capabilities and human checkpoints.
 
 Developer grants are tracked by id, owner, label, scopes, creation/expiry,
 last use, and revocation state. The plaintext token is delivered once to the

package/REQUIREMENTS.md

@@ -46,6 +46,11 @@ Agnacl, but none should mention or special-case Agnacl.
   controls. Approval accepts the request digest exactly; denial requires a
   bounded, non-secret explanation returned to the polling agent. Any changed
   scope, project, or capability requires a fresh request.
+- An approved exact project id may be absent at review time. Collection must
+  reserve that id for the approved credential, which may create only that app
+  once; creation binds the reviewed grant to the new app incarnation. Existing
+  foreign or archived ids remain unapprovable. Approval precondition failures
+  must return an actionable conflict—never a route-like 404.
 - Only one claimed pending or approved-but-uncollected request may be active per
   user. Unclaimed issued codes must not occupy that slot.
 - Every real CLI handshake must attempt to open that canonical approval URL,

package/package.json

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

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

@@ -112,8 +112,14 @@ 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; 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.
+- 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,14 @@ 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, 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.
+
 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