@abloatai/ablo 0.11.0 → 0.11.2

package/docs/react.md

@@ -31,7 +31,7 @@ import { schema } from '@/ablo/schema';
 // from your own server route (see Identity below).
 export const ablo = Ablo({
   schema,
-  authEndpoint: '/api/ablo-session',
+  apiKey: () => fetch('/api/ablo-session').then((r) => r.text()),
 });
 ```
 
@@ -65,13 +65,13 @@ export function Providers({
 
 | Prop        | Default          | Purpose                                                                                                   |
 | ----------- | ---------------- | --------------------------------------------------------------------------------------------------------- |
-| `client`    | —                | **Required.** The `Ablo({ schema, authEndpoint })` instance. It carries the schema and connection config. |
+| `client`    | —                | **Required.** The `Ablo({ schema, apiKey })` instance. It carries the schema and connection config. |
 | `userId`    | resolved from auth | App participant id for app-owned fields and your `identityRoles`. Not the security boundary.            |
 | `fallback`  | neutral spinner  | Rendered during the *first* bootstrap only. Pass a branded skeleton, `null`, or `'passthrough'`.          |
 | `onError`   | —                | Engine / WebSocket / bootstrap errors. Wire to Sentry / Datadog.                                          |
 
 Everything that used to be a provider prop — `schema`, `url`, `apiKey`,
-`teamIds`, `syncGroups`/`scope`, `persistence`, `bootstrapMode` — now lives on
+`teamIds`, `syncGroups`, `persistence`, `bootstrapMode` — now lives on
 the `Ablo({ ... })` client you build before mounting the provider. Where the
 identity comes from, and why the API key never reaches the browser, is the whole
 of [Identity & Sync Groups](./identity.md) — read that if it isn't obvious how
@@ -178,6 +178,52 @@ imperative work after an event or effect.
 
 See [API reference](/docs/api) for the full options surface.
 
+## useClaim — named-claim dispatcher
+
+`useClaim` (renamed from `useIntent` in 0.11.0) is typed sugar for invoking a
+*named* claim from your own coordination vocabulary — distinct from the
+row-level `ablo.<model>.claim({ id })` resource claim. Use it when you want to
+broadcast a semantic claim like "I'm editing this layer" or "the agent is
+generating here" and let your transport turn it into a network effect.
+
+Declare the vocabulary once via module augmentation on the `Register` interface
+(the `Claims` key — previously `Intents`):
+
+```ts
+declare module '@abloatai/ablo' {
+  interface Register {
+    Claims: {
+      editLayer: { slideId: string; layerId: string };
+      generateWithAI: { entityId: string; tool: string };
+    };
+  }
+}
+```
+
+Then `useClaim('editLayer')` returns a function whose sole argument is the
+`editLayer` shape — purely compile-time narrowing, no runtime checks:
+
+```tsx
+'use client';
+
+import { useClaim } from '@abloatai/ablo/react';
+
+export function LayerToolbar({ slideId, layerId }: { slideId: string; layerId: string }) {
+  const claimEditLayer = useClaim('editLayer');
+
+  return (
+    <button onClick={() => claimEditLayer({ slideId, layerId })}>
+      Edit layer
+    </button>
+  );
+}
+```
+
+The hook is pure sugar: the actual network effect lives in the `beginClaim`
+function wired into the provider (bound to your transport). If no `beginClaim`
+is wired, the returned invoker throws `AbloValidationError` with code
+`claim_not_wired`.
+
 ## Next.js
 
 The Next.js [App Router landing](/nextjs) walks through Server Components

package/docs/schema-contract.md

@@ -49,6 +49,20 @@ The model key (`weatherReports`) becomes the client namespace
 contract. You should not create a parallel string-keyed write path for the same
 data.
 
+### Reserved fields
+
+The SDK provides these on every row automatically — do **not** declare them in
+your `model(...)` fields:
+
+- `id`
+- `createdAt`
+- `updatedAt`
+- `organizationId`
+- `createdBy`
+
+Declare only your own fields; the reserved ones are still present on the row and
+readable, you just don't author them.
+
 ## Reads and writes
 
 Use async reads when the row may not be local:
@@ -88,12 +102,16 @@ the fresh row. Reads stay open; only acting on the row serializes.
 
 ## Storage boundary
 
-Every schema model is backed by your own database through a Data Source — Ablo
-coordinates each write and your app commits it to your Postgres.
+Every schema model is backed by your own database. There are three start states,
+all covered in [Connect Your Database](./data-sources.md) (the single source of
+truth): the sandbox (`apiKey` only, no database), a direct connection string
+(`databaseUrl` passed to `Ablo(...)`, a live, server-only option), or a signed
+Data Source endpoint where your app keeps the database credential and commits
+each write itself.
 
-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.
+If your database stays canonical behind a Data Source endpoint, do not pass
+`databaseUrl` 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
 

package/llms-full.txt

@@ -19,7 +19,7 @@ Public imports:
 - `@abloatai/ablo/react` — React provider and hooks.
 - `@abloatai/ablo/testing` — test harnesses and mocks.
 
-TYPES: have the project register its schema ONCE via declaration merging (init scaffolds `ablo.d.ts`): `declare module '@abloatai/ablo' { interface Register { Schema: typeof schema } }`. Then model types are one parameter: `type Task = Model<'tasks'>` (import type { Model } from '@abloatai/ablo/schema'). Do NOT teach `InferModel` (deprecated) or the two-param `Model<typeof schema,'tasks'>` unless multiple schemas exist. Never hand-write model interfaces — derive from the schema.
+TYPES: the project registers its schema ONCE via declaration merging — `npx ablo init` scaffolds `ablo/register.ts` (a regular `.ts` module beside schema.ts, NOT a hand-authored `.d.ts`): `import type { schema } from './schema'; declare module '@abloatai/ablo' { interface Register { Schema: typeof schema } }`. The top-level `import type` makes `declare module` MERGE (augment) the SDK's Register interface rather than collide — same shape TanStack Router uses in src/router.tsx; any `.ts` file in tsconfig include works, never imported. Then model types are one parameter: `type Task = Model<'tasks'>` (import type { Model } from '@abloatai/ablo/schema'). Do NOT teach `InferModel` (deprecated) or the two-param `Model<typeof schema,'tasks'>` unless multiple schemas exist. Never hand-write model interfaces — derive from the schema. To NAME the client type (function param, context value), infer from the value: `type Sync = typeof sync` — same idiom as tRPC `typeof appRouter` / Drizzle `typeof db`; it resolves the typed overload at the call site. Do NOT use `ReturnType<typeof Ablo>` (collapses to the untyped last overload) and do NOT import a bespoke client-type generic — there is none.
 
 
 Do not teach `/api`, `/agent`, `/ai-sdk`, `/core`, `/realtime`, or `internal/*` as public imports. The Data Source surface — `/source`, `/source/next`, `/source/drizzle`, `/source/kysely`, `/source/conformance` — IS public (it's how a customer-owned database is wired).
@@ -39,9 +39,9 @@ Use `snapshot(...)` and `readAt` when an agent write depends on state it already
 read. `onStale: 'reject'` prevents lost updates by rejecting if the target
 changed after the snapshot.
 
-Claims are live coordination signals, not database locks. Schema clients wait
-from the realtime claim stream. Schema-less HTTP clients must pass an explicit
-`claimedPollInterval` for `ifClaimed: 'wait'`; no hidden hard-coded polling.
+Claims are live coordination signals, not database locks. Reads never block on a
+claim — to wait for a row to free up, `claim({ id })` it and the claim queues
+fairly behind the current holder.
 
 Agent run bookkeeping is internal. Most users should not create run ledger
 records or scoped access credentials manually.
@@ -145,9 +145,21 @@ This applies to any API-backed app: Python, Rails, Go, or Node. The backend keep
 its service layer and DB credentials. Ablo gets a Data Source endpoint and uses
 `ABLO_API_KEY`, not a database URL.
 
-When the user DOES use the connection-string path (`Ablo({ databaseUrl })` /
-`DATABASE_URL` at init): the role must be NON-superuser and NON-BYPASSRLS —
-Ablo enforces row-level security and rejects owner roles with
+The connection-string path is the PRIMARY one: pass `databaseUrl` explicitly to
+`Ablo({ databaseUrl })`. It is NOT auto-read from the environment — a
+`DATABASE_URL` set for another tool (Prisma, Drizzle, docker-compose) is ignored
+unless you pass `databaseUrl`. The typical user ALREADY has a Postgres (often
+Prisma-managed for auth/audit/log tables that are NOT in the Ablo schema); Ablo
+syncs a SUBSET of models against it. Most users do NOT run `ablo migrate` — they
+ADOPT existing tables with `npx ablo pull` / `npx ablo check`, or keep managing
+tables with their own migration tool. Run `npx ablo migrate` only when Ablo
+should OWN the tables. NOTE: Ablo's CLOUD connects to your Postgres over the
+NETWORK, so a localhost / private-range DB is unreachable and rejected — for a
+local dev DB, expose a signed Data Source endpoint (your app proxies to it) or
+use the hosted sandbox (no DB needed).
+
+When the user DOES use the connection-string path: the role must be NON-superuser
+and NON-BYPASSRLS — Ablo enforces row-level security and rejects owner roles with
 `database_role_cannot_enforce_rls`. Neon's and Supabase's default dashboard
 strings use the database OWNER (e.g. `neondb_owner`) and ARE rejected. EASIEST: have the user run `npx ablo migrate` — it detects the unsafe role and creates the scoped one automatically from their machine (owner credential never reaches Ablo; new DATABASE_URL written to the env file). Manual alternative — create a scoped role first (`CREATE ROLE ablo_app LOGIN PASSWORD '...'
 NOSUPERUSER NOBYPASSRLS; GRANT CREATE, CONNECT ON DATABASE <db> TO ablo_app;
@@ -162,9 +174,11 @@ The options that matter: `schema` and `apiKey`. Everything else
 breaks the connection. It exists only for self-hosted/proxy setups the human
 explicitly asks for.
 
-There is intentionally no `databaseURL` option on `Ablo(...)`. Application and
-agent code use `ABLO_API_KEY`. Customer-owned app databases stay private behind
-a signed Data Source endpoint.
+`databaseUrl` is an OPTIONAL, server-only option on `Ablo(...)`. It is NOT
+auto-read from the environment — pass it EXPLICITLY to register your Postgres
+directly (the primary connection-string path). Omit it when you expose a signed
+Data Source endpoint (so customer-owned app databases stay private), or when
+trying Ablo against the hosted sandbox (apiKey only, no database).
 
 Important per-write options: `wait`, `readAt`, `onStale`,
 `idempotencyKey`, and `timeout`.
@@ -187,7 +201,10 @@ There are two sandbox surfaces:
   be pasted into Claude Code or Codex to wire one real model through Ablo.
 - Authenticated org sandboxes are real test environments. The default sandbox is
   the Stripe-style sandbox for an org. It has an isolated sync group prefix,
-  can mint `sk_test_*` keys, and can be reset without touching live state.
+  can mint `sk_test_*` keys, and can be reset without touching live state. The
+  sandbox CAN host rows in Ablo's test plane, so you can try Ablo with NO
+  database — `apiKey` only, no `databaseUrl` — like Stripe test mode. (In
+  production, your own Postgres is the system of record.)
 
 Additional org sandboxes can start blank or copy live configuration. Keep
 customer production traffic on `sk_live_*`; use `sk_test_*` for app setup, Data
@@ -290,7 +307,10 @@ common agent path.
 
 ## Model
 
-Every model read returns state plus coordination metadata:
+The read shape depends on whether the client has a local graph:
+
+- The stateful `ablo.<model>.retrieve({ id })` returns the BARE row (`T | undefined`), and `list({ where })` returns `T[]`. Read coordination metadata (state watermark, active claims) separately via `ablo.snapshot(...)` and `ablo.<model>.claim.state({ id })`.
+- The stateless HTTP / `.model(name)` `retrieve({ id })` returns a `ModelRead<T>` envelope because it has no local graph to carry the watermark; `list({ where })` still returns `T[]`.
 
 ```ts
 type ModelRead<T> = {
@@ -300,32 +320,31 @@ type ModelRead<T> = {
 };
 ```
 
-`stamp` is the state watermark. Pass it to writes as `readAt`.
+`stamp` is the state watermark. Pass it to writes as `readAt` (from `ablo.snapshot(...)` on the stateful client, or from the envelope on the HTTP client).
 
 `claims` lists active work on the target. Reads are allowed while another participant is working. The caller decides whether to return, fail, or wait.
 
 ## Claimed Behavior
 
-Claimed behavior is explicit:
+Claimed behavior is explicit, and there are only two policies:
 
-- `ifClaimed: 'return'` returns the current claims with the read.
+- `ifClaimed: 'return'` (the default) returns the row plus the current claims with the read.
 - `ifClaimed: 'fail'` throws `AbloClaimedError`.
-- `ifClaimed: 'wait'` waits for matching claims to clear.
-
-Schema clients use the realtime claim stream for waits.
 
-Schema-less HTTP clients cannot know when a claim clears unless the caller opts into polling. When using `ifClaimed: 'wait'` over HTTP, provide `claimedPollInterval` and usually `claimedTimeout`.
+Reads never block on a claim. To wait for a row to free up, `claim({ id })` it —
+the claim queues fairly behind the current holder and is granted when the row
+frees. Use `ifClaimed: 'fail'` when you'd rather refuse to read a claimed row.
 
 ```ts
+// Read a claimed row without blocking, surfacing who holds it:
 await api.model('reports').retrieve({
   id: 'report_stockholm',
-  ifClaimed: 'wait',
-  claimedPollInterval: 1_000,
-  claimedTimeout: 30_000,
+  ifClaimed: 'return',
 });
-```
 
-No hidden hard-coded claimed polling. `claimedTimeout` is a maximum wait, not the coordination mechanism.
+// Or wait for it to free up by queueing your own claim:
+await api.model('reports').claim({ id: 'report_stockholm' });
+```
 
 ## Write
 

package/llms.txt

@@ -8,7 +8,7 @@ Use AI SDK for the agent loop. Use Ablo when agent reads and writes must persist
 
 ## Start here
 
-First action when integrating into an app: run `npx ablo init --yes --framework <nextjs|vite|remix|vanilla> --storage datasource`. Agents have no TTY — `--yes` is REQUIRED or it HANGS. It scaffolds `ablo/schema.ts`, the client, the Data Source endpoint, and (for Next.js) the browser provider + session route, all on the current API. Edit the generated files rather than hand-writing from this doc.
+First action when integrating into an app: run `npx ablo init --yes --framework <nextjs|vite|remix|vanilla>`. Agents have no TTY — `--yes` is REQUIRED or it HANGS. The default `--storage direct` (connection string) scaffolds `ablo/schema.ts`, the client, and (for Next.js) the browser provider + session route; pass `--storage endpoint` instead when database credentials must stay inside the app — that variant scaffolds a signed Data Source endpoint. All on the current API. Edit the generated files rather than hand-writing from this doc.
 
 Second: make sure a key exists — WITHOUT printing it. The key is a secret; it must never appear in your output, your reasoning, or a file you echo (it would live in the conversation history forever). Check PRESENCE only: `[ -n "$ABLO_API_KEY" ] && echo set` and `grep -cq '^ABLO_API_KEY=' .env.local && echo wired` — never `cat .env.local`, never `echo $ABLO_API_KEY`. If neither check passes, ask the HUMAN to run `npx ablo login` once — it opens a browser and saves a `sk_test_` key locally; an agent must NOT run it. You never copy the key by hand: the next step writes it into `.env.local` (and gitignores it) for you.
 
@@ -24,7 +24,7 @@ Each app gets its own PROJECT inside the org — its own schema, its own sandbox
 import Ablo from '@abloatai/ablo';
 import { defineSchema, model, z } from '@abloatai/ablo/schema';
 
-TYPES: have the project register its schema ONCE via declaration merging (init scaffolds `ablo.d.ts`): `declare module '@abloatai/ablo' { interface Register { Schema: typeof schema } }`. Then model types are one parameter: `type Task = Model<'tasks'>` (import type { Model } from '@abloatai/ablo/schema'). Do NOT teach `InferModel` (deprecated) or the two-param `Model<typeof schema,'tasks'>` unless multiple schemas exist. Never hand-write model interfaces — derive from the schema.
+TYPES: the project registers its schema ONCE via declaration merging — `npx ablo init` scaffolds `ablo/register.ts` (a regular `.ts` module beside schema.ts, NOT a hand-authored `.d.ts`): `import type { schema } from './schema'; declare module '@abloatai/ablo' { interface Register { Schema: typeof schema } }`. The top-level `import type` makes `declare module` MERGE (augment) the SDK's Register interface rather than collide — same shape TanStack Router uses in src/router.tsx; any `.ts` file in tsconfig include works, never imported. Then model types are one parameter: `type Task = Model<'tasks'>` (import type { Model } from '@abloatai/ablo/schema'). Do NOT teach `InferModel` (deprecated) or the two-param `Model<typeof schema,'tasks'>` unless multiple schemas exist. Never hand-write model interfaces — derive from the schema. To NAME the client type (function param, context value), infer from the value: `type Sync = typeof sync` — same idiom as tRPC `typeof appRouter` / Drizzle `typeof db`; it resolves the typed overload at the call site. Do NOT use `ReturnType<typeof Ablo>` (collapses to the untyped last overload) and do NOT import a bespoke client-type generic — there is none.
 
 
 const schema = defineSchema({
@@ -99,13 +99,13 @@ coordination until the app reports it through Data Source events.
 ## Claimed Behavior
 
 Reads never silently block. Schema reads stay open while a row is claimed.
-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.
+Server reads through `ablo.model(name)` can pass `ifClaimed: 'return'` (the
+default — returns the row plus active claim metadata) or `ifClaimed: 'fail'`
+to throw `AbloClaimedError`.
 
-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.
+Reads never block on a claim. To wait for a row to free up, `claim({ id })` it —
+the claim queues fairly behind the current holder and is granted when the row
+frees. Use `ifClaimed: 'fail'` when you'd rather refuse to read a claimed row.
 
 ## Guarantees
 
@@ -123,9 +123,9 @@ A schema is model fields and relations. Advanced schema helpers such as `mutable
 
 ## Storage Boundary
 
-Do not add `databaseURL` to `Ablo(...)`. Application and agent code use `ABLO_API_KEY`.
+`databaseUrl` is an OPTIONAL, server-only constructor option on `Ablo(...)`. It is NOT auto-read from the environment — pass it EXPLICITLY to register your Postgres directly. Omit it when you expose a signed Data Source endpoint, or when trying Ablo against the hosted sandbox (apiKey only). A `DATABASE_URL` set for another tool (Prisma, Drizzle, docker-compose) is ignored unless you pass `databaseUrl` explicitly.
 
-Every schema model is backed by a database, and the default is YOUR OWN. Keep your rows in your Postgres and expose a Data Source endpoint that hands Ablo an ORM `adapter` (Drizzle is the default; Prisma and Kysely are also supported) — it owns the transaction, exactly-once idempotency, and outbox in ONE pass (no hand-written `commit`/`events`). Your `DATABASE_URL` lives in your app, never in `Ablo(...)`; run `npx ablo migrate` to provision the synced-model tables in your DB.
+In production, every schema model is backed by YOUR OWN database. The PRIMARY path is the connection string: pass `databaseUrl` (most users already have a Postgres — often Prisma- or Drizzle-managed for auth/audit/log tables that are NOT in the Ablo schema; Ablo syncs a SUBSET of models against it). Most users do NOT run `ablo migrate` — they ADOPT existing tables with `npx ablo pull` / `npx ablo check`, or keep managing tables with their own migration tool. Run `npx ablo migrate` only when Ablo should OWN the tables (it provisions the synced-model tables in your DB). The alternative to the connection string is a signed Data Source endpoint that hands Ablo an ORM `adapter` (Drizzle is the default; Prisma and Kysely are also supported) — it owns the transaction, exactly-once idempotency, and outbox in ONE pass (no hand-written `commit`/`events`); use it when database credentials must never leave your infrastructure (or for a local/private-range DB, which Ablo's cloud cannot reach over the network).
 
 GOTCHA the user WILL hit: `DATABASE_URL` must use a NON-superuser, NON-BYPASSRLS role (Ablo enforces row-level security; owner roles are rejected with `database_role_cannot_enforce_rls`). Neon's and Supabase's default dashboard connection strings use the database OWNER (e.g. `neondb_owner`) and are rejected. EASIEST: `npx ablo migrate` detects the unsafe role and creates the scoped one automatically from the user's machine (owner credential never reaches Ablo; new DATABASE_URL written to the env file). Manual alternative — create a scoped role first: `CREATE ROLE ablo_app LOGIN PASSWORD '...' NOSUPERUSER NOBYPASSRLS; GRANT CREATE, CONNECT ON DATABASE <db> TO ablo_app; GRANT CREATE, USAGE ON SCHEMA public TO ablo_app;` — then swap user/password into the same host/db string.
 
@@ -145,7 +145,7 @@ export const { POST } = dataSourceNext({
 });
 ```
 
-`npx ablo init` defaults to this — it scaffolds the endpoint and the `DATABASE_URL` for you (see CLI below). Your app database credentials stay private — Ablo only calls the endpoint.
+`npx ablo init` defaults to `--storage direct` (the connection-string path — it scaffolds the client carrying `databaseUrl` and the `DATABASE_URL` env entry; see CLI below). Pass `--storage endpoint` to scaffold the signed Data Source endpoint above instead, when app database credentials must stay private — Ablo only calls the endpoint.
 
 ## Sandboxes
 
@@ -156,9 +156,11 @@ when an agent is asked to "make Ablo work" in an existing app.
 
 Authenticated org sandboxes are real test environments. Treat the default
 sandbox like Stripe test mode: it has an isolated sync group prefix and mints
-`sk_test_*` keys. Extra sandboxes can start blank or copy live configuration.
-Resetting a sandbox creates a clean future stream without touching live data.
-Use `sk_live_*` only for production.
+`sk_test_*` keys. The sandbox CAN host rows in Ablo's test plane, so you can try
+Ablo with NO database — `apiKey` only, no `databaseUrl`. (In production, your own
+Postgres is the system of record.) Extra sandboxes can start blank or copy live
+configuration. Resetting a sandbox creates a clean future stream without
+touching live data. Use `sk_live_*` only for production.
 
 For coding agents, the sandbox success path is: pick one shared model,
 declare schema, create the Ablo client, replace one direct mutation with a typed
@@ -185,7 +187,7 @@ Do not teach `/api`, `/agent`, `/ai-sdk`, `/core`, `/realtime`, or internal subp
 
 `ablo init` and other prompts need a TTY; an agent/CI run has none and will HANG. Always:
 
-- `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.
+- `npx ablo init --yes` (flags: `--framework`, `--auth`, `--storage direct|endpoint` (default `direct`), `--no-agent`, `--no-pull`, `--no-install`, `--no-login`). Generates `ablo/schema.ts` + the client; `--storage direct` (default) wires `databaseUrl`, `--storage endpoint` scaffolds the `ablo/data-source.ts` endpoint above instead.
 - Key: see "Start here" — env → `.env.local` → ask the human to `npx ablo login`; never run `login` yourself, never copy keys by hand (`ablo push` writes `.env.local`).
 - Adopt an existing DB: `npx ablo pull prisma [path]` / `npx ablo pull drizzle <module>`.
 - `npx ablo push --no-watch` pushes the schema (sandbox) AND writes `ABLO_API_KEY` to `.env.local` (default watches forever); `npx ablo logs --no-follow` (default tails forever); `npx ablo mode sandbox|production` (always pass the arg). `npx ablo push`/`status`/`pull`/`check`/`generate` are one-shot.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@abloatai/ablo",
-  "version": "0.11.0",
+  "version": "0.11.2",
   "description": "The Collaboration Layer For AI Agents",
   "license": "Apache-2.0",
   "type": "module",

package/dist/api/index.d.ts

@@ -1,10 +0,0 @@
-/**
- * Internal compatibility entrypoint for the stateless hosted protocol client.
- *
- * Use this build for serverless functions, scripts, and backends that want
- * model reads/writes and commits over HTTP without the realtime sync runtime.
- */
-export { createProtocolClient, createProtocolClient as Ablo, type AbloApi, type AbloApiClientOptions, type AbloApiClaims, type Capability, type CapabilityCreateOptions, type CapabilityParticipantKind, type CapabilityRecord, type CapabilityResource, type CapabilityRevocation, type CapabilityScope, } from '../client/ApiClient.js';
-export type { CommitCreateOptions, CommitOperationInput, CommitReceipt, CommitWait, ClaimCreateOptions, ClaimHandle, ClaimWaitOptions, ClaimedOptions, IfClaimedPolicy, ModelClient, ModelClaim, ModelMutationOptions, ModelReadOptions, ModelRead, ModelTarget, } from '../client/Ablo.js';
-import { createProtocolClient } from '../client/ApiClient.js';
-export default createProtocolClient;

package/dist/api/index.js

@@ -1,9 +0,0 @@
-/**
- * Internal compatibility entrypoint for the stateless hosted protocol client.
- *
- * Use this build for serverless functions, scripts, and backends that want
- * model reads/writes and commits over HTTP without the realtime sync runtime.
- */
-export { createProtocolClient, createProtocolClient as Ablo, } from '../client/ApiClient.js';
-import { createProtocolClient } from '../client/ApiClient.js';
-export default createProtocolClient;

package/dist/principal.d.ts

@@ -1,44 +0,0 @@
-/**
- * Principal constructors — a thin typed façade over the raw
- * `SessionRef` / `AgentRef` shapes so call sites don't have to memorize
- * the discriminated-union tags.
- *
- * ```ts
- * import Ablo, { session } from '@abloatai/ablo';
- *
- * const ablo = Ablo({ schema, apiKey });
- * const participant = await ablo.participants.join({
- *   type: 'Matter',
- *   id: 'deal-1',
- * });
- * ```
- *
- * Browser-human flows use `session(...)`. Agent-spawn-agent flows use
- * `agent(...)`, but those rarely appear in customer code because the
- * participant layer handles attenuation.
- *
- * These are pure — no I/O, no hidden state. If the shape ever grows a
- * required field (say, a scope hint for the restricted key), the helper
- * is the one place to flag migrations.
- */
-import type { AgentRef, SessionRef } from './types/streams.js';
-/**
- * Build a `SessionRef` from the identifiers your auth system already
- * holds. Typical inputs: the Better Auth session id, the user id, and
- * the organization the session is scoped to.
- */
-export declare function session(params: {
-    id: string;
-    userId: string;
-    organizationId: string;
-}): SessionRef;
-/**
- * Build an `AgentRef` from an agent id + the capability token that
- * authenticates it. Rare in application code — the common path is
- * `participant.join(child)` where the parent's token is attenuated
- * automatically.
- */
-export declare function agent(params: {
-    id: string;
-    capabilityToken: string;
-}): AgentRef;

package/dist/principal.js

@@ -1,49 +0,0 @@
-/**
- * Principal constructors — a thin typed façade over the raw
- * `SessionRef` / `AgentRef` shapes so call sites don't have to memorize
- * the discriminated-union tags.
- *
- * ```ts
- * import Ablo, { session } from '@abloatai/ablo';
- *
- * const ablo = Ablo({ schema, apiKey });
- * const participant = await ablo.participants.join({
- *   type: 'Matter',
- *   id: 'deal-1',
- * });
- * ```
- *
- * Browser-human flows use `session(...)`. Agent-spawn-agent flows use
- * `agent(...)`, but those rarely appear in customer code because the
- * participant layer handles attenuation.
- *
- * These are pure — no I/O, no hidden state. If the shape ever grows a
- * required field (say, a scope hint for the restricted key), the helper
- * is the one place to flag migrations.
- */
-/**
- * Build a `SessionRef` from the identifiers your auth system already
- * holds. Typical inputs: the Better Auth session id, the user id, and
- * the organization the session is scoped to.
- */
-export function session(params) {
-    return {
-        kind: 'session',
-        id: params.id,
-        userId: params.userId,
-        organizationId: params.organizationId,
-    };
-}
-/**
- * Build an `AgentRef` from an agent id + the capability token that
- * authenticates it. Rare in application code — the common path is
- * `participant.join(child)` where the parent's token is attenuated
- * automatically.
- */
-export function agent(params) {
-    return {
-        kind: 'agent',
-        id: params.id,
-        capabilityToken: params.capabilityToken,
-    };
-}

package/dist/react/SyncGroupProvider.d.ts

@@ -1,19 +0,0 @@
-import { type ReactNode } from 'react';
-export interface SyncGroupProviderProps {
-    /** The sync-group identifier — e.g., `matter:abc-123`, `deck:xyz`. */
-    id: string;
-    children: ReactNode;
-}
-export declare function SyncGroupProvider({ id, children }: SyncGroupProviderProps): import("react").JSX.Element;
-/**
- * Returns the ID of the nearest `<SyncGroupProvider>`. Throws if
- * called outside one — sync-group awareness is mandatory by design,
- * so the error points the consumer at the provider instead of
- * returning undefined and letting downstream code silently miss scope.
- *
- * If a component legitimately renders both inside and outside a
- * group, structure the tree so the hook is only called on the
- * inside path (e.g., split into two components). Silent nulls are
- * never the right answer.
- */
-export declare function useSyncGroup(): string;

package/dist/react/SyncGroupProvider.js

@@ -1,44 +0,0 @@
-'use client';
-import { jsx as _jsx } from "react/jsx-runtime";
-import { createContext, useContext, useMemo } from 'react';
-import { AbloValidationError } from '../errors.js';
-/**
- * Narrow context for a per-entity sync-group scope. Maps directly onto
- * Liveblocks' `<RoomProvider id="...">`: wrap a subtree, and any hooks
- * inside can read `useSyncGroup()` to discover "which entity am I
- * scoped to?" without threading the ID through props.
- *
- * Typical IDs follow the multiplayer sync-group convention: `matter:<id>`,
- * `deck:<id>`, `project:<id>`. The ID is an opaque string — the
- * provider doesn't parse it.
- *
- * v0.3.0 scope: this is a thin passthrough. Future versions will
- * scope `useQuery` / `useOne` results to the group automatically.
- */
-const SyncGroupContext = createContext(null);
-export function SyncGroupProvider({ id, children }) {
-    // Stabilize the context value so consumers memoized on it don't
-    // re-render when the provider re-renders for unrelated reasons.
-    const value = useMemo(() => id, [id]);
-    return _jsx(SyncGroupContext.Provider, { value: value, children: children });
-}
-/**
- * Returns the ID of the nearest `<SyncGroupProvider>`. Throws if
- * called outside one — sync-group awareness is mandatory by design,
- * so the error points the consumer at the provider instead of
- * returning undefined and letting downstream code silently miss scope.
- *
- * If a component legitimately renders both inside and outside a
- * group, structure the tree so the hook is only called on the
- * inside path (e.g., split into two components). Silent nulls are
- * never the right answer.
- */
-export function useSyncGroup() {
-    const id = useContext(SyncGroupContext);
-    if (!id) {
-        throw new AbloValidationError('useSyncGroup: no <SyncGroupProvider> mounted above this component. ' +
-            'Wrap your tree with <SyncGroupProvider id="matter:..."> from ' +
-            '@abloatai/ablo/react.', { code: 'no_sync_group_provider' });
-    }
-    return id;
-}

package/dist/react/useClaim.d.ts

@@ -1,29 +0,0 @@
-import type { ResolveClaims } from '../types/global.js';
-/**
- * Named-claim invoker, typed via `ResolveClaims[ClaimName]`.
- *
- * The consumer declares their claim vocabulary in the global:
- *
- * ```ts
- * declare module '@abloatai/ablo' {
- *   interface Register {
- *     Claims: {
- *       editLayer: { slideId: string; layerId: string };
- *       generateWithAI: { entityId: string; tool: string };
- *     };
- *   }
- * }
- * ```
- *
- * Then `useClaim('editLayer')` returns a function whose sole argument
- * is the `editLayer` claim shape — no runtime checks, purely compile-
- * time narrowing.
- *
- * The SDK doesn't own what happens next: the `beginClaim` function on
- * the React context (supplied via `SyncProvider`) is where the claim
- * claim turns into a network effect. A Node-backed consumer wires it
- * through `SyncAgent.beginClaim`; a browser-backed consumer may
- * broadcast it through their own WebSocket. This hook is pure sugar
- * that adds the typed name + claim narrowing.
- */
-export declare function useClaim<Name extends keyof ResolveClaims & string>(claimName: Name): (claim: ResolveClaims[Name]) => unknown;

package/dist/react/useClaim.js

@@ -1,42 +0,0 @@
-'use client';
-import { useCallback } from 'react';
-import { useSyncContext } from './context.js';
-import { AbloValidationError } from '../errors.js';
-/**
- * Named-claim invoker, typed via `ResolveClaims[ClaimName]`.
- *
- * The consumer declares their claim vocabulary in the global:
- *
- * ```ts
- * declare module '@abloatai/ablo' {
- *   interface Register {
- *     Claims: {
- *       editLayer: { slideId: string; layerId: string };
- *       generateWithAI: { entityId: string; tool: string };
- *     };
- *   }
- * }
- * ```
- *
- * Then `useClaim('editLayer')` returns a function whose sole argument
- * is the `editLayer` claim shape — no runtime checks, purely compile-
- * time narrowing.
- *
- * The SDK doesn't own what happens next: the `beginClaim` function on
- * the React context (supplied via `SyncProvider`) is where the claim
- * claim turns into a network effect. A Node-backed consumer wires it
- * through `SyncAgent.beginClaim`; a browser-backed consumer may
- * broadcast it through their own WebSocket. This hook is pure sugar
- * that adds the typed name + claim narrowing.
- */
-export function useClaim(claimName) {
-    const { beginClaim } = useSyncContext();
-    return useCallback((claim) => {
-        if (!beginClaim) {
-            throw new AbloValidationError(`useClaim: no \`beginClaim\` wired into SyncProvider. Pass ` +
-                `a \`beginClaim\` prop (typically bound to your transport) ` +
-                `to enable claim invocations.`, { code: 'claim_not_wired' });
-        }
-        return beginClaim(claimName, claim);
-    }, [beginClaim, claimName]);
-}