@odla-ai/cli 0.9.0 → 0.10.0

package/skills/odla-migrate/SKILL.md

@@ -2,13 +2,14 @@
 name: odla-migrate
 description: >
   Migrate a static site (e.g. GitHub Pages) to odla on Cloudflare in safe
-  phases, then add a database, Clerk login, and AI. Use when the user wants to
+  phases, then add a database, optional read-only calendar mirror, Clerk login, and AI. Use when the user wants to
   move a static or GitHub Pages site to Cloudflare/odla, or to add a backend,
   database, login/auth, or AI features to a static site via odla.
 runbookOrder:
   - references/phase-0-preflight.md
   - references/phase-1-static.md
   - references/phase-2-db.md
+  - references/phase-2b-calendar.md
   - references/phase-3-auth.md
   - references/phase-3b-user-sync.md
   - references/phase-4-ai.md
@@ -45,12 +46,16 @@ installed skill at `../odla/SKILL.md` instead.
    approved o11y rotation with `--push-secrets` so the Worker is updated in the
    same run. If the final Wrangler transfer fails, use the CLI's printed
    non-rotating `secrets push` retry; never rotate again just to retry delivery.
+7. Existing calendar embeds are public links, not proof of a booking. Preserve
+   them via `bookingPageUrl`; never claim reconciliation until the read-only
+   mirror is connected and the app correlates `$bookings` deliberately. Google
+   OAuth tokens never enter the repo, CLI, or chat.
 
 ## Phase state machine
 
 Phases run strictly in order; each has a verification gate:
 
-  P0 preflight -> P1 static-on-cloudflare -> P2 database -> P3 login
+  P0 preflight -> P1 static-on-cloudflare -> P2 database -> P2b calendar (optional) -> P3 login
   -> P4 ai (optional) -> P5 prod + DNS cutover
 
 `MIGRATION.md` at the user's repo root is the durable state: create it in
@@ -100,6 +105,7 @@ Read the current phase's file when you enter it — not before:
 - references/phase-0-preflight.md
 - references/phase-1-static.md
 - references/phase-2-db.md
+- references/phase-2b-calendar.md (optional: preserve an embed and add authoritative read-only reconciliation)
 - references/phase-3-auth.md
 - references/phase-3b-user-sync.md (optional: mirror Clerk users into $users)
 - references/phase-4-ai.md

package/skills/odla-migrate/references/phase-2-db.md

@@ -10,8 +10,8 @@ in the browser in interactive terminals).
 
 ## Steps
 
-1. Require `npm view @odla-ai/cli@0.8.0 version` to succeed, then run
-   `npm i -D --save-exact @odla-ai/cli@0.8.0` and `npm i @odla-ai/db`.
+1. Require `npm view @odla-ai/cli@0.10.0 version` to succeed, then run
+   `npm i -D --save-exact @odla-ai/cli@0.10.0` and `npm i @odla-ai/db`.
 2. `npx @odla-ai/cli init --app-id <id> --name "<Name>" --env dev --services db`
    Review `odla.config.mjs`. Keep `envs: ["dev"]` — prod is Phase 5. Set
    `links.dev` to the URL the Phase 1 `wrangler deploy` **actually printed** —

package/skills/odla-migrate/references/phase-2b-calendar.md

@@ -0,0 +1,42 @@
+# Phase 2b — Google Calendar (optional, read-only)
+
+Use this phase only when the existing site has a Google Appointment Schedule
+link/embed or locally reported meeting state. Keep the old booking experience
+working while adding an authoritative read-only mirror.
+
+Human obligations: review attendee-data retention and complete the second,
+server-issued Google consent page. They never paste an OAuth code or token.
+
+1. Inventory the old behavior. Distinguish a public appointment-page link from
+   actual event create/reschedule/cancel APIs. Do not promise more than exists.
+2. Require `npm view @odla-ai/calendar@0.1.0 version` to succeed, then install
+   `npm i --save-exact @odla-ai/calendar@0.1.0` as a runtime dependency. An
+   exact-version `E404` blocks this phase; do not substitute a git checkout or
+   another version. Add `"calendar"` beside
+   `"db"` in services and configure:
+   - `calendar.google.calendars.dev` (start with `"primary"`);
+   - optional summary/organizer/attendee match filters;
+   - deliberate `attendeePolicy: "full" | "hashed"`;
+   - the old public Appointment Schedule URL as `bookingPageUrl.dev` when
+     preserving the embed/link. It is public configuration, not a secret.
+3. Run `doctor`, then `provision --dry-run`. Show the human the calendars,
+   attendee policy, public booking page, and read-only scope.
+4. Run normal dev provision. After odla device approval, pause again while the
+   human grants Google `calendar.events.readonly`; the CLI follows initial sync.
+5. Run `calendar calendars --env dev --json`, refine the checked-in ids, and
+   re-provision. Verify `calendar status --env dev --json` and `smoke --env dev`.
+6. Put `initCalendar` only in trusted Worker code. Browser code may keep using
+   the public `bookingPageUrl`, query `$bookings` through explicit db rules, or
+   import pure helpers from `@odla-ai/calendar/client`. Never expose
+   `ODLA_API_KEY`.
+7. Replace self-reported meeting state only after an explicit, tested
+   application-to-booking correlation exists. A matching attendee email may be
+   sufficient for some apps; do not silently regress later workflow statuses.
+
+This slice cannot create, reschedule, or cancel Google events. A static picker
+continues to be Google's sealed UI; odla supplies configuration, mirror reads,
+and reconciliation.
+
+Gate: the old embed/link still works, status is healthy, the selected calendars
+match config, `$bookings` smoke succeeds, no Google credential exists in local
+files, and `MIGRATION.md` records the disclosure/correlation decision.