@abloatai/ablo 0.7.0 → 0.9.0

package/docs/schema-contract.md

@@ -0,0 +1,111 @@
+# Schema Contract
+
+Ablo's schema is the integration contract. Define it once, pass it to `Ablo(...)`,
+and every actor gets the same typed model surface:
+
+```txt
+defineSchema(...) -> ablo.<model>.create/retrieve/update/claim(...)
+```
+
+That one object drives:
+
+- typed model clients in trusted server runtimes,
+- React selectors through `useAblo((ablo) => ablo.<model>.get(id))`,
+- agent and background-worker writes,
+- Data Source request/response shape when your database stays canonical,
+- hosted schema push, migration planning, and schema-version gating.
+
+## Minimal shape
+
+```ts
+import Ablo from '@abloatai/ablo';
+import { defineSchema, model, z } from '@abloatai/ablo/schema';
+
+export const schema = defineSchema({
+  weatherReports: model({
+    location: z.string(),
+    status: z.enum(['pending', 'ready']),
+    forecast: z.string().optional(),
+  }),
+});
+
+export const ablo = Ablo({
+  schema,
+  apiKey: process.env.ABLO_API_KEY,
+});
+
+await ablo.ready();
+
+const report = await ablo.weatherReports.create({
+  data: {
+    location: 'Stockholm',
+    status: 'pending',
+  },
+});
+```
+
+The model key (`weatherReports`) becomes the client namespace
+(`ablo.weatherReports`). The Zod fields become the create/update/read type
+contract. You should not create a parallel string-keyed write path for the same
+data.
+
+## Reads and writes
+
+Use async reads when the row may not be local:
+
+```ts
+const report = await ablo.weatherReports.retrieve({ id: reportId });
+const ready = await ablo.weatherReports.list({ where: { status: 'ready' } });
+```
+
+Use synchronous local reads in render after data has synced:
+
+```ts
+const report = ablo.weatherReports.get(reportId);
+const pending = ablo.weatherReports.getAll({ where: { status: 'pending' } });
+```
+
+Use model writes for every actor:
+
+```ts
+await ablo.weatherReports.update({ id: reportId, data: { status: 'ready' }, wait: 'confirmed' });
+```
+
+## Coordination
+
+Agents and background jobs often read, call a tool or model, then write later.
+Wrap that slow span in `claim`:
+
+```ts
+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 hands you
+the fresh row. Reads stay open; only acting on the row serializes.
+
+## Storage boundary
+
+Every schema model needs a backing store:
+
+- Use Ablo-managed state when the row can live in Ablo.
+- Use a Data Source when your app database remains canonical.
+
+Do not pass a database URL to `Ablo(...)`. Trusted runtimes use `ABLO_API_KEY`.
+Browser code goes through `<AbloProvider>` or a scoped session route, never a raw
+API key.
+
+## Rules of thumb
+
+- Start with fields and relations before load/index tuning.
+- Import one schema into app code, server actions, agents, and Data Source routes.
+- Keep direct database writes out of the coordinated path unless they are reported
+  back through Data Source events.
+- Use `claim` for slow read -> think -> write spans.
+- Use `readAt` + `onStale: 'reject'` when a write must fail if the row changed
+  after it was read.
+
+For the shortest runnable path, start with [Quickstart](./quickstart.md). For a
+production app, continue with [Integration Guide](./integration-guide.md).

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/README.md

@@ -31,9 +31,13 @@ intentionally cannot import the app schema.
 
 ## Running
 
+Run from the package root, not `examples/` — the `examples/` folder has
+no `package.json`, so Node resolves the entry path against the package
+root and a bare `quickstart.ts` won't be found.
+
 ```bash
-cd packages/sync-engine/examples
-ABLO_API_KEY=sk_test_... npx tsx quickstart.ts
+cd packages/sync-engine
+ABLO_API_KEY=sk_test_... npx tsx examples/quickstart.ts
 ```
 
 ## Data Source (customer-owned database)
@@ -45,8 +49,8 @@ orchestrator drives the customer handler in-process so signer and
 verifier exchange real signed bytes without leaving the process.
 
 ```bash
-cd packages/sync-engine/examples
-npx tsx data-source/run.ts
+cd packages/sync-engine
+npx tsx examples/data-source/run.ts
 ```
 
 See `data-source/README.md` for what each file teaches and the

package/examples/data-source/README.md

@@ -16,10 +16,14 @@ when they want Ablo to coordinate writes against rows stored in
 ## Run
 
 ```bash
-cd packages/sync-engine/examples
-npx tsx data-source/run.ts
+cd packages/sync-engine
+npx tsx examples/data-source/run.ts
 ```
 
+Run from the package root, not `examples/`: the `examples/` folder has
+no `package.json`, so Node resolves the entry path against the package
+root and a bare `data-source/run.ts` won't be found.
+
 No network port, no env vars, no cloud credentials. The orchestrator
 calls the handler in-process. Signer and verifier still exchange
 signed bytes — flip the API key and you'll see a 401.
@@ -34,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
 
@@ -92,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/examples/data-source/run.ts

@@ -1,10 +1,11 @@
 /**
  * End-to-end Data Source demo.
  *
- * Run:
+ * Run (from the package root — the examples/ folder has no package.json
+ * of its own, so Node resolves module paths against the package root):
  *
- *   cd packages/sync-engine/examples
- *   npx tsx data-source/run.ts
+ *   cd packages/sync-engine
+ *   npx tsx examples/data-source/run.ts
  *
  * What this proves:
  *

package/examples/quickstart.ts

@@ -3,7 +3,7 @@
  *
  * Run:
  *
- *   ABLO_API_KEY=sk_test_... npx tsx quickstart.ts
+ *   ABLO_API_KEY=sk_test_... npx tsx examples/quickstart.ts
  */
 
 import Ablo from '@abloatai/ablo';

package/llms.txt

@@ -2,6 +2,8 @@
 
 Ablo is the state coordination layer for apps where humans and agents edit the same data.
 
+Here is the problem it solves. Two writers touch `report_stockholm` at once. The agent claims the row, does slow work (an LLM call, a fetch), and commits; the human's UI sees the claim live and never clobbers it. 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.
+
 Use AI SDK for the agent loop. Use Ablo when agent reads and writes must persist, coordinate with concurrent work, and leave an audit trail.
 
 ## Use this API
@@ -21,7 +23,7 @@ const schema = defineSchema({
 
 const ablo = Ablo({ schema, apiKey: process.env.ABLO_API_KEY });
 
-const [report] = await ablo.weatherReports.load({ where: { id: 'report_stockholm' } });
+const report = await ablo.weatherReports.retrieve('report_stockholm');
 if (!report) throw new Error('Row not found');
 
 const updated = await ablo.weatherReports.claim('report_stockholm', async (report) => {
@@ -33,20 +35,29 @@ const updated = await ablo.weatherReports.claim('report_stockholm', async (repor
 });
 ```
 
-That is the normal app path: declare models in a schema, then use `ablo.<model>.load(...)`, `ablo.<model>.retrieve(...)`, `ablo.<model>.create(...)`, `ablo.<model>.update(...)`, and `ablo.<model>.delete(...)`.
+That is the normal app path: declare models in a schema, then use `ablo.<model>.retrieve(...)`, `ablo.<model>.create(...)`, `ablo.<model>.update(...)`, and `ablo.<model>.delete(...)`.
+
+Treat the schema as the integration contract. It drives typed model clients,
+React selectors, server and agent writes, Data Source request/response shape,
+hosted schema push, and schema-version gating. Do not invent a parallel
+string-keyed write path for rows that belong to a schema model.
 
 For full integrations, use `integration-guide` as the canonical doc. It covers
 the same model API across Ablo-managed state, Data Source-backed app databases,
 React selectors, multiplayer, and future agent workers.
 
-`ablo.<model>.list(...)` and `count(...)` are synchronous local reads. They
-accept `where`, `filter`, `orderBy`, `limit`, `offset`, and `scope`; scope
-defaults to `'live'`, with `'archived'` and `'all'` for lifecycle-aware reads.
+Reads come in two flavors, and you pick by whether you can wait. `retrieve(id)`
+(one row) and `list({ where })` (many) are async — they hit the server and return
+a Promise, so await them. `get(id)`, `getAll({ where })`, and `getCount({ where })`
+are synchronous — they read the local graph and are reactive in render, so no
+await. The query reads accept `where`, `filter`, `orderBy`, `limit`, `offset`,
+and `state`; state defaults to `'live'`, with `'archived'` and `'all'` to include
+retired rows.
 
-Advanced schema-less agents exist for workers that cannot import the app schema,
-but do not teach that path first.
+Workers that can't import the app schema can use a schema-less mode (covered in
+`integration-guide`).
 
-React reads should use selector `useAblo`: `useAblo((ablo) => ablo.weatherReports.retrieve(id))`.
+React reads should use selector `useAblo`: `useAblo((ablo) => ablo.weatherReports.get(id))` (synchronous local read, reactive in render).
 Use zero-argument `useAblo()` only when a component needs the client for an
 event handler or effect. Treat `useQuery`, `useOne`, `useReader`, and
 `useMutate` as compatibility hooks for older string-keyed integrations, not the
@@ -57,7 +68,7 @@ first integration path.
 Multiplayer is not a separate mode. When human UI, server actions, and agents use
 the same schema client and write through `ablo.<model>`, Ablo coordinates the
 shared model stream: confirmed deltas fan out to subscribers, active claims are
-visible through `claimState(id)`, and stale writes can be rejected with `readAt`.
+visible through `claim.state(id)`, and stale writes can be rejected with `readAt`.
 
 If an app writes directly to its own database outside Ablo, that write bypasses
 coordination until the app reports it through Data Source events.
@@ -65,7 +76,7 @@ coordination until the app reports it through Data Source events.
 ## Nouns
 
 - `Model client` is the typed `ablo.<model>` object generated from schema.
-- `Claim` holds a model row while slow work runs; `claimState(id)` observes it.
+- `Claim` holds a model row while slow work runs; `claim.state(id)` observes it.
 - `Commit` is the durable protocol write behind `ablo.<model>.update(...)`.
 - `Receipt` confirms the commit.
 
@@ -76,36 +87,46 @@ Server reads through `ablo.model(name)` can pass `ifClaimed: 'return'` to
 receive active claims, `ifClaimed: 'fail'` to throw `AbloClaimedError`, or
 `ifClaimed: 'wait'` to wait until the active claim clears.
 
-Schema clients wait from the realtime claim stream. Schema-less HTTP callers must provide an explicit `claimedPollInterval` when using `ifClaimed: 'wait'`; Ablo does not hide a hard-coded polling loop.
+Schema clients learn when a claim clears by listening to the live claim stream, so they don't need to poll. Schema-less HTTP callers must provide an explicit `claimedPollInterval` when using `ifClaimed: 'wait'`; Ablo does not hide a hard-coded polling loop.
 
 Use `claimedTimeout` only as a maximum wait, not as the coordination mechanism.
 
 ## Guarantees
 
-`wait: 'confirmed'` means the server accepted the write. Schema model writes are optimistic by default; server rejection rolls back local state. Use `snapshot(...)` plus `readAt` and `onStale: 'reject'` to prevent lost updates.
+`wait: 'confirmed'` means the server accepted the write. Schema model writes are optimistic by default; server rejection rolls back local state. To prevent lost updates, read with `snapshot(...)` to capture a `readAt`, then write with `onStale: 'reject'` — the server rejects your update if someone else changed the row after that `readAt`.
 
 Claims coordinate writers; they do not block readers. Most users should stay on
-schema-backed reads/writes and `claim(...)`; do not teach manual protocol
-bookkeeping in the happy path.
+schema-backed reads/writes and `claim(...)`; manual protocol bookkeeping is not
+part of the happy path.
 
 All SDK errors extend `AbloError`. Important classes: `AbloClaimedError`, `AbloStaleContextError`, `AbloAuthenticationError`, `AbloPermissionError`, `AbloRateLimitError`, `AbloIdempotencyError`, `AbloConnectionError`, `AbloValidationError`, and `AbloServerError`.
 
 ## Schema Scope
 
-Teach schema as model fields and relations first. Advanced schema helpers such as `mutable`, `readOnly`, `field`, `indexed`, queries, and load strategies exist for offline/cache/indexing-heavy apps, but they should not be the first concept a new integration sees.
+A schema is model fields and relations. Advanced schema helpers such as `mutable`, `readOnly`, `field`, `indexed`, queries, and load strategies exist for offline/cache/indexing-heavy apps; reach for them only after the basic field/relation schema is working.
 
 ## Storage Boundary
 
 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,
@@ -132,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`, `integration-guide`, `guarantees`, `client-behavior`, `data-sources`, `examples/existing-python-backend`, `api`, `examples/ai-sdk-tool`, and `examples/server-agent`.
+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.7.0",
+  "version": "0.9.0",
   "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",
@@ -54,6 +54,46 @@
       "types": "./dist/source/index.d.ts",
       "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": [
@@ -118,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": {
@@ -140,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",