@abloatai/ablo 0.8.0 → 0.9.1

package/docs/mcp/claude-code.md

@@ -3,7 +3,7 @@
 ## Install
 
 ```bash
-claude mcp add --transport http ablo-sync https://<your-app>/api/mcp
+claude mcp add --transport http ablo https://<your-app>/api/mcp
 ```
 
 That's it — no token or header needed. The endpoint is public and serves
@@ -18,14 +18,14 @@ In Claude Code, run:
 /mcp list
 ```
 
-You should see `ablo-sync` with the integration tools enumerated:
+You should see `ablo` with the integration tools enumerated:
 `search_ablo_docs`, `get_recipe`, `get_api_surface`, `validate_schema`,
 `scaffold_app`.
 
 ## Removing
 
 ```bash
-claude mcp remove ablo-sync
+claude mcp remove ablo
 ```
 
 ## More

package/docs/mcp/cursor.md

@@ -7,7 +7,7 @@ Add the Ablo Sync MCP server to Cursor's `mcp.json`:
 ```json
 {
   "mcpServers": {
-    "ablo-sync": {
+    "ablo": {
       "transport": "http",
       "url": "https://<your-app>/api/mcp"
     }

package/docs/mcp/windsurf.md

@@ -7,7 +7,7 @@ Add the Ablo Sync MCP server to Windsurf's MCP config:
 ```json
 {
   "mcpServers": {
-    "ablo-sync": {
+    "ablo": {
       "transport": "http",
       "url": "https://<your-app>/api/mcp"
     }
@@ -22,7 +22,7 @@ the endpoint is public and serves only docs, schema lint, and scaffolds.
 ## Verify
 
 Cascade's MCP panel lists every configured server with its tools. You
-should see `ablo-sync` with the integration tools enumerated:
+should see `ablo` with the integration tools enumerated:
 `search_ablo_docs`, `get_recipe`, `get_api_surface`, `validate_schema`,
 `scaffold_app`.
 

package/docs/mcp.md

@@ -33,10 +33,10 @@ Each tool mirrors an SDK verb, scoped to a model + id:
 |---|---|---|
 | `get_model` | `ablo.<model>.get(id)` | read latest state + active claims |
 | `list_models` | `ablo.<model>.list({…})` | cursor-paginated list with filters |
-| `create_model` | `ablo.<model>.create(data)` | guarded create |
-| `update_model` | `ablo.<model>.update(id, …)` | guarded update |
-| `delete_model` | `ablo.<model>.delete(id)` | guarded delete |
-| `claim_model` | `ablo.<model>.claim(id)` | acquire / queue a coordination lease |
+| `create_model` | `ablo.<model>.create({ data })` | guarded create |
+| `update_model` | `ablo.<model>.update({ id, … })` | guarded update |
+| `delete_model` | `ablo.<model>.delete({ id })` | guarded delete |
+| `claim_model` | `ablo.<model>.claim({ id })` | acquire / queue a coordination lease |
 | `release_claim` | — | release the lease so others proceed |
 
 The agent-facing contract — the safe loop, the "derive idempotency keys from
@@ -64,7 +64,7 @@ server above, never here.
 Point your assistant at the hosted endpoint — no auth, no token:
 
 ```bash
-claude mcp add --transport http ablo-sync https://<your-app>/api/mcp
+claude mcp add --transport http ablo https://<your-app>/api/mcp
 ```
 
 Per-client walkthroughs:
@@ -87,7 +87,7 @@ Per-client walkthroughs:
 
 #### Resources
 
-Every doc file is addressable at `ablo-sync-engine://docs/{name}`, so a
+Every doc file is addressable at `ablo://docs/{name}`, so a
 client can list the corpus and fetch individual files on demand instead of
 loading everything into context.
 

package/docs/quickstart.md

@@ -41,13 +41,18 @@ export const ablo = Ablo({
 await ablo.ready();
 
 const created = await ablo.weatherReports.create({
-  location: 'Stockholm',
-  status: 'pending',
+  data: {
+    location: 'Stockholm',
+    status: 'pending',
+  },
 });
 
-const updated = await ablo.weatherReports.update(created.id, {
-  status: 'ready',
-  forecast: 'Light rain, 13C',
+const updated = await ablo.weatherReports.update({
+  id: created.id,
+  data: {
+    status: 'ready',
+    forecast: 'Light rain, 13C',
+  },
 });
 
 console.log({ id: updated.id, status: updated.status });
@@ -69,40 +74,45 @@ ABLO_API_KEY=sk_test_... npx tsx examples/quickstart.ts
 ## Add coordination for slow work
 
 When AI or background work will touch an existing row for more than a quick
-write, coordinate through `claim(id, work)`. It claims the row and hands the row
-back; `claim.state(id)` reads who is currently working on it without blocking;
-and you write the usual way with `ablo.<model>.update(id, ...)`.
+write, coordinate through `claim({ id })`. It claims the row and hands a handle
+back; `claim.state({ id })` reads who is currently working on it without blocking;
+and you write the usual way with `ablo.<model>.update({ id, data })`.
 
 Claims don't lock. If another writer holds the row, `claim` waits for them,
 re-reads the fresh row, then hands it to you — so two writers serialize instead
 of clobbering. Normal reads still work while the claim is held. If a server read
 should not return a row while someone else is mid-edit, pass `ifClaimed: 'wait'`
-to wait for the claim to clear, or `ifClaimed: 'fail'` to error out instead. The
-callback form releases the claim when the callback returns or throws.
+to wait for the claim to clear, or `ifClaimed: 'fail'` to error out instead.
+Call `handle.release()` when your work is done.
 
 ```ts
 // Claim the row so other participants serialize behind us while we work.
-await ablo.weatherReports.claim(
-  'weather_stockholm',
-  async (report) => {
-    // Your existing weather tool or agent call. While this runs, other clients
-    // see that weather_stockholm is being checked.
-    const weather = await weatherAgent.getWeather(report.location);
-
-    await ablo.weatherReports.update(report.id, {
-      status: 'ready',
-      forecast: weather.summary,
-    });
+const handle = await ablo.weatherReports.claim({
+  id: 'weather_stockholm',
+  action: 'checking_weather',
+  ttl: '2m',
+});
+
+// Your existing weather tool or agent call. While this runs, other clients
+// see that weather_stockholm is being checked.
+const weather = await weatherAgent.getWeather(handle.data.location);
+
+await ablo.weatherReports.update({
+  id: handle.data.id,
+  data: {
+    status: 'ready',
+    forecast: weather.summary,
   },
-  { action: 'checking_weather', ttl: '2m' },
-);
+});
+
+await handle.release();
 ```
 
 Ablo does not fetch the weather. If another participant already holds the row,
 `claim` waits for them to finish, re-reads, and then hands you the fresh row.
-While you hold the claim, `update(id, ...)` rejects with `AbloStaleContextError`
+While you hold the claim, `update({ id, data })` rejects with `AbloStaleContextError`
 if someone else changed the row first — so you never overwrite work you didn't
-see. The claim releases automatically once the callback returns or throws.
+see. Call `handle.release()` once your work is done.
 
 ## Multiplayer and claimed work
 
@@ -110,19 +120,19 @@ There is no separate multiplayer mode. Use the same schema client for human UI,
 server actions, and agents; Ablo fans out confirmed writes and keeps active
 claims visible on the same model row.
 
-`claim.state(id)` tells you when another human or agent is active on the same row.
-For schema clients, `claim(id, work)` waits fairly, re-reads, and then lets you
+`claim.state({ id })` tells you when another human or agent is active on the same row.
+For schema clients, `claim({ id })` waits fairly, re-reads, and then lets you
 write through the model.
 
 ```ts
-const active = ablo.weatherReports.claim.state('weather_stockholm');
+const active = ablo.weatherReports.claim.state({ id: 'weather_stockholm' });
 if (active) {
   console.log(`${active.heldBy} is ${active.action}`);
 }
 
-await ablo.weatherReports.claim('weather_stockholm', async (report) => {
-  await ablo.weatherReports.update(report.id, { status: 'ready' });
-});
+const handle = await ablo.weatherReports.claim({ id: 'weather_stockholm' });
+await ablo.weatherReports.update({ id: handle.data.id, data: { status: 'ready' } });
+await handle.release();
 ```
 
 Use `{ wait: false }` on `claim` when work should be skipped instead of queued

package/docs/react.md

@@ -75,7 +75,7 @@ import { useAblo } from '@abloatai/ablo/react';
 
 export function ReportView({ report: serverReport }: { report: { id: string; location: string } }) {
   const report = useAblo((ablo) => ablo.weatherReports.get(serverReport.id)) ?? serverReport;
-  const active = useAblo((ablo) => ablo.weatherReports.claim.state(serverReport.id));
+  const active = useAblo((ablo) => ablo.weatherReports.claim.state({ id: serverReport.id }));
   const claimed = Boolean(active);
 
   return <article>{report.location}</article>;
@@ -90,7 +90,7 @@ The hook:
    deltas arrive.
 3. Lets Server Component data stay outside the hook: use `?? serverReport` when a
    parent already loaded the row.
-4. Works for coordination state too, such as `ablo.weatherReports.claim.state(id)`.
+4. Works for coordination state too, such as `ablo.weatherReports.claim.state({ id })`.
 
 Use the zero-argument form only when you need the full client for callbacks,
 effects, or writes:
@@ -117,12 +117,12 @@ const reports = useAblo((ablo) =>
 ## Server Load
 
 ```tsx
-const report = await ablo.weatherReports.retrieve(id);
+const report = await ablo.weatherReports.retrieve({ id });
 ```
 
 Use `retrieve` in Server Components when the row may not be in the local pool
 yet — it hydrates from the local store and the server, and returns a Promise, so
-`await` it. (Server reads come in two shapes: `retrieve(id)` for one row and
+`await` it. (Server reads come in two shapes: `retrieve({ id })` for one row and
 `list({ where })` for many; both are async. The synchronous local reads are
 `get`/`getAll`/`getCount`, used in render below.)
 
@@ -134,7 +134,9 @@ For Server Actions and route handlers, call the SDK directly:
 import { ablo } from '@/lib/ablo';
 
 const snap = ablo.snapshot({ weatherReports: id });
-await ablo.weatherReports.update(id, patch, {
+await ablo.weatherReports.update({
+  id,
+  data: patch,
   readAt: snap.stamp,
   onStale: 'reject',
   wait: 'confirmed',
@@ -150,11 +152,13 @@ const ablo = useAblo();
 async function markReady() {
   if (!ablo) return;
   const snap = ablo.snapshot({ weatherReports: id });
-  await ablo.weatherReports.update(
+  await ablo.weatherReports.update({
     id,
-    { status: 'ready' },
-    { readAt: snap.stamp, onStale: 'reject', wait: 'confirmed' },
-  );
+    data: { status: 'ready' },
+    readAt: snap.stamp,
+    onStale: 'reject',
+    wait: 'confirmed',
+  });
 }
 ```
 

package/docs/schema-contract.md

@@ -37,8 +37,10 @@ export const ablo = Ablo({
 await ablo.ready();
 
 const report = await ablo.weatherReports.create({
-  location: 'Stockholm',
-  status: 'pending',
+  data: {
+    location: 'Stockholm',
+    status: 'pending',
+  },
 });
 ```
 
@@ -52,7 +54,7 @@ data.
 Use async reads when the row may not be local:
 
 ```ts
-const report = await ablo.weatherReports.retrieve(reportId);
+const report = await ablo.weatherReports.retrieve({ id: reportId });
 const ready = await ablo.weatherReports.list({ where: { status: 'ready' } });
 ```
 
@@ -66,7 +68,7 @@ const pending = ablo.weatherReports.getAll({ where: { status: 'pending' } });
 Use model writes for every actor:
 
 ```ts
-await ablo.weatherReports.update(reportId, { status: 'ready' }, { wait: 'confirmed' });
+await ablo.weatherReports.update({ id: reportId, data: { status: 'ready' }, wait: 'confirmed' });
 ```
 
 ## Coordination
@@ -75,14 +77,14 @@ Agents and background jobs often read, call a tool or model, then write later.
 Wrap that slow span in `claim`:
 
 ```ts
-await ablo.weatherReports.claim(reportId, async (report) => {
-  const forecast = await getForecast(report.location);
-  await ablo.weatherReports.update(report.id, { status: 'ready', forecast });
-});
+const handle = await ablo.weatherReports.claim({ id: reportId });
+const forecast = await getForecast(handle.data.location);
+await ablo.weatherReports.update({ id: handle.data.id, data: { status: 'ready', forecast } });
+await handle.release();
 ```
 
-If another writer already holds the row, `claim` waits, re-reads, and gives your
-callback the fresh row. Reads stay open; only acting on the row serializes.
+If another writer already holds the row, `claim` waits, re-reads, and hands you
+the fresh row. Reads stay open; only acting on the row serializes.
 
 ## Storage boundary
 

package/docs/the-loop.md

@@ -0,0 +1,21 @@
+# The loop: how your data flows
+
+This explainer moved to the canonical, maintained docs:
+
+**→ https://abloatai.com/docs/webhooks**
+
+The short version: Ablo has the same two-sided shape as Stripe — **you call Ablo to make changes (the client), and Ablo calls you to persist them (a signed webhook)** — plus realtime sync to every connected client.
+
+```
+your app ──write──▶  Ablo (hosted)  ──realtime sync──▶  other clients
+ (the client)        the transaction log               (live, optimistic)
+                            │
+                            └──signed event──▶  /api/ablo/[...all]  ──▶  YOUR database
+                                                (the webhook route)
+```
+
+Ablo owns the ordered transaction log (the source of truth); your database is a
+materialized copy you keep via the webhook. See the link above for the full
+guide: scaffolding the handler (`ablo init`), local testing (`ablo dev`),
+registering an endpoint (`ablo webhooks create`), signature verification, the
+delivery/retry model, and best practices.

package/examples/data-source/README.md

@@ -38,9 +38,9 @@ signed bytes — flip the API key and you'll see a 401.
 3. **The customer DB stays canonical.** Ablo never sees rows
    directly; it only sees the response payload from the customer's
    handler.
-4. **The outbox feed.** Writes that bypass Ablo (cron, dashboards,
-   batch imports) show up on the next `events` poll so Ablo can fan
-   them out to connected clients.
+4. **The outbox feed.** Every committed app-row change gets an outbox marker.
+   Ablo filters markers for commits it already appended and uses the same feed
+   to repair a failed post-commit append.
 
 ## Production wiring
 
@@ -96,8 +96,7 @@ data layer. The handler shape stays the same:
 - `tasks.load({ id })` -> `db.task.findUnique({ where: { id } })`
 - `tasks.list({ query })` -> `db.task.findMany({ take, cursor })`
 - `tasks.commit({ operations, clientTxId })` -> `db.$transaction` that
-  applies each `op` and tags the row with `clientTxId` for idempotent
-  retries
+  applies each `op` and writes an outbox marker with `clientTxId` before commit
 - `events({ cursor, limit })` -> read from your outbox table, return
   rows with their `clientTxId` (Ablo dedupes its own commits) and the
   resume cursor

package/examples/data-source/customer-server.ts

@@ -15,7 +15,7 @@
  * inside a transaction. The shape of the handlers stays identical.
  */
 
-import Ablo, { dataSource } from '@abloatai/ablo';
+import Ablo, { dataSource, sourceEventForOperation } from '@abloatai/ablo';
 import { schema } from './schema';
 
 type TaskRow = {
@@ -29,16 +29,10 @@ type TaskRow = {
 const taskStore = new Map<string, TaskRow>();
 
 // Outbox table. In production this is a `tasks_outbox` Postgres table
-// populated by triggers or service code. Ablo polls `events` to fan
-// out changes that didn't originate from an Ablo commit.
-type OutboxRow = {
-  id: string;
-  entityId: string;
-  type: Ablo.Source.Operation['type'];
-  data: TaskRow | null;
-  clientTxId?: string;
-};
-const outbox: OutboxRow[] = [];
+// populated in the same transaction as the app-row write. Ablo polls `events`
+// to fan out changes that bypassed Ablo, and to repair SDK-origin writes if
+// Ablo's immediate post-commit append failed.
+const outbox: Ablo.Source.Event[] = [];
 let outboxSequence = 0;
 
 // Seed one row so the example's first `load` returns something.
@@ -132,19 +126,14 @@ export const handleAbloSource = dataSource({
     const start = cursor ? Number(cursor) : 0;
     const cap = limit ?? 100;
     const slice = outbox.slice(start, start + cap);
-    const events = slice.map((row) => ({
-      id: row.id,
-      model: 'tasks',
-      entityId: row.entityId,
-      type: row.type,
-      data: row.data,
-      ...(row.clientTxId ? { clientTxId: row.clientTxId } : {}),
-    }));
     const nextCursor =
       start + slice.length < outbox.length
         ? String(start + slice.length)
         : undefined;
-    return { events, ...(nextCursor !== undefined ? { nextCursor } : {}) };
+    return {
+      events: slice,
+      ...(nextCursor !== undefined ? { nextCursor } : {}),
+    };
   },
 });
 
@@ -166,7 +155,7 @@ function applyOperation(
         : {}),
     };
     taskStore.set(id, row);
-    appendOutbox({ entityId: id, type: 'CREATE', data: row, clientTxId });
+    appendOutbox({ operation: op, entityId: id, data: row, clientTxId });
     return row;
   }
 
@@ -175,7 +164,7 @@ function applyOperation(
     if (!existing) return null;
     const next: TaskRow = { ...existing, ...(op.input as Partial<TaskRow>) };
     taskStore.set(id, next);
-    appendOutbox({ entityId: id, type: 'UPDATE', data: next, clientTxId });
+    appendOutbox({ operation: op, entityId: id, data: next, clientTxId });
     return next;
   }
 
@@ -183,16 +172,29 @@ function applyOperation(
     const existing = taskStore.get(id);
     if (!existing) return null;
     taskStore.delete(id);
-    appendOutbox({ entityId: id, type: 'DELETE', data: null, clientTxId });
+    appendOutbox({ operation: op, entityId: id, data: null, clientTxId });
     return existing;
   }
 
   return null;
 }
 
-function appendOutbox(input: Omit<OutboxRow, 'id'>): void {
+function appendOutbox(input: {
+  operation: Ablo.Source.Operation;
+  entityId: string;
+  data: TaskRow | null;
+  clientTxId: string | undefined;
+}): void {
   outboxSequence += 1;
-  outbox.push({ id: `evt_${outboxSequence}`, ...input });
+  outbox.push(
+    sourceEventForOperation({
+      eventId: `evt_${outboxSequence}`,
+      operation: input.operation,
+      entityId: input.entityId,
+      data: input.data,
+      ...(input.clientTxId ? { clientTxId: input.clientTxId } : {}),
+    }),
+  );
 }
 
 // Exposed for the orchestrator's `run.ts`. A real customer doesn't

package/llms.txt

@@ -109,14 +109,24 @@ A schema is model fields and relations. Advanced schema helpers such as `mutable
 
 Do not add `databaseURL` to `Ablo(...)`. Application and agent code use `ABLO_API_KEY`.
 
-Every schema model has a backing store. By default, Ablo stores rows for declared models, so `ablo.<model>.create/update/delete` write to Ablo-managed state. If the customer database is canonical, expose a Data Source endpoint and pass `apiKey: process.env.ABLO_API_KEY` to `dataSource({ schema, apiKey, load, list, commit, events })`. Customer-owned app database credentials stay private.
-
-Use `dataSource` from the root import:
+Every schema model has a backing store. By default, Ablo stores rows for declared models, so `ablo.<model>.create/update/delete` write to Ablo-managed state. If the customer database is canonical, expose a Data Source endpoint. With Prisma or Drizzle this is ONE line — pass an ORM `adapter` and it owns the transaction, idempotency, and outbox (no hand-written `commit`/`events`):
 
 ```ts
-import { dataSource } from '@abloatai/ablo';
+// app/api/ablo/source/route.ts
+import { dataSourceNext } from '@abloatai/ablo/source/next';
+import { prismaDataSource } from '@abloatai/ablo/source';
+import { schema } from '@/ablo/schema';
+import { prisma } from '@/lib/prisma';
+
+export const { POST } = dataSourceNext({
+  schema,
+  apiKey: process.env.ABLO_API_KEY!,
+  adapter: prismaDataSource(prisma, schema), // or drizzleDataSource(db, tables)
+});
 ```
 
+`npx ablo init` generates this file for you (see CLI below). Customer-owned app database credentials stay private — Ablo only calls the endpoint.
+
 ## Sandboxes
 
 Public `/sandbox` is a deterministic visual demo. It should teach shared state,
@@ -143,7 +153,20 @@ Import from these public paths only:
 - `@abloatai/ablo/schema` — schema DSL.
 - `@abloatai/ablo/react` — React provider and hooks.
 - `@abloatai/ablo/testing` — test harnesses and mocks.
+- `@abloatai/ablo/source` — `dataSource`, the `DataSourceAdapter` spine, `prismaDataSource`. For a customer-canonical Data Source endpoint.
+- `@abloatai/ablo/source/next` — `dataSourceNext` (Next.js App Router `{ POST }`).
+- `@abloatai/ablo/source/drizzle` — `drizzleDataSource`.
+- `@abloatai/ablo/source/conformance` — `runDataSourceTests` to prove a custom adapter/handler.
+
+Do not teach `/api`, `/agent`, `/ai-sdk`, `/core`, `/realtime`, or internal subpaths. (`/source` IS public — it's the Data Source endpoint surface above.)
+
+## CLI — agents run it NON-INTERACTIVELY
+
+`ablo init` and other prompts need a TTY; an agent/CI run has none and will HANG. Always:
 
-Do not teach `/api`, `/agent`, `/ai-sdk`, `/core`, `/realtime`, `/source`, or internal subpaths.
+- `npx ablo init --yes` (flags: `--framework`, `--auth`, `--storage`, `--no-agent`, `--no-pull`, `--no-install`, `--no-login`). Generates `ablo/schema.ts` + the `ablo/data-source.ts` endpoint above.
+- Authenticate with the `ABLO_API_KEY` env var. Do NOT run `ablo login` (opens a browser).
+- Adopt an existing DB: `npx ablo pull prisma [path]` / `npx ablo pull drizzle <module>`.
+- `npx ablo dev --no-watch` (default watches forever); `npx ablo logs --no-follow` (default tails forever); `npx ablo mode test|live` (always pass the arg). `npx ablo push`/`status`/`pull`/`check`/`generate` are one-shot.
 
 Canonical docs to read before integrating: `quickstart`, `schema-contract`, `integration-guide`, `guarantees`, `client-behavior`, `data-sources`, `examples/existing-python-backend`, `api`, `examples/ai-sdk-tool`, and `examples/server-agent`.

package/package.json

@@ -1,11 +1,11 @@
 {
   "name": "@abloatai/ablo",
-  "version": "0.8.0",
+  "version": "0.9.1",
   "description": "State control API for AI agents and collaborative apps.",
   "license": "Apache-2.0",
   "type": "module",
   "engines": {
-    "node": ">=22.0.0"
+    "node": ">=24.0.0"
   },
   "main": "./dist/index.js",
   "types": "./dist/index.d.ts",
@@ -55,10 +55,45 @@
       "import": "./dist/source/index.js",
       "default": "./dist/source/index.js"
     },
+    "./source/conformance": {
+      "types": "./dist/source/conformance.d.ts",
+      "import": "./dist/source/conformance.js",
+      "default": "./dist/source/conformance.js"
+    },
+    "./source/drizzle": {
+      "types": "./dist/source/adapters/drizzle.d.ts",
+      "import": "./dist/source/adapters/drizzle.js",
+      "default": "./dist/source/adapters/drizzle.js"
+    },
+    "./source/next": {
+      "types": "./dist/source/next.d.ts",
+      "import": "./dist/source/next.js",
+      "default": "./dist/source/next.js"
+    },
     "./keys": {
       "types": "./dist/keys/index.d.ts",
       "import": "./dist/keys/index.js",
       "default": "./dist/keys/index.js"
+    },
+    "./wire": {
+      "types": "./dist/wire/index.d.ts",
+      "import": "./dist/wire/index.js",
+      "default": "./dist/wire/index.js"
+    },
+    "./server": {
+      "types": "./dist/server/index.d.ts",
+      "import": "./dist/server/index.js",
+      "default": "./dist/server/index.js"
+    },
+    "./server/next": {
+      "types": "./dist/server/next.d.ts",
+      "import": "./dist/server/next.js",
+      "default": "./dist/server/next.js"
+    },
+    "./webhooks": {
+      "types": "./dist/webhooks/index.d.ts",
+      "import": "./dist/webhooks/index.js",
+      "default": "./dist/webhooks/index.js"
     }
   },
   "files": [
@@ -123,11 +158,15 @@
     "url": "https://github.com/Abloatai/ablo/issues"
   },
   "peerDependencies": {
-    "react": "^19.0.0"
+    "react": "^19.0.0",
+    "drizzle-orm": ">=0.30.0"
   },
   "peerDependenciesMeta": {
     "react": {
       "optional": true
+    },
+    "drizzle-orm": {
+      "optional": true
     }
   },
   "dependencies": {
@@ -145,6 +184,7 @@
     "@testing-library/react": "^16.0.0",
     "@testing-library/jest-dom": "^6.6.0",
     "ai": "^6.0.0",
+    "drizzle-orm": "^0.45.2",
     "fake-indexeddb": "^6.0.0",
     "fast-check": "^3.0.0",
     "jest": "^29.7.0",