npm - @lunora/cli - Versions diffs - 1.0.0-alpha.105 → 1.0.0-alpha.106 - Mend

@lunora/cli 1.0.0-alpha.105 → 1.0.0-alpha.106

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (8) hide show

package/package.json +4 -4
package/skills/README.md +28 -14
package/skills/lunora/SKILL.md +48 -9
package/skills/lunora-functions/SKILL.md +38 -3
package/skills/lunora-migration-helper/SKILL.md +36 -17
package/skills/lunora-performance-audit/SKILL.md +36 -6
package/skills/lunora-quickstart/SKILL.md +61 -20
package/skills/lunora-realtime/SKILL.md +43 -30

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "@lunora/cli",
-  "version": "1.0.0-alpha.105",
+  "version": "1.0.0-alpha.106",
   "description": "The Lunora CLI: init, dev, deploy, codegen, run, reset, and migrate commands",
   "keywords": [
     "agent-skills",
@@ -53,13 +53,13 @@
   "dependencies": {
     "@bomb.sh/tab": "0.0.21",
     "@lunora/bindings": "1.0.0-alpha.11",
-    "@lunora/codegen": "1.0.0-alpha.58",
-    "@lunora/config": "1.0.0-alpha.84",
+    "@lunora/codegen": "1.0.0-alpha.59",
+    "@lunora/config": "1.0.0-alpha.85",
     "@lunora/container": "1.0.0-alpha.16",
     "@lunora/d1": "1.0.0-alpha.43",
     "@lunora/errors": "1.0.0-alpha.8",
     "@lunora/runtime": "1.0.0-alpha.39",
-    "@lunora/seed": "1.0.0-alpha.33",
+    "@lunora/seed": "1.0.0-alpha.34",
     "@visulima/cerebro": "3.0.0",
     "@visulima/error": "6.0.0",
     "@visulima/fs": "5.0.5",

package/skills/README.md CHANGED Viewed

@@ -9,21 +9,35 @@ framework correctly. They ship inside `@lunora/cli` and are discovered by the
 Each skill is a `SKILL.md` with YAML frontmatter (`name`, `description`) in its
 own directory:
-| Skill                      | Use for                                                                     |
-| -------------------------- | --------------------------------------------------------------------------- |
-| `lunora`                   | Router — start here, then switch to the matching skill below.               |
-| `lunora-quickstart`        | `lunora init` / adding Lunora to an app + first round-trip.                 |
-| `lunora-functions`         | Core authoring rules — schema, validators, query/mutation/action, `ctx.db`. |
-| `lunora-realtime`          | Client reactivity — live hooks, optimistic updates, `@lunora/db`.           |
-| `lunora-setup-auth`        | Authentication via `lunora registry add auth` (+ providers).                |
-| `lunora-setup-mail`        | Transactional email via `lunora registry add mail` — `sendEmail` actions.   |
-| `lunora-setup-storage`     | R2 file storage via `lunora registry add storage` — signed upload/download. |
-| `lunora-setup-scheduler`   | Deferred (`ctx.scheduler`) + cron jobs (`lunora registry add crons`).       |
-| `lunora-create-package`    | Building a reusable registry item or `@lunora/*` package.                   |
-| `lunora-migration-helper`  | Schema/data migrations, `.global()` D1 flow, the drift gate.                |
-| `lunora-deploy`            | Deploying to Cloudflare — wrangler bindings, secrets, the gate.             |
-| `lunora-performance-audit` | Scans, indexes, OCC write conflicts, sharding/`.global()`.                  |
+| Skill                            | Use for                                                                      |
+| -------------------------------- | ---------------------------------------------------------------------------- |
+| `lunora`                         | Router — start here, then switch to the matching skill below.                |
+| `lunora-quickstart`              | `lunora init` / adding Lunora to an app + first round-trip.                  |
+| `lunora-functions`               | Core authoring rules — schema, validators, query/mutation/action, `ctx.db`.  |
+| `lunora-realtime`                | Client reactivity — live hooks, optimistic updates, `@lunora/db`.            |
+| `lunora-setup-auth`              | Authentication via `lunora registry add auth` (+ providers).                 |
+| `lunora-setup-mail`              | Transactional email via `lunora registry add mail` — `sendEmail` actions.    |
+| `lunora-setup-storage`           | R2 file storage via `lunora registry add storage` — signed upload/download.  |
+| `lunora-setup-scheduler`         | Deferred (`ctx.scheduler`) + cron jobs (`lunora registry add crons`).        |
+| `lunora-setup-hyperdrive`        | Existing Postgres/MySQL from an action — `ctx.sql`, non-reactive.            |
+| `lunora-setup-hyperdrive-global` | Postgres/MySQL as a reactive `.global()` backend; D1 → Hyperdrive migration. |
+| `lunora-create-package`          | Building a reusable registry item or `@lunora/*` package.                    |
+| `lunora-migration-helper`        | Schema/data migrations, `.global()` DDL flow, the drift gate.                |
+| `lunora-deploy`                  | Deploying to Cloudflare — wrangler bindings, secrets, the gate.              |
+| `lunora-performance-audit`       | `lunora insights`, scans, indexes, OCC conflicts, sharding/`.global()`.      |
 These are mirrored into `.agents/skills/` and `.claude/skills/` (via symlinks)
 so agents working inside this repo pick them up directly. The source of truth
 lives here so the published `@lunora/cli` tarball carries them.
+**Adding a skill?** Create it here, then mirror it through both hops:
+```bash
+ln -s ../../packages/cli/skills/<name> .agents/skills/<name>
+ln -s ../../.agents/skills/<name> .claude/skills/<name>
+```
+`scripts/check-skill-mirrors.js` (run on every `pnpm install`) fails if a mirror
+is missing, dangling, or has become a real directory — a copied directory keeps
+resolving while it silently drifts from the source, so it is treated as an
+error rather than a warning.

package/skills/lunora/SKILL.md CHANGED Viewed

@@ -14,8 +14,9 @@ Lunora exposes a Convex-style functional API (`defineSchema`, `query`,
 `mutation`, `action`) on top of Cloudflare Workers and Durable Objects. State
 lives in a per-app `ShardDO` (SQLite, OCC, hibernated WebSocket subscriptions)
 by default; `.shardBy(key)` partitions it across many DOs and `.global()`
-replicates a table to D1 for low-latency cross-region reads. A Vite plugin
-drives codegen and end-to-end type sync.
+replicates a table to D1 — or to Postgres/MySQL over Hyperdrive — for
+low-latency cross-region reads. A Vite plugin drives codegen and end-to-end
+type sync.
 If a more specific Lunora skill clearly matches the request, use that instead.
@@ -47,12 +48,13 @@ After codegen is green, use the most specific Lunora skill for the task:
 - Wiring live data into a client (hooks, optimistic updates): `lunora-realtime`
 - Authentication setup (email/password, OAuth, magic link, OTP):
   `lunora-setup-auth`
-- Wiring a prebuilt capability (mail, file storage, scheduled jobs, rate
-  limiting, vectors, AI, containers, payments, MCP): install it with
-  `lunora registry add <item>` (see `lunora registry list`). Capabilities with a
-  dedicated skill: `lunora-setup-mail` (mail), `lunora-setup-storage` (R2 file
-  storage), `lunora-setup-scheduler` (deferred `ctx.scheduler` + cron jobs). For
-  the rest, read the item's README after installing.
+- Transactional email: `lunora-setup-mail`
+- R2 file storage (signed upload/download): `lunora-setup-storage`
+- Deferred work (`ctx.scheduler`) and cron jobs: `lunora-setup-scheduler`
+- Querying an **existing** Postgres/MySQL database from an action (`ctx.sql`,
+  non-reactive): `lunora-setup-hyperdrive`
+- Using Postgres/MySQL as a **reactive `.global()` backend**, or migrating a D1
+  `.global()` dataset onto it: `lunora-setup-hyperdrive-global`
 - Building a reusable capability — a registry item or an `@lunora/*` package:
   `lunora-create-package`
 - Planning or running a schema/data migration: `lunora-migration-helper`
@@ -64,6 +66,41 @@ After codegen is green, use the most specific Lunora skill for the task:
 If one of those clearly matches the user's goal, switch to it instead of staying
 in this skill.
+## Capabilities Without a Dedicated Skill
+Most other capabilities install as a **registry item** — `lunora registry add
+<item>` scaffolds the `lunora/` glue, wrangler bindings, and env vars, then
+prints post-install steps. Browse with `lunora registry list`; preview with
+`lunora registry view <item>`. Read the installed item's README, and the
+package's `docs/` for the API.
+| Goal                                          | Install / package                                            |
+| --------------------------------------------- | ------------------------------------------------------------ |
+| Background jobs on Cloudflare Queues          | `registry add queue` → `@lunora/queue` (`ctx.queues`)        |
+| Durable multi-step workflows                  | `registry add workflow` → `@lunora/workflow` (`ctx.runStep`) |
+| Durable AI agents (tool loops, HITL, memory)  | `@lunora/agent` (`defineAgent`)                              |
+| Workers AI / RAG                              | `registry add ai` → `@lunora/ai` (`ctx.ai`, `defineRag`)     |
+| Feature flags (OpenFeature)                   | `registry add flags` → `@lunora/flags` (`ctx.flags`)         |
+| Payments (Stripe / Polar)                     | `registry add payment` → `@lunora/payment`                   |
+| Rate limiting                                 | `registry add ratelimit` → `@lunora/ratelimit`               |
+| Headless browser (action-only)                | `registry add browser` → `@lunora/browser` (`ctx.browser`)   |
+| Cloudflare Containers                         | `@lunora/container` (`defineContainer`, `ctx.containers`)    |
+| Presence / who's-here                         | `registry add presence`                                      |
+| Cloudflare Access (Zero Trust) identity       | `registry add cloudflare-access`                             |
+| Backup / restore                              | `registry add backup`                                        |
+| Testing (in-memory harness, agent doubles)    | `@lunora/testing` (`lunoraTest`)                             |
+| Deterministic seed data                       | `@lunora/seed` + `lunora seed`                               |
+| Local-first replica / offline mirror          | `@lunora/replica`                                            |
+| Exposing the deployment to AI agents over MCP | `@lunora/mcp`                                                |
+Scaffolding inside this repo uses `vis generate lunora-<kind>` — `query`,
+`mutation`, `action`, `http-route`, `table`, `cron`, `container`, `workflow`,
+`queue`, `step`, `agent`, `flags`, `collections`, `package` (`vis generate
+--list` for the full set). Most take a name: **always** pass it as
+`--name=value`, since vis parses a space-separated `--name foo` as `--name=true`
+plus a stray positional. `lunora-flags` and `lunora-collections` are singletons
+and take no name.
 ## Core Mental Model
 - **Functions** live in `lunora/*.ts` and are one of `query` (reactive read),
@@ -75,7 +112,9 @@ in this skill.
 - **Reads go through indexes.** Prefer `ctx.db.query("t").withIndex(...)` over
   `.filter(...)`; declare the index with `.index("by_x", ["x"])`.
 - **Clients** subscribe over WebSocket. `useQuery`/`useMutation` (React, Vue,
-  Solid, Svelte) re-render the moment a mutation changes the queried rows.
+  Solid, Svelte, React Native; signals in Angular) re-render the moment a
+  mutation changes the queried rows. Subscriptions run under the socket's
+  verified identity, so `rls()` / `ctx.auth` apply to live updates too.
 ## When Not to Use

package/skills/lunora-functions/SKILL.md CHANGED Viewed

@@ -150,9 +150,44 @@ Declare the index and constrain with `.withIndex`.
 ## Other `ctx` capabilities
-`ctx.auth` (the resolved session: `ctx.auth.userId`), `ctx.scheduler`
-(`runAfter` / `runAt` for deferred work), `ctx.storage` (R2), `ctx.vectors`
-(Vectorize), and — when their packages are wired — `ctx.ai` and `ctx.containers`.
+Always available:
+- `ctx.auth` — the resolved session (`ctx.auth.userId`).
+- `ctx.scheduler` — `runAfter` / `runAt` for deferred work.
+- `ctx.secrets` — Cloudflare Secrets Store.
+- `ctx.span` / `ctx.trace` — the current span and a scoped tracing helper for
+  wide events.
+Added by their package when wired. **A dependency in `package.json` is not
+enough** — codegen scans the `lunora/` source set and flips a capability on only
+when a file there imports the `@lunora/*` package or reads its `ctx.*` helper.
+So write the call first, then run `lunora codegen` to surface the typed context:
+| `ctx.*`                                                                                   | Package                       |
+| ----------------------------------------------------------------------------------------- | ----------------------------- |
+| `ctx.storage`                                                                             | `@lunora/storage` (R2)        |
+| `ctx.ai`                                                                                  | `@lunora/ai` (Workers AI)     |
+| `ctx.flags`                                                                               | `@lunora/flags` (OpenFeature) |
+| `ctx.queues.<name>`                                                                       | `@lunora/queue`               |
+| `ctx.workflows` / `ctx.runStep`                                                           | `@lunora/workflow`            |
+| `ctx.containers`                                                                          | `@lunora/container`           |
+| `ctx.browser` (action-only)                                                               | `@lunora/browser`             |
+| `ctx.sql` (action-only)                                                                   | `@lunora/hyperdrive`          |
+| `ctx.kv` / `ctx.images` / `ctx.analytics` / `ctx.pipelines` / `ctx.vectors` / `ctx.r2sql` | `@lunora/bindings` subpaths   |
+Two exceptions to the usage scan, and one extra requirement:
+- **`ctx.flags` gates on a declaration file**, not on usage — codegen wires it
+  only when `lunora/flags.ts` exists (`vis generate lunora-flags` creates it).
+  `ctx.notify` / `ctx.push` work the same way via `lunora/notify.ts`.
+- **`ctx.sql` also needs the real resource.** Codegen types the field, but the
+  connection needs a `HYPERDRIVE` binding (`wrangler hyperdrive create`) and an
+  explicit `createHyperdrive(ctx.env.HYPERDRIVE)` + driver adapter in the
+  action — see `lunora-setup-hyperdrive`. Bindings codegen can provision on its
+  own (e.g. `BROWSER` for `ctx.browser`) need no manual wrangler step.
+`ctx.browser` and `ctx.sql` are **action-only** by design — they are
+non-deterministic and would break query reactivity and mutation replay.
 ## HTTP endpoints

package/skills/lunora-migration-helper/SKILL.md CHANGED Viewed

@@ -2,7 +2,8 @@
 name: lunora-migration-helper
 description: Plans Lunora schema and data migrations with widen-migrate-narrow. Use for
     breaking schema changes, backfills, table reshaping, online data migrations
-    (`defineMigration` + `lunora migrate up`), the `.global()` D1 SQL flow, and the
+    (`defineMigration` + `lunora migrate up`), the `.global()` D1 / Hyperdrive
+    structural flows, and the
     pre-deploy schema-drift gate.
 ---
@@ -15,7 +16,7 @@ Safely change a Lunora schema and migrate data when making breaking changes.
 - Adding required fields to existing tables.
 - Changing field types or structure.
 - Splitting/merging tables, renaming/removing fields.
-- Reshaping `.global()` (D1-backed) tables.
+- Reshaping `.global()` tables (D1- or Hyperdrive-backed).
 ## When Not to Use
@@ -23,21 +24,35 @@ Safely change a Lunora schema and migrate data when making breaking changes.
 - Adding **optional** fields that need no backfill.
 - Adding new tables or indexes with no correctness concern.
-## Two Storage Layers — Know Which You Are Migrating
+## Storage Layers — Know Which You Are Migrating
-Lunora tables live in one of two backends, and they migrate differently:
+Lunora tables live in one of three backends, and they migrate differently:
 - **ShardDO SQLite (default `root`, and `.shardBy(key)` tables).** State lives in
   the per-app / per-shard Durable Object. Data is reshaped with **online data
   migrations** — `defineMigration` declarations run by `lunora migrate up`,
   resumable per shard.
-- **`.global()` tables (D1).** Replicated to D1 for cross-region reads. Their
-  structural DDL gets versioned **SQL migrations** via `lunora migrate generate`,
-  applied by `@lunora/d1`'s runner at deploy time.
-A breaking change to a `.global()` table needs a generated SQL migration; a data
-backfill (either layer) is an online `defineMigration`. Both follow the same
-**widen → migrate → narrow** discipline.
+- **`.global()` on D1 (the default global backend).** Replicated to D1 for
+  cross-region reads. Structural DDL gets versioned **SQL migrations** via
+  `lunora migrate generate`, applied by `@lunora/d1`'s runner at deploy time.
+- **`.global({ backend: "hyperdrive" })` on Postgres/MySQL.** The same reactive
+  `.global()` contract served over Cloudflare Hyperdrive. Structural DDL works
+  differently here: tables **auto-provision on first use** — the runtime applies
+  the DDL through the dialect — so there is no `lunora migrate generate` step
+  and no versioned SQL file to commit. See `lunora-setup-hyperdrive-global`.
+So: a breaking structural change to a **D1-backed** `.global()` table needs a
+generated SQL migration; the Hyperdrive-backed equivalent provisions itself. A
+data backfill (any layer) is always an online `defineMigration`. All three
+follow the same **widen → migrate → narrow** discipline — check the table's
+backend before assuming which structural path applies.
+> **Moving an existing dataset between global backends.** To move a `.global()`
+> dataset from D1 onto Hyperdrive, use
+> `lunora migrate d1-to-hyperdrive --from-url <d1-worker> --to-url <hd-worker>`
+> (`--tables` scopes it; `--out` keeps the intermediate NDJSON dump). This is a
+> backend move, not a schema change — the widen → migrate → narrow discipline
+> below still governs any reshaping you do on either side of it.
 ## Key Principle: Widen, Migrate, Narrow
@@ -129,7 +144,10 @@ lunora migrate down backfill-display-name      # revert (if `down` defined)
 Useful flags: `--batch-size <n>`, `--steps <n>` (cap batches this run), and
 `--prod --url <worker> --yes` to target production (with `LUNORA_ADMIN_TOKEN`).
-## `.global()` (D1) Structural Migration Flow
+## `.global()` on D1 — Structural Migration Flow
+This flow is **D1-specific**. Hyperdrive-backed globals auto-provision their DDL
+at runtime and skip it entirely.
 ```bash
 # 1. Edit lunora/schema.ts (widen: add the optional new field to the .global() table).
@@ -146,8 +164,8 @@ lunora deploy
 ```
 `lunora migrate generate` only considers `.global()` tables (root/sharded tables
-are not D1-backed). Run it after each schema edit in the widen and narrow steps;
-backfill data with an online migration between them.
+live in ShardDO SQLite, not D1). Run it after each schema edit in the widen and
+narrow steps; backfill data with an online migration between them.
 ## The Schema-Drift Gate
@@ -176,9 +194,10 @@ add the migration — not to bypass it.
    transform before it touches real rows.
 5. **Deleting a field prematurely.** Deprecate with `v.optional` + a comment;
    delete only once nothing references it.
-6. **Migrating the wrong layer.** A `.global()` structural change needs `lunora
-migrate generate` (SQL); a data backfill needs a `defineMigration`. Check the
-   table's `.global()` / `.shardBy()` modifier first.
+6. **Migrating the wrong layer.** A D1-backed `.global()` structural change needs
+   `lunora migrate generate` (SQL); a Hyperdrive-backed one auto-provisions; a
+   data backfill needs a `defineMigration`. Check the table's `.global()` /
+   `.shardBy()` modifier — and, for `.global()`, its `backend` — first.
 ## Checklist

package/skills/lunora-performance-audit/SKILL.md CHANGED Viewed

@@ -2,8 +2,8 @@
 name: lunora-performance-audit
 description: Diagnoses and fixes Lunora performance problems — full-table scans, missing
     indexes, OCC write conflicts, oversized subscriptions, and sharding/`.global()`
-    scaling. Use when queries are slow, mutations conflict, or `@lunora/advisor`
-    flags a table.
+    scaling. Use when queries are slow, mutations conflict, `lunora insights`
+    reports a hot-spot, or `@lunora/advisor` flags a table.
 ---
 # Lunora Performance Audit
@@ -34,12 +34,35 @@ apply it across sibling functions consistently.
 ## Signal Gathering
-Start with the static advisors — they need no traffic:
+### Runtime signal: `lunora insights`
+When the worker is running and has served traffic, start here — it reports the
+measured problem, not a suspected one:
+```bash
+lunora insights                      # against the local dev worker
+lunora insights --shard channel:demo # scope to one shard
+lunora insights --limit 25 --json    # machine-readable, more rows
+lunora insights --prod --url https://app.example.com --token $LUNORA_ADMIN_TOKEN
+```
+It ranks per-function **write-conflict hot-spots** (OCC contention — the
+sharding signal), **error rates**, and **latency outliers**. A function at the
+top of the write-conflict list is the direct input to the OCC section below; a
+latency outlier usually resolves to the read-amplification section.
+The Studio **Issues** panel and `lunora logs` cover the error side in more
+detail once `insights` tells you where to look.
+### Static signal: the advisors
+These need no traffic, so they also work on a cold codebase:
 - **Lunora Studio → Advisors tab** surfaces `@lunora/advisor` findings live in
   dev.
-- `@lunora/advisor` runs static lints over `defineSchema` + discovered query
-  reads / insert writes. Relevant performance/schema rules:
+- `@lunora/advisor` runs ~90 static lints over `defineSchema` + discovered query
+  reads / insert writes (plus a few runtime lints). The performance/schema rules
+  most relevant here:
     - `filter-without-index` — a query filters a table with no covering index.
     - `unindexed-foreign-key` — a relation/FK column has no index.
     - `duplicate-index` / `empty-index` — wasted or malformed indexes.
@@ -75,7 +98,8 @@ column. Fix every sibling query on the table the same way.
 ## Problem Class: Write Conflicts (OCC)
-**Symptom:** mutations on hot rows retry or fail under concurrency. ShardDO uses
+**Symptom:** mutations on hot rows retry or fail under concurrency, or the
+function tops the write-conflict section of `lunora insights`. ShardDO uses
 optimistic concurrency control — concurrent writes to the same DO that touch
 overlapping state conflict and retry.
@@ -115,6 +139,11 @@ cross-region reads (with read-your-writes via the Sessions API). Reserve it for
 read-mostly tables — `.global()` adds the D1 migration flow (see the
 `lunora-migration-helper` skill) and write-path cost.
+If the dataset outgrows D1, `.global({ backend: "hyperdrive" })` serves the same
+reactive `.global()` contract from Postgres/MySQL over Cloudflare Hyperdrive —
+see the `lunora-setup-hyperdrive-global` skill (and `lunora migrate
+d1-to-hyperdrive` to move an existing dataset).
 ### `.shardBy(key)` vs `.global()` — choose one per table
 - `.shardBy(key)`: partitions a table across Durable Objects by key — scales
@@ -135,6 +164,7 @@ read-mostly tables — `.global()` adds the D1 migration flow (see the
 ## Checklist
 - [ ] Scoped one concrete flow; traced every `ctx.db` read/write.
+- [ ] Ran `lunora insights` (if the worker has traffic) for the measured signal.
 - [ ] Checked the Studio Advisors tab / `@lunora/advisor` findings.
 - [ ] Read amplification: replaced `.filter()` with an indexed `.withIndex()`.
 - [ ] Write conflicts: narrowed writes and/or partitioned with `.shardBy(key)`.

package/skills/lunora-quickstart/SKILL.md CHANGED Viewed

@@ -45,28 +45,65 @@ Set up a working Lunora project as fast as possible.
 plugin + `lunora/` already wired together).
 ```bash
-lunora init my-app --template vite
+lunora init my-app --vite react
 cd my-app
 pnpm install
 ```
-### Pick a template
+### Pick a stack: `--vite` (SPA) or `-t` (bespoke template)
-| Template               | Stack                                          |
-| ---------------------- | ---------------------------------------------- |
-| `vite`                 | React + Vite (the simplest full-stack starter) |
-| `standalone`           | Worker-only Lunora backend, no frontend        |
-| `astro`                | Astro integration                              |
-| `next`                 | Next.js (App Router, OpenNext on Cloudflare)   |
-| `nuxt`                 | Nuxt (Vue)                                     |
-| `sveltekit`            | SvelteKit                                      |
-| `tanstack-start-react` | TanStack Start (React)                         |
-| `tanstack-start-solid` | TanStack Start (Solid)                         |
+There are **two scaffold paths**, and they take different flags:
-If the user has not specified a preference, default to `vite`. Pass `--template`
-explicitly to avoid the interactive prompt. Templates are fetched remotely (via
-`giget`) from `gh:anolilab/lunora/templates/<type>`; pass `--from <dir>` to use a
-local template directory offline.
+**`--vite <framework>` — the create-vite overlay.** Fetches the official
+create-vite base and applies the Lunora layer on top. Use it for a plain SPA:
+| `--vite` value | Stack                                           |
+| -------------- | ----------------------------------------------- |
+| `react`        | React SPA (**the default**)                     |
+| `vue`          | Vue SPA                                         |
+| `solid`        | Solid SPA                                       |
+| `svelte`       | Svelte SPA                                      |
+| `vanilla`      | No framework (overlay-only — not in the picker) |
+**`-t` / `--template <type>` — a bespoke Lunora template.** Whole-project
+templates fetched remotely (via `giget`) from
+`gh:anolilab/lunora/templates/<type>`:
+| `-t` value             | Stack                                                      |
+| ---------------------- | ---------------------------------------------------------- |
+| `next`                 | Next.js (App Router, OpenNext on Cloudflare)               |
+| `tanstack-start-react` | TanStack Start (React) — SSR with live-loader routes       |
+| `tanstack-start-solid` | TanStack Start (Solid)                                     |
+| `react-router`         | React Router v7 (framework mode), SSR in the Lunora worker |
+| `astro`                | Astro + a standalone Lunora worker                         |
+| `analog`               | AnalogJS (Angular) — single worker, Lunora in Nitro        |
+| `nuxt`                 | Nuxt (Vue) — single worker, Lunora in Nitro                |
+| `sveltekit`            | SvelteKit + a standalone Lunora worker                     |
+| `expo`                 | React Native (Expo) — iOS/Android/web + a Lunora worker    |
+| `standalone`           | Worker-only Lunora backend, no frontend                    |
+> There is **no `--template vite`.** SPAs go through `--vite <framework>`; `-t`
+> is only for the bespoke templates above.
+With neither flag, an interactive run shows the framework picker (defaulting to
+the React overlay) and a **non-interactive run errors out** — so as an agent,
+always pass `--vite` or `-t` explicitly. If the user stated no preference,
+use `--vite react`.
+### Useful `init` flags
+```bash
+lunora init my-app --vite react --ci github     # + a GitHub Actions deploy pipeline (or --ci gitlab)
+lunora init my-app -t next --add auth,email     # scaffold capabilities non-interactively
+lunora init my-app --vite react --yes           # skip the interactive auth/email offer
+lunora init my-app --vite react --dry-run       # walk every step, write nothing
+```
+`--add` accepts a comma-separated list of `ai | auth | backup | browser |
+cloudflare-access | crons | email | flags | hyperdrive | payment | presence |
+queue | storage | workflow`. `--ref <branch|tag|commit>` pins the template
+source (e.g. `--ref alpha`); `--from <dir>` copies from a local templates root
+offline (expects `<type>/` subdirs).
 ### Generate types and push the first run
@@ -152,9 +189,12 @@ createRoot(document.querySelector("#root")!).render(
 );
 ```
-Vue, Solid, and Svelte have matching providers in `@lunora/vue`, `@lunora/solid`,
-and `@lunora/svelte`. `VITE_LUNORA_URL` is optional — it defaults to
-`location.origin`, which is correct for the single-origin dev setup.
+Every client adapter has a matching provider: `@lunora/vue`, `@lunora/solid`,
+`@lunora/svelte`, `@lunora/angular` (`provideLunora` / `injectLunoraClient`),
+and `@lunora/react-native` (`createLunoraClient`, re-exporting `@lunora/react`).
+For meta-frameworks, `@lunora/astro` and `@lunora/nuxt` mount Lunora on the
+server side. `VITE_LUNORA_URL` is optional — it defaults to `location.origin`,
+which is correct for the single-origin dev setup.
 ## Writing Your First Function
@@ -253,7 +293,8 @@ ids, `.dev.vars` secrets, and container exports.
 ## Checklist
 - [ ] Determined starting point: new project or existing app.
-- [ ] New project: scaffolded with `lunora init --template <t>`.
+- [ ] New project: scaffolded with `lunora init --vite <framework>` (SPA) or
+      `lunora init -t <template>` (bespoke) — never `--template vite`.
 - [ ] Existing app: ran `lunora init --here` and wired `LunoraProvider`.
 - [ ] Ran `lunora codegen`: `lunora/_generated/` exists and typecheck is clean.
 - [ ] Dev server is running — user terminal, or `lunora dev --background`

package/skills/lunora-realtime/SKILL.md CHANGED Viewed

@@ -2,8 +2,8 @@
 name: lunora-realtime
 description: Wires Lunora's live data into a client. Use for `LunoraClient`/`LunoraProvider`,
     reactive `useQuery`/`useSubscription`, `useMutation` with optimistic updates,
-    pagination, connection status, the React/Vue/Solid/Svelte adapters, and the
-    `@lunora/db` TanStack binding.
+    pagination, connection status, the React/Vue/Solid/Svelte/Angular/React Native
+    adapters, and the `@lunora/db` TanStack binding.
 ---
 # Lunora Realtime
@@ -15,7 +15,8 @@ automatic rollback.
 ## When to Use
-- Wiring a frontend to a Lunora backend (React, Vue, Solid, Svelte).
+- Wiring a frontend to a Lunora backend (React, Vue, Solid, Svelte, Angular,
+  React Native/Expo, or an Astro/Nuxt meta-framework).
 - Adding optimistic updates, pagination, or presence to the UI.
 - Choosing between live hooks and the `@lunora/db` collection layer.
@@ -42,6 +43,19 @@ const client = new LunoraClient({ url });
 Vue / Solid / Svelte have matching providers in `@lunora/vue`, `@lunora/solid`,
 `@lunora/svelte`; the hook names and semantics below mirror across them.
+Two adapters differ in shape:
+- **`@lunora/angular`** is signal-based rather than hook-based: register with
+  `provideLunora(...)`, read the client via `injectLunoraClient()`, and use
+  `liveQuery(...)` / `mutate(...)` / `connectionStatus(...)` in place of the
+  hooks below.
+- **`@lunora/react-native`** re-exports all of `@lunora/react` and adds
+  `createLunoraClient` (plus `@lunora/react-native/auth` for the better-auth
+  Expo bridge) — build the client with that instead of `new LunoraClient`.
+For SSR meta-frameworks, `@lunora/astro` and `@lunora/nuxt` compose Lunora into
+the server (Nitro for Nuxt) and ship reactive-loader server helpers.
 ## Live Queries
 `useQuery(reference, args)` opens a subscription and returns the value, or
@@ -67,33 +81,32 @@ const todos = useQuery(api.todos.list, {}) as Doc<"todos">[] | undefined;
 ## Authorization & Live Queries
-Subscriptions re-run the query handler **server-side under anonymous
-identity**. The one-shot `fetch` RPC behind the initial load carries the
-caller's identity, but the live WebSocket channel (the subscription seed and
-every write-driven refresh) does not — it evaluates as anonymous.
-This matters for any query that authorizes or filters on the authenticated
-user:
-- A query guarded by `.use(rls(...))` or one that reads `ctx.auth.userId`
-  directly returns the user's rows on the **initial** HTTP fetch, but its
-  **live** updates evaluate anonymously and may resolve to an empty/denied
-  set.
-- This **fails closed** — the live channel shows _less_ data, never another
-  user's data, so there is no leak. But it is a correctness caveat: the
-  initial render and the live updates can disagree.
-The supported pattern today is to scope per-user data **outside** of
-`ctx.auth` inside a subscribed query:
-- Partition the data by shard with `.shardBy(userId)` (or tenant/room), so the
-  subscription is already scoped to the right state, or
-- Pass the identifier as an **explicit query arg**
-  (`useQuery(api.todos.list, { userId })`) and filter on the arg rather than on
-  `ctx.auth`.
-Reserve `rls()` / `ctx.auth`-based filtering for non-subscribed reads (one-shot
-actions/queries) where identity is always present.
+**Live queries are identity-aware.** At the WebSocket upgrade the runtime
+stamps the caller's verified identity onto the socket (from the server-minted
+`x-lunora-userid` / `x-lunora-identity` headers, which a client cannot forge).
+Every subscription re-run, shape resolution, and poke-driven refresh executes
+under that socket's own identity, passed by value so a concurrent RPC can't
+clobber it.
+Practically, this means:
+- `.use(rls(...))` and `ctx.auth.userId` work the same in a subscribed query as
+  in a one-shot read. Shape subscriptions AND-merge the shape predicate with
+  the table's RLS read base-where, so the membership query the poke protocol
+  runs is RLS-correct by construction — never the client's word for it.
+- An **anonymous** socket carries no identity, so an RLS/`ctx.auth` query fails
+  closed (empty/denied) rather than leaking another user's rows.
+- **Token expiry is enforced on the socket.** When the resolved credential
+  carries an expiry, the DO sends a `TOKEN_EXPIRED` error frame and closes with
+  code `4001` at the next send at or after that instant. `LunoraClient`
+  reconnects automatically and re-resolves a fresh identity — but surface it in
+  the UI if a re-login is required.
+You can still scope data structurally when it fits the domain — `.shardBy(userId)`
+(or tenant/room) partitions state so a subscription is narrow by construction,
+and explicit query args keep subscriptions cheap (see the args-scoping note
+above). Prefer those for _performance_; use `rls()` / `ctx.auth` for
+_authorization_. They compose.
 ## Mutations + Optimistic Updates