@abloatai/ablo 0.3.0

package/docs/api.md

@@ -0,0 +1,230 @@
+# API
+
+Start with the schema client:
+
+For end-to-end app setup across React, existing backends, Data Source, and
+agents, read [Integration Guide](./integration-guide.md).
+
+
+```ts
+import Ablo from '@ablo/sync-engine';
+import { defineSchema, model, z } from '@ablo/sync-engine/schema';
+
+const schema = defineSchema({
+  tasks: model({
+    title: z.string(),
+    status: z.enum(['todo', 'doing', 'done']),
+  }),
+});
+
+const ablo = Ablo({ schema, apiKey: process.env.ABLO_API_KEY });
+
+await ablo.ready();
+const [task] = await ablo.tasks.load({ where: { id: 'task_123' } });
+if (!task) throw new Error('Task not found');
+
+await ablo.tasks.update('task_123', { status: 'done' }, { wait: 'confirmed' });
+```
+
+## Model Methods
+
+Each schema model becomes a typed resource on the client:
+
+- `ablo.tasks.load({ where })` hydrates rows asynchronously.
+- `ablo.tasks.retrieve(id)` reads one already-loaded row synchronously.
+- `ablo.tasks.create(data)` creates a row.
+- `ablo.tasks.update(id, data, options?)` updates a row.
+- `ablo.tasks.delete(id, options?)` deletes a row.
+
+`load` and `retrieve` are not aliases. Use `load` when the row may not be in the
+local pool yet. Use `retrieve` after `ready()` or `load()` when you want a cheap
+local read.
+
+| Method | Returns | Use when |
+|---|---|---|
+| `load({ where })` | `Promise<T[]>` | You need to hydrate rows from local store and server. |
+| `retrieve(id)` | `T \| undefined` | You already loaded the row and want a synchronous local read. |
+| `list(options?)` | `T[]` | You want a synchronous local list. |
+| `count(options?)` | `number` | You want a synchronous local count. |
+| `create(data, options?)` | `Promise<T>` | You want to create through the schema model. |
+| `update(id, data, options?)` | `Promise<T>` | You want to update through the schema model. |
+| `delete(id, options?)` | `Promise<void>` | You want to delete through the schema model. |
+
+`list` and `count` read the local pool. They default to live rows and accept:
+
+```ts
+const activeDoneTasks = ablo.tasks.list({
+  where: { status: 'done' },
+  filter: (task) => !task.title.startsWith('[archived]'),
+  orderBy: { updatedAt: 'desc' },
+  limit: 20,
+  scope: 'live', // 'live' | 'archived' | 'all'
+});
+```
+
+## Protected Writes
+
+Use `snapshot` when a write should reject if the row changed mid-flight:
+
+```ts
+const snap = ablo.snapshot({ tasks: 'task_123' });
+
+await ablo.tasks.update(
+  'task_123',
+  { status: 'done' },
+  { readAt: snap.stamp, onStale: 'reject', wait: 'confirmed' },
+);
+```
+
+Protected write options:
+
+| Option | Purpose |
+|---|---|
+| `readAt` | The state cursor the write was based on. |
+| `onStale` | Stale-state policy. Prefer `reject` for agent writes. |
+| `intent` | Active work claim associated with the write. |
+| `wait` | `queued` resolves after local queueing; `confirmed` waits for server acceptance. |
+| `idempotencyKey` | Stable key for retry-safe writes. The SDK generates one when omitted. |
+| `timeout` | Maximum time to wait for the write call. |
+
+## Advanced Resource API
+
+Use `resource(name)` only when you intentionally need the raw protocol shape:
+generic server runtimes, MCP routes, batch tools, or code that has no schema.
+
+```ts
+const tasks = ablo.resource<{ status: string }>('tasks');
+
+const { data, stamp, intents } = await tasks.retrieve('task_123', {
+  ifBusy: 'return',
+});
+```
+
+`stamp` is the state watermark. Pass it as `readAt` to reject stale writes.
+
+`intents` lists active work on the target. Set `ifBusy: 'wait'` to wait for
+that work to clear, or `ifBusy: 'fail'` to throw `AbloBusyError`.
+
+## Intent
+
+Intent is the coordination signal. It tells humans and agents who is working on
+a target before the write lands.
+
+```ts
+const intent = await ablo.intents.create({
+  target: { resource: 'tasks', id: 'task_123', field: 'status' },
+  action: 'update',
+});
+
+try {
+  const snap = ablo.snapshot({ tasks: 'task_123' });
+  const task = await ablo.tasks.update(
+    'task_123',
+    { status: 'done' },
+    { intent, readAt: snap.stamp, onStale: 'reject', wait: 'confirmed' },
+  );
+
+  task.status; // done
+} finally {
+  await intent.release();
+}
+```
+
+`intents.waitFor(target)` waits until the live intent stream clears. Pass
+`timeout` only when your product needs an upper bound.
+
+## Advanced Commit API
+
+Most callers use `ablo.<model>.update(...)` or `resource.update(...)`. For atomic
+batches or custom runtimes, use `commits.create`.
+
+```ts
+await ablo.commits.create({
+  wait: 'confirmed',
+  operations: [
+    {
+      action: 'update',
+      resource: 'tasks',
+      id: 'task_123',
+      data: { status: 'done' },
+      readAt: stamp,
+      onStale: 'reject',
+    },
+  ],
+});
+```
+
+Every state change becomes a commit. Commits check authorization, stale state,
+intent conflicts, and idempotency.
+
+## Agent
+
+Most agents should import the same schema as the app and call
+`ablo.<model>.load(...)` plus `ablo.<model>.update(...)`. The schema-less
+`agent.run(...)` wrapper exists for advanced server workers that cannot import
+the app schema; it creates the capability and task internally and returns
+`done`, `failed`, or `cancelled`.
+
+## Data Source
+
+Use `dataSource(...)` only when the customer's app database remains canonical
+and Ablo should call a signed endpoint instead of storing customer rows itself.
+
+```ts
+import { dataSource } from '@ablo/sync-engine';
+import { schema } from './ablo.schema';
+
+export const POST = dataSource({
+  schema,
+  signingSecret: process.env.ABLO_DATA_SOURCE_SIGNING_SECRET,
+  async commit({ operations, clientTxId, context }) {
+    // Write operations to the customer's database transaction.
+    return { rows: [] };
+  },
+});
+```
+
+The SDK still uses `ablo.<model>.update(...)`. The Data Source endpoint is a
+server-to-server storage adapter. See [Connect Your Database](./data-sources.md).
+
+## Capability
+
+Capabilities are the lower-level permission boundary. Most apps should let
+`agent.run(...)` create and revoke them.
+
+```ts
+const capability = await api.capabilities.create({
+  participantKind: 'agent',
+  participantId: 'agent:task-writer',
+  // Strings derive from the schema's `identityRoles` templates
+  // (see integration-guide.md §1) or a model's `syncGroupFormat`.
+  syncGroups: ['org:acme', 'user:agent:task-writer'],
+  operations: ['tasks.retrieve', 'tasks.update'],
+  lease: '10m',
+});
+```
+
+Use `lease` as a crash cleanup window. Normal agent runs still close when the
+handler returns, fails, or is cancelled.
+
+For the design rationale — why capabilities instead of static API keys,
+why the lease + signature + revocation triple, and how this maps to AWS
+STS / Vault / Auth0 Token Vault — see [Capabilities](./capabilities.md#why-capabilities-not-api-keys).
+
+## Errors
+
+All SDK errors extend `AbloError` and expose a stable `type` string.
+
+| Error | Meaning |
+|---|---|
+| `AbloAuthenticationError` | Missing, invalid, or expired credential. |
+| `AbloPermissionError` | Credential is valid but the action is outside scope. |
+| `AbloRateLimitError` | Rate limit or quota exceeded. |
+| `AbloIdempotencyError` | Idempotency key was reused with a different request. |
+| `AbloConnectionError` | Network, timeout, abort, or transport failure. |
+| `AbloValidationError` | Invalid input. |
+| `AbloServerError` | Server-side 5xx. |
+| `AbloStaleContextError` | `readAt` no longer matches current state. |
+| `AbloBusyError` | Active intent conflict or busy wait timeout. |
+
+See [Client Behavior](./client-behavior.md) for retry and timeout guidance.

package/docs/audit.md

@@ -0,0 +1,81 @@
+# Audit log
+
+Every commit becomes one row. Rows are hash-chained per principal —
+tamper-evident, queryable, exportable.
+
+## Row shape
+
+```ts
+{
+  occurredAt:           '2026-05-14T14:22:01.034Z',
+  actorKind:            'user' | 'agent' | 'system',
+  actorId:              string,
+  onBehalfOfKind:       'user' | 'agent' | 'system' | null,
+  onBehalfOfId:         string | null,
+  capabilityId:         string | null,
+  capabilityLabel:      string | null,
+  delegationChainRoot:  string | null,    // always points at a human
+  causedByTaskId:       string | null,
+  actionType:           string,           // e.g. 'task.update'
+  modelName:            string | null,    // e.g. 'claude-opus-4-7'
+  diffSummary:          unknown,
+  // tamper-evident
+  chainSeq:             number,
+  prevHash:             string,
+  rowHash:              string,
+}
+```
+
+## Delegation chain
+
+`delegationChainRoot` always points at the human who started the chain.
+There is no audit row whose root is an agent. Autonomous AI writes are not
+a thing in this system; every chain starts with a person.
+
+## Verify
+
+```bash
+curl https://<your-app>/api/orgs/<slug>/audit/verify-chain?\
+  principalKind=agent\
+  &principalId=task-writer-v3
+```
+
+Returns either:
+
+```json
+{ "ok": true, "rowsChecked": 10472, "fromSeq": 1, "lastSeq": 10472 }
+```
+
+or, on tamper:
+
+```json
+{ "ok": false, "brokenAtSeq": 8419, "reason": "hash_mismatch",
+  "expectedHash": "sha256:…", "foundHash": "sha256:…" }
+```
+
+## Filter and paginate
+
+The dashboard at `/[orgSlug]/audit` is the UI for this. The same filters
+are available on the API:
+
+```
+GET /api/orgs/<slug>/audit?actorKind=agent&since=2026-05-01&limit=100
+```
+
+Cursor-paginated. Continue with the `nextCursor` value from the response.
+
+## Export
+
+```bash
+curl 'https://<your-app>/api/orgs/<slug>/audit/export?actorKind=agent&since=2026-05-01' \
+  > may-agent-writes.csv
+```
+
+CSV up to a hard cap per request. For larger windows, paginate.
+
+## Compliance posture
+
+The [audit log landing page](/audit-log) is the marketing-side description.
+The verifier's hash algorithm and chain semantics live in the
+`@ablo/audit-chain` package — embeddable if you need to verify chains in a
+detached service.

package/docs/capabilities.md

@@ -0,0 +1,163 @@
+# Capabilities
+
+A capability is scoped credentials for a non-human actor.
+
+It is not a task and it is not an intent. It is the permission boundary that
+answers who may touch which resources.
+
+Most apps should use `api.agent(...).run(...)`; the SDK creates and revokes the
+capability for that run. Create capabilities directly only for custom runtimes,
+MCP sessions, or protocol-level integrations.
+
+## Why capabilities, not API keys
+
+Static API keys protect a human-operated workflow with one shared secret —
+fine for a server-to-server integration written once and forgotten. They are
+the wrong primitive for AI agents:
+
+- An agent that holds an account-wide key inherits every permission your
+  human team has. A leaked key burns the whole account; a confused-deputy
+  bug lets the agent write to resources it had no business touching.
+- Per-task work needs per-task attribution. One static key across every
+  agent invocation makes the audit trail say "the API key did it" — which
+  tells you nothing about which run, which prompt, or which user delegated
+  the action.
+- Long-lived secrets accumulate blast radius. The longer a credential is
+  valid, the more places it travels (logs, env files, agent prompts), and
+  the wider the leak surface.
+
+Capabilities replace the one-static-key model with **per-run, per-scope,
+short-lived** credentials. The 2025-2026 AI-agent auth consensus (the
+OAuth 2.1 / MCP spec, GCP short-lived credentials, AWS STS AssumeRole,
+HashiCorp Vault leases, Auth0 Token Vault) converged on the same shape:
+issue scoped tokens, attach a TTL, verify per-request, support fast
+revocation. Capabilities are Ablo's instance of that pattern.
+
+## The three-layer security model
+
+Every commit is authorized by three independent checks. None of them is
+sufficient on its own; together they cap the blast radius of every
+credible failure mode.
+
+1. **Lease (TTL)** — every capability has an expiry encoded in the bearer
+   token itself. After the lease, the token decodes but every signature
+   check fails. Caps the damage from a leaked token without requiring a
+   database lookup on the hot path.
+2. **Signature verification (per request)** — every commit re-verifies
+   the token's signature and attenuation. Stateless, cheap (microseconds),
+   detects forged or tampered tokens. The token's `syncGroups` and
+   `operations` are checked against the commit's actual targets;
+   `capability_scope_denied` rejects the request before any write lands.
+3. **Revocation** — `DELETE /v1/capabilities/:id` flips the cap's status
+   server-side; live WebSocket sessions are closed, future requests are
+   rejected within seconds. Closes the gap between lease refresh cycles
+   when you need *immediate* cutoff (compromised agent, accidental
+   over-grant, end-of-trial cleanup).
+
+The mental model: **lease prevents the slow leak, signature verification
+prevents the forged token, revocation prevents the active attacker.**
+Removing any one of the three leaves a class of failure uncovered.
+
+## Why this shape, in one paragraph each
+
+**Lease, not "session"** — A session token requires a database round-trip
+on every request to check liveness. A lease is encoded in the token and
+verified stateless. Vault popularized the term ("lease, renew, revoke");
+the mechanic is the same as AWS STS time-bounded credentials and GCP
+short-lived service-account creds. Ablo uses the word "lease" because the
+bearer holds a *bounded grant*, not just a timer — the same word
+`capability_scope_denied` errors reference.
+
+**Two scope axes (`syncGroups` + `operations`), not one** — `syncGroups`
+narrows *which rows* the actor can see; `operations` narrows *which verbs*
+the actor can use. Collapsing them into one set forces an explosion
+(`tasks.update:org:acme`, `tasks.delete:org:acme`, ...). Keeping them
+orthogonal lets a 3-group × 5-op cap stay 3+5 instead of 3×5. Same shape
+as IAM policies (`Resource` + `Action`), Stripe Restricted Keys
+(`resource_type` + `permission`), and Biscuit caveats.
+
+**Strings from `identityRoles`, never invented** — A consumer who types
+`'org:acme'` literally couples their code to Ablo's identity convention.
+Templates declared once on the schema (see integration-guide.md §1) let
+the convention live in one place; consumers reference it by template, not
+by hand-typing the prefix. Same boundary as Liveblocks' `prepareSession()`
+or PowerSync's named streams: server owns the namespace, client picks a
+subset by id.
+
+**`participantKind` cannot be `'user'`** — Capabilities are explicitly
+for non-human actors. A capability minted as a user would let any code
+path with that bearer impersonate the human; instead, user actions flow
+through session auth (cookies / OAuth) so the audit chain says
+"alice@example.com did X" — not "a token did X." Stripe makes the same
+split between Restricted API Keys (system) and Connect OAuth (user-on-
+behalf-of).
+
+## What capabilities aren't
+
+| Not | Why we didn't ship that |
+|---|---|
+| **A static API key** | One leaked secret = whole-account compromise. No per-run attribution. No automatic expiry. |
+| **An OAuth session token** | OAuth's user-delegation model assumes a human in the loop; agents are the actor, not the delegate. The auth flow round-trips don't fit agent runtimes. |
+| **An opaque DB session** | Per-request DB lookup is the slow path. Stateless verification (signature + lease) is the fast path; the DB is the revocation list, not the live-check. |
+| **A bearer JWT with `exp`** | Conceptually similar, but Biscuit caveats let us *attenuate* a cap further (delegate a narrower sub-scope to a sub-agent) without re-minting. Plain JWTs can't subset themselves. |
+
+## Create
+
+```ts
+import Ablo from '@ablo/sync-engine';
+
+const admin = Ablo({ apiKey: process.env.ABLO_API_KEY });
+
+const capability = await admin.capabilities.create({
+  participantKind: 'agent',
+  participantId: 'agent:task-writer',
+  // Identity-anchored groups derived from the schema's `identityRoles`
+  // registration (see integration-guide.md §1). The strings here mirror
+  // whatever templates the schema declared — `org:{id}` and friends for
+  // Ablo's stock schema; a third-party schema with `region:{id}` /
+  // `customer:{id}` roles would pass those instead.
+  syncGroups: ['org:acme', 'user:agent:task-writer'],
+  operations: ['tasks.retrieve', 'tasks.update'],
+  lease: '10m',
+});
+```
+
+Pass `capability.token` into the agent runtime. The agent never sees admin
+credentials.
+
+```ts
+const agent = capability.client();
+```
+
+## Inspect
+
+```ts
+const record = await admin.capabilities.retrieve(capability.id);
+
+record.status; // active | expired | revoked
+record.operations; // ['tasks.retrieve', 'tasks.update']
+```
+
+Inspection never returns the bearer token. Tokens are returned once at create
+time.
+
+## Revoke
+
+```ts
+await admin.capabilities.revoke(capability.id);
+```
+
+Revocation is forward-only. Already accepted commits stand; future requests with
+that token are rejected within seconds.
+
+## Scope Grammar
+
+| Field | Required | Meaning |
+|---|---|---|
+| `participantKind` | yes | `agent` or `system`. Capabilities cannot impersonate `user`. |
+| `participantId` | recommended | Stable actor id, for example `agent:task-writer`. |
+| `syncGroups` | yes | Sync groups the actor can touch. Strings come from the schema's `identityRoles` templates or a model's `syncGroupFormat` — never invented by the caller. |
+| `operations` | yes | Typed operation names, for example `tasks.update`. |
+| `lease` / `leaseSeconds` | recommended | Crash cleanup window for abandoned actors. |
+| `label` | no | Human-readable label for dashboards and audit. |
+| `userMeta` | no | Customer-attested end-user metadata for B2B2C flows. |

package/docs/client-behavior.md

@@ -0,0 +1,202 @@
+# Client Behavior
+
+This page covers the SDK behavior around options, errors, retries, and runtimes.
+
+## Constructor
+
+```ts
+import Ablo from '@ablo/sync-engine';
+import { defineSchema, model, z } from '@ablo/sync-engine/schema';
+
+const schema = defineSchema({
+  tasks: model({
+    title: z.string(),
+    status: z.enum(['todo', 'doing', 'done']),
+  }),
+});
+
+const ablo = Ablo({
+  schema,
+  apiKey: process.env.ABLO_API_KEY,
+});
+```
+
+Common options:
+
+| Option | Purpose |
+|---|---|
+| `schema` | Required for typed model resources. Omit only for advanced schema-less runtimes. |
+| `apiKey` | Bearer credential for trusted server runtimes. Defaults to `ABLO_API_KEY` when available. |
+| `baseURL` | Override the hosted sync endpoint for staging or private deployments. |
+| `persistence` | `volatile` by default. Use `indexeddb` for browser durable cache and offline queueing. |
+| `fetch` | Custom fetch implementation for tests or non-standard runtimes. |
+| `defaultHeaders` | Extra headers attached to every HTTP request. |
+| `defaultQuery` | Extra query parameters attached to every HTTP request. |
+| `dangerouslyAllowBrowser` | Required before sending an API key from browser code. Prefer a server route instead. |
+
+There is intentionally no `databaseURL` constructor option. Teams that keep
+canonical rows in their own database use a signed [Data Source](./data-sources.md)
+endpoint.
+
+## Model Methods
+
+Each schema model becomes a typed resource:
+
+```ts
+await ablo.ready();
+
+const [task] = await ablo.tasks.load({ where: { id: 'task_123' } });
+const local = ablo.tasks.retrieve('task_123');
+
+await ablo.tasks.create({ title: 'Draft launch plan', status: 'todo' });
+await ablo.tasks.update('task_123', { status: 'done' }, { wait: 'confirmed' });
+await ablo.tasks.delete('task_123', { wait: 'confirmed' });
+```
+
+`load` is async hydration from local store and server. `retrieve`, `list`, and
+`count` are synchronous local reads after data is loaded.
+
+`list` accepts the same practical read options the React selector path uses:
+`where`, `filter`, `orderBy`, `limit`, `offset`, and `scope`. Scope defaults to
+`'live'`; pass `'archived'` or `'all'` when you intentionally want non-live
+rows.
+
+## Multiplayer Behavior
+
+Multiplayer works when every participant uses the same model resource path. A
+human Server Action, a browser view, and an agent worker can all use
+`ablo.tasks`:
+
+```ts
+const [task] = await ablo.tasks.load({ where: { id } });
+const snap = ablo.snapshot({ tasks: id });
+
+await ablo.tasks.update(id, patch, {
+  readAt: snap.stamp,
+  onStale: 'reject',
+  wait: 'confirmed',
+});
+```
+
+The confirmed write fans out over realtime subscriptions. React clients that use
+`useAblo((ablo) => ablo.tasks.retrieve(id))` receive the new row, and selectors
+such as `useAblo((ablo) => ablo.intents.list({ resource: 'tasks', id }))`
+receive active intents. There is
+no extra multiplayer setup beyond routing shared state through Ablo.
+
+If an app writes directly to its database, Ablo cannot coordinate that write
+until the app reports it through Data Source events.
+
+## Per-Write Options
+
+```ts
+await ablo.tasks.update(
+  'task_123',
+  { status: 'done' },
+  {
+    wait: 'confirmed',
+    readAt: snap.stamp,
+    onStale: 'reject',
+    intent,
+    idempotencyKey: 'task_123:mark-done:v1',
+    timeout: 20_000,
+  },
+);
+```
+
+| Option | Purpose |
+|---|---|
+| `wait` | `queued` resolves after local queueing; `confirmed` waits for server acceptance. |
+| `readAt` | State cursor the write was based on. |
+| `onStale` | Policy when the target changed after `readAt`. Prefer `reject`. |
+| `intent` | Active work claim associated with this write. |
+| `idempotencyKey` | Stable key for retry-safe writes. The SDK generates one when omitted. |
+| `timeout` | Maximum time for the write call. |
+
+## Busy Behavior
+
+```ts
+const busy = ablo.intents.list({ resource: 'tasks', id: 'task_123' });
+
+if (busy.length > 0) {
+  await ablo.intents.waitFor(
+    { resource: 'tasks', id: 'task_123' },
+    { timeout: 30_000 },
+  );
+}
+```
+
+Reads never silently block. For raw resource calls, use `ifBusy`:
+
+- `return` returns active intents.
+- `wait` waits for matching intents to clear.
+- `fail` throws `AbloBusyError`.
+
+Schema clients use the realtime stream for waits. Schema-less HTTP clients must
+provide `busyPollInterval` when using `ifBusy: 'wait'`.
+
+## Errors
+
+All SDK errors extend `AbloError` and carry a stable `type`.
+
+| Error | Typical cause |
+|---|---|
+| `AbloAuthenticationError` | Missing, invalid, or expired credential. |
+| `AbloPermissionError` | Valid credential, denied operation or scope. |
+| `AbloRateLimitError` | Rate limit or quota exceeded. Check `retryAfterSeconds`. |
+| `AbloIdempotencyError` | Same idempotency key reused with a different request. |
+| `AbloConnectionError` | Network, timeout, abort, or transport failure. |
+| `AbloValidationError` | Invalid input or unsupported request shape. |
+| `AbloServerError` | Server-side 5xx. Retry with backoff if the operation is idempotent. |
+| `AbloStaleContextError` | Write was based on stale `readAt` state. Re-read and retry. |
+| `AbloBusyError` | Active intent conflicted with `ifBusy: 'fail'` or a busy wait timed out. |
+
+```ts
+import { AbloBusyError } from '@ablo/sync-engine';
+
+try {
+  await ablo.tasks.update('task_123', { status: 'done' }, { wait: 'confirmed' });
+} catch (error) {
+  if (error instanceof AbloBusyError) {
+    return { status: 'busy', intents: error.intents };
+  }
+  throw error;
+}
+```
+
+## Retries and Idempotency
+
+Model writes are retry-safe by default because the SDK attaches an idempotency
+key. If you provide your own key, keep it stable for retries of the same logical
+operation and never reuse it for a different payload.
+
+Retry transport failures and 5xx with backoff. Do not blindly retry validation,
+permission, idempotency, or stale-context errors without changing the request.
+
+## Logging
+
+Pass a logger when you need SDK logs in your own observability pipeline:
+
+```ts
+const ablo = Ablo({
+  schema,
+  apiKey: process.env.ABLO_API_KEY,
+  logger,
+});
+```
+
+The logger receives lifecycle, sync, retry, and rollback events. Avoid logging
+request bodies that may contain customer data.
+
+## Public Imports
+
+Only these imports are public SemVer surface:
+
+- `@ablo/sync-engine`
+- `@ablo/sync-engine/schema`
+- `@ablo/sync-engine/react`
+- `@ablo/sync-engine/testing`
+
+`dataSource(...)` is exported from the root package for customer-owned storage
+adapters. Everything outside the four import paths is internal to Ablo-owned
+apps and infrastructure.