@abloatai/ablo 0.5.0 → 0.6.0

package/CHANGELOG.md

@@ -1,5 +1,27 @@
 # Changelog
 
+## 0.6.0
+
+### Minor Changes
+
+- 0f663e7: Coordination surface: fair queue, reactive wait-line, and lease renewal.
+  - **Claims acquire through a server FIFO queue.** On contention a claim waits its turn and re-reads before proceeding; reads are never blocked. Writes blocked by another participant's claim throw a typed `AbloBusyError`.
+  - **`ablo.<model>.queue(id)`** — reactive read of the wait-line behind a row: who's queued, their action, and FIFO position. Synced to peers like `activity(id)`.
+  - **Backpressure on `claim`** — `{ wait: false }` skips instead of waiting if the row is already held (claim-or-skip dedup); `{ maxQueueDepth: n }` bails with `AbloBusyError('queue_too_deep')` rather than joining a line already that deep.
+  - **Lease renewal** — a held claim renews automatically while the holder's connection is alive, so you never size a TTL; it lapses only after the holder goes silent. A queued claim that's abandoned is dequeued (no ghost waiters).
+  - **Reads are never gated by a claim**, including for agents.
+  - Intent vocabulary cleanup: a waiting claim is an `Intent` with `status: 'queued'` (`position` carries its place in line). Removed the unbuilt `whenFree`.
+
+- **BREAKING — API renames** (apply when upgrading from 0.5.1):
+  - Change-listeners renamed to `.onChange(...)`: `ablo.<model>.subscribe(cb)`, `presence.subscribe()`, `intents.subscribe()` → `.onChange(...)`. (`subscribe` is reserved for an upcoming scope-grant verb.)
+  - Row-access API renamed Resource → Model: `Ablo.Resource.*` → `Ablo.Model.*`, `ablo.resource(name)` → `ablo.model(name)`, `ModelTarget.resource` → `ModelTarget.model`, error code `resource_not_found` → `model_not_found`.
+
+## 0.5.1
+
+### Patch Changes
+
+- Docs: add a React quick-start (provider + `useAblo`), plain-language rewrite, and a "Set up with Claude Code" section.
+
 ## 0.5.0
 
 ### Minor Changes

package/README.md

@@ -1,6 +1,6 @@
 # Ablo
 
-Ablo Sync is a typed sync engine for shared app state — the kind that humans,
+Ablo is a typed sync engine for shared app state — the kind that humans,
 server code, and AI agents all edit at once.
 
 Reach for it when those edits need to show up everywhere in real time, not
@@ -8,29 +8,32 @@ silently overwrite each other, expose who's working on what, and leave a record
 of who changed what.
 
 ```txt
-schema -> ablo.<model>.create/load/update(...)
+schema -> ablo.<model>.create/retrieve/update/claim(...)
 ```
 
-## Install
+## Set up
 
 ```bash
 npm install @abloatai/ablo
 ```
 
-Requires Node 22+ and TypeScript 5+.
+The package ships an `llms.txt` — a precise map of the API — so a coding agent
+integrates from the real surface instead of guessing it. Point Claude Code or
+Cursor at it:
 
-## Get a Test Key
+> Read `node_modules/@abloatai/ablo/llms.txt`, then add an Ablo schema and
+> `<AbloProvider>`, wire my first create / retrieve / update, and use `claim`
+> for anything an agent edits across a slow step (read → LLM → write).
 
-Create an Ablo sandbox and copy an `sk_test_*` API key. Keep API keys in trusted
-server runtimes only.
+Or wire it by hand — the [Quick Start](#quick-start) below is the shape it
+produces. For production (React, an existing backend, Data Source, agents), the
+[Integration Guide](./docs/integration-guide.md) is the deeper map.
 
-```bash
-export ABLO_API_KEY=sk_test_...
-```
-
-In the browser, connect through the React provider (`<AbloProvider>`), which
-authenticates with the signed-in user's session — never the raw API key. Do not
-ship `ABLO_API_KEY` in a browser bundle.
+**Keys & runtime.** Ablo is ESM-only (`import`, not `require`) and needs Node
+22+ and TypeScript 5+. Grab an `sk_test_*` key
+for a sandbox (`export ABLO_API_KEY=sk_test_...`); keep keys in trusted server
+runtimes only. In the browser, `<AbloProvider>` authenticates with the signed-in
+user's session — never the raw key.
 
 ## Quick Start
 
@@ -74,139 +77,202 @@ Expected output:
 { id: '...', status: 'ready' }
 ```
 
-Pass `schema` to get typed models like `ablo.weatherReports.update(...)`. Omit it
-only for the lower-level client used by custom agents and MCP routes that can't
-import your app's schema.
+Pass `schema` to get typed models like `ablo.weatherReports.update(...)`.
 
-Run the package example from this directory:
+## Reading
 
-```bash
-cd examples
-ABLO_API_KEY=sk_test_... npx tsx quickstart.ts
+`retrieve(id)` returns one row from the local cache — synchronous, no round-trip.
+`list(...)` filters and sorts what's already synced; it's also synchronous, and
+reactive under `useAblo`/`subscribe`. `load(...)` fetches from the server when a
+row may not be local yet.
+
+```ts
+ablo.weatherReports.retrieve('report_stockholm'); // → row | undefined
+
+// Synchronous, from the local cache → row[]
+const pending = ablo.weatherReports.list({
+  where: { status: 'pending' },   // equality filter (an array value means IN)
+  orderBy: { location: 'asc' },
+  limit: 20,
+});
+
+// Server fetch → Promise<row[]>. 'complete' waits for the server; 'unknown'
+// returns what's local now and refreshes in the background.
+const ready = await ablo.weatherReports.load({
+  where: { status: 'ready' },
+  type: 'complete',
+});
 ```
 
-For a production integration with React, an existing backend, Data Source, and
-future agents, read [Integration Guide](./docs/integration-guide.md).
+## Writing
 
-## AI Activity on Existing State
+`create` / `update` apply optimistically and resolve to the row. Two options
+matter day to day:
 
-When AI or background work will spend real time on an existing row — not just a
-one-shot write — coordinate through `ablo.<model>.intent(id)`, the coordination
-accessor that sits beside `create`/`update`/`retrieve`. It takes the row's `id` (the same
-id you pass to `retrieve(id)` / `update(id, …)`) and returns a handle
-synchronously, so you can see who's already working on a row before you start.
+| Option | Values | What it does |
+| --- | --- | --- |
+| `wait` | `'queued'` \| `'confirmed'` | `'confirmed'` resolves only after the server acks the write; `'queued'` resolves as soon as it's locally queued (fire-and-forget). |
+| `idempotencyKey` | `string` | Auto-generated per call. Override only when you own the retry boundary (e.g. a job id) so a re-run dedupes server-side. |
 
 ```ts
-// `report_stockholm` is this weather report's id — set at create time, or the
-// `created.id` returned above.
-const report = ablo.weatherReports.intent('report_stockholm');
-
-// Read side: is someone already on it? Wait for them to finish.
-if (report.current) {
-  report.current.heldBy; // 'agent:forecaster'
-  await report.whenFree();
-}
+await ablo.weatherReports.update(id, { status: 'ready' }, { wait: 'confirmed' });
+```
 
-// Write side: claim so other participants yield while we work.
-await report.claim({ action: 'checking_weather', field: 'forecast', ttl: '2m' });
+To guard a write against a row that changed under you, pass `readAt` + `onStale`
+— see [Coordinating long agent work](#coordinating-long-agent-work).
 
-// Your existing weather tool or agent call. While this runs, other clients see
-// that report_stockholm is being checked.
-const row = ablo.weatherReports.retrieve('report_stockholm');
-const weather = await weatherAgent.getWeather(row.location);
+## Coordinating long agent work
 
-await report.update({
-  status: 'ready',
-  forecast: weather.summary,
-});
+An agent reads a row, thinks for 30s, writes back — and clobbers whatever changed
+meanwhile, or worse, acts on stale state. `claim` holds the row across that gap:
+
+```ts
+await ablo.weatherReports.claim('report_stockholm', async (report) => {
+  // If someone else holds it, claim() WAITS in a fair queue, then re-reads —
+  // so `report` is the current row, never a stale snapshot. Reads stay open by
+  // default; only acting-on-the-row serializes.
+
+  const forecast = await weatherAgent.getWeather(report.location); // slow LLM gap
+  await ablo.weatherReports.update(report.id, { forecast, status: 'ready' });
+}); // claim released here, whether the callback returns or throws
 ```
 
-Ablo does not fetch the weather. It keeps the activity visible while the work
-runs, rejects `report.update(...)` with `AbloStaleContextError` if the row
-changed under you, and finishes the claim automatically once the write lands.
+See who's mid-edit before you act — decide to wait, or skip:
 
-## Multiplayer
+```ts
+ablo.weatherReports.claimState('report_stockholm'); // → the holder, or null
+ablo.weatherReports.queue('report_stockholm');    // → { data: [{ heldBy, action, position }, …] }
 
-There is no separate multiplayer mode. When human UI, server actions, and agent
-workers share the same schema and write through `ablo.<model>`, they all see
-each other's changes in real time — that's the default, not a feature you turn on.
+await ablo.weatherReports.claim(id, async (report) => {
+  /* do the held work */
+}, { wait: false });      // held? skip (dedup) — throws instead of waiting
 
-- `ablo.<model>.create/update/delete` fan out confirmed deltas to subscribers.
-- `useAblo(...)` gives React clients the live row plus active intents.
-- `ablo.<model>.intent(id)` lets humans and agents see and coordinate active work before a write lands.
-
-Always write through Ablo — the SDK (`ablo.<model>.create/update/delete`) or the
-HTTP API (`POST /v1/commits`). If you write straight to your own database
-instead, those changes won't reach connected clients. Use Ablo's endpoints and
-the fan-out is automatic.
-
-Under the hood, capabilities, tasks, leases, intents, commits, and receipts are
-real protocol primitives. They exist so agent work is scoped, coordinated,
-attributable, and cleaned up if a runtime disappears — but you don't touch them
-in a first integration. The default path above is enough.
-
-## HTTP API
-
-The SDK is a typed wrapper over a signed HTTP API, the same way `stripe-node`
-wraps Stripe's REST API. Everything you do through `ablo.<model>` is reachable
-over HTTP, so backends in other languages and server-to-server callers work
-without the SDK.
-
-Writes — create, update, and delete — all go through one endpoint as a batch of
-operations:
-
-```http
-POST /v1/commits
-Authorization: Bearer sk_live_...
-Idempotency-Key: <your-unique-id>
-
-{
-  "operations": [
-    {
-      "type": "UPDATE",
-      "model": "weatherReports",
-      "id": "report_stockholm",
-      "input": { "status": "ready" },
-      "readAt": 1042,
-      "onStale": "reject"
-    }
-  ]
+await ablo.weatherReports.claim(id, async (report) => {
+  /* do the held work */
+}, { maxQueueDepth: 2 }); // 2+ already ahead? bail
+```
+
+Default reads keep working while a row is claimed. Server reads that need claimed
+semantics can opt in with `ifClaimed: 'return' | 'wait' | 'fail'`.
+
+Even an unclaimed write can't land on stale reasoning — the commit is guarded:
+
+```ts
+try {
+  await ablo.weatherReports.update(id, { status: 'ready' }, { readAt, onStale: 'reject' });
+} catch (e) {
+  if (e instanceof AbloStaleContextError) { /* row moved under you — re-read, retry */ }
 }
 ```
 
-Each operation is one `CREATE` / `UPDATE` / `DELETE` (plus `ARCHIVE` /
-`UNARCHIVE`). Reads fetch a single row with `GET /v1/resources/{model}/{id}`.
-The same API key, scope, idempotency, and stale-write rules apply as in the SDK
-— the SDK just removes the boilerplate.
+> Prefer the callback form for ordinary held work. Manual scoped claims are
+> available for wider lifetimes, but callback claims are the docs default.
 
-## Load vs Retrieve
+See [Coordination](./docs/coordination.md) for the full `claim` / `claimState` /
+`queue` / `release` reference.
 
-Most reads are `retrieve` — it's the everyday path, especially inside `useAblo(...)`:
+## React
 
-- `ablo.weatherReports.retrieve(id)` is sync. It returns the already-loaded row from
-  the local pool (or `undefined` if it isn't loaded yet). In React,
-  `useAblo((ablo) => ablo.weatherReports.retrieve(id))` keeps that read live.
-- `ablo.weatherReports.load({ where })` is async. Reach for it when you need to
-  guarantee a row is hydrated before you read it — initial fetch, SSR, scripts, or
-  any non-reactive runtime.
+In a React app it's the **same `ablo.<model>` API** — just mounted through a
+provider and read with hooks, from `@abloatai/ablo/react`. Wrap your tree once;
+everything inside is live.
 
-## Persistence
+```tsx
+import { AbloProvider, useAblo } from '@abloatai/ablo/react';
+import { schema } from './ablo.schema';
 
-Ablo keeps local state in memory by default. That keeps the SDK focused on
-coordinating shared state, rather than silently turning every browser app into
-an offline database it didn't ask for.
+function App() {
+  return (
+    <AbloProvider schema={schema}>
+      <Report id="report_stockholm" />
+    </AbloProvider>
+  );
+}
 
-Opt into a durable browser cache and offline write queue when you want it:
+function Report({ id }: { id: string }) {
+  // Reactive read: this re-renders whenever the row changes — whether you,
+  // a teammate, or an agent changed it.
+  const report = useAblo((ablo) => ablo.weatherReports.retrieve(id));
+  const ablo = useAblo();
 
-```ts
-const ablo = Ablo({
-  schema,
-  apiKey: process.env.ABLO_API_KEY,
-  persistence: 'indexeddb',
-});
+  if (!report) return null;
+
+  // Write: same method as the server example above. Optimistic; fans out.
+  return (
+    <button onClick={() => ablo?.weatherReports.update(id, { status: 'ready' })}>
+      {report.status}
+    </button>
+  );
+}
 ```
 
-Node, SSR, tests, and agents use volatile in-memory persistence automatically.
+`<AbloProvider>` owns the connection — no API key in the browser. That's the
+whole loop: read with `useAblo(selector)`, write with `ablo.<model>`, and every
+other client (human or agent) on that row sees it in real time. See
+[React](./docs/react.md) for the full `<AbloProvider>` prop surface (`userId`,
+`teamIds`, `syncGroups`, `fallback`, `bootstrapMode`) and status hooks.
+
+## Identity & Sync Groups
+
+Ablo is **not** an auth provider — you keep your own (Clerk, Auth0, NextAuth,
+whatever). Ablo's job starts after you've authenticated a request: you tell it
+*who* is connecting, and it scopes their realtime data to the right **sync
+groups** (named channels like `org:acme` or `deck:abc123` that are both the unit
+of fan-out and the unit of access).
+
+The model is a proxy: your `ABLO_API_KEY` stays on your trusted server, your
+server resolves the signed-in user (org / team / user) from your own auth, and
+the browser connects as an already-scoped participant — it never holds the key
+and can't widen its own scope. Your schema's `identityRoles` map that identity
+to sync-group strings.
+
+```tsx
+// userId / teamIds come from YOUR auth, resolved server-side
+<AbloProvider schema={schema} userId={user.id} teamIds={user.teamIds}>
+  <App />
+</AbloProvider>
+```
+
+If it isn't obvious where org / team / user come from in the Quick Start above,
+that's because they come from *your* app — see
+[Identity & Sync Groups](./docs/identity.md) for the full picture: what a sync
+group is, the two halves of scoping (`identityRoles` + per-model `orgScoped` /
+`syncGroupFormat`), and how identity reaches Ablo without an API key in the
+browser.
+
+## Multiplayer
+
+There is no separate multiplayer mode. When human UI, server actions, and agent
+workers share the same schema and write through `ablo.<model>`, they all see
+each other's changes in real time — that's the default, not a feature you turn on.
+
+- `ablo.<model>.create/update/delete` fan out confirmed deltas to subscribers.
+- `useAblo(...)` gives React clients the live row, kept current automatically.
+- `ablo.<model>.claim(id)` / `claimState(id)` / `queue(id)` let humans and agents coordinate (and observe) active work on a row — and the line waiting behind it — before a write lands.
+
+Always write through Ablo — either the SDK model methods
+(`ablo.<model>.create/update/delete`) or the HTTP write endpoint below. If you
+write straight to your own database instead, those changes won't reach connected
+clients.
+
+## HTTP Writes
+
+Use the SDK when you are in JavaScript and want typed models or realtime. Use the
+HTTP endpoint when a server-to-server caller needs to write without opening a
+WebSocket:
+
+```bash
+curl https://api.ablo.dev/v1/commits \
+  -H "Authorization: Bearer sk_test_..." \
+  -H "Content-Type: application/json" \
+  -d '{ "operations": [
+        { "action": "update", "model": "weatherReports", "id": "report_stockholm", "data": { "status": "ready" } }
+      ] }'
+```
+
+```json
+{ "object": "commit_receipt", "status": "confirmed", "serverTxId": "tx_…", "lastSyncId": 1042, "ops": 1 }
+```
 
 ## Connect Your Database
 
@@ -216,35 +282,76 @@ write to Ablo-managed state.
 
 If your existing database stays the source of truth, connect it as a Data
 Source: Ablo sends signed commit requests to an endpoint you host, and your app
-writes its own database. Ablo never sees your database credentials — only the
-API key:
+writes its own database. Your `DATABASE_URL` stays in your app — Ablo only ever
+sees the API key.
 
-```bash
-# stays in your app — Ablo never receives this
-DATABASE_URL=postgres://...
+See [Connect Your Database](./docs/data-sources.md) for the integration shape.
 
-# the only Ablo credential your app needs
-ABLO_API_KEY=sk_live_...
-```
+## Configuration
 
-See [Connect Your Database](./docs/data-sources.md) for the route and commit shape.
+`Ablo({ ... })` takes one required option and a couple of transport overrides:
 
-## Agent Runs
+| Option | Type | Default | Purpose |
+| --- | --- | --- | --- |
+| `schema` | `Schema` | — (required) | Typed model proxies (`ablo.<model>.*`) |
+| `apiKey` | `string \| ApiKeySetter \| null` | `process.env.ABLO_API_KEY` | Server key — a string, or an async function for rotation |
+| `baseURL` | `string` | `wss://mesh.ablo.finance` | Point at a self-hosted or staging mesh |
+
+Keep `apiKey` in trusted server runtimes. In the browser, `<AbloProvider>`
+authenticates with the signed-in user's session; the raw-key path is gated
+behind `dangerouslyAllowBrowser` for server-proxy setups only. Self-hosted
+deployments can pass `authToken` instead of `apiKey`. Advanced hooks (custom
+`fetch`, logging, observability) live in [Client Behavior](./docs/client-behavior.md).
+
+## Errors
+
+Every SDK error extends `AbloError` and carries a `requestId` for support.
+Discriminate with `instanceof` or the `type` string — the string form also
+survives worker / `postMessage` boundaries, where `instanceof` does not:
+
+```ts
+try {
+  await ablo.weatherReports.update(id, { status: 'ready' }, { readAt, onStale: 'reject' });
+} catch (e) {
+  if (e instanceof AbloStaleContextError) { /* row moved under you — re-read, retry */ }
+  if ((e as AbloError).type === 'AbloClaimedError') { /* another participant holds it */ }
+}
+```
 
-Most agent workers should import the same schema and use
-`ablo.<model>.load(...)` plus `ablo.<model>.update(...)`. The schema-less
-`agent.run(...)` wrapper exists for advanced workers that intentionally cannot
-import the app schema.
+| Error | When |
+| --- | --- |
+| `AbloAuthenticationError` | Invalid / missing / expired credentials |
+| `AbloPermissionError` / `CapabilityError` | Action forbidden by scope |
+| `AbloRateLimitError` | Rate limited (carries `retryAfterSeconds`) |
+| `AbloIdempotencyError` | Same `idempotencyKey` reused with a different body |
+| `AbloValidationError` | Invalid request payload |
+| `AbloStaleContextError` | Write carried `readAt`, but the row has newer changes (`conflicts`) |
+| `AbloClaimedError` | Target is claimed by another participant (`claims`) |
+| `AbloConnectionError` / `AbloServerError` | Transport failure / server 5xx |
+| `SyncSessionError` | Session expired (prompts re-auth) |
+
+## Reconnect & retries
+
+The client owns reconnection so your code doesn't have to. A dropped WebSocket
+reconnects automatically with exponential backoff (1s → 30s, ±15% jitter, up to
+~7.5 minutes); session errors (401/403) suppress it so you re-authenticate
+instead of looping. Commits are idempotent by client transaction id, and a
+commit that times out is never silently rolled back — the client reconciles
+against authoritative server state on reconnect. These defaults are the
+contract; there are no retry or timeout knobs to tune.
 
 ## Production Reference
 
-- [Guarantees](./docs/guarantees.md) — confirmed writes, stale-write protection, intent coordination, and agent lifecycle.
+- [Identity & Sync Groups](./docs/identity.md) — bring your own auth; tell Ablo who's connecting and how org / team / user map to sync-group scope.
+- [Guarantees](./docs/guarantees.md) — confirmed writes, stale-write protection, claim coordination, and agent lifecycle.
 - [Integration Guide](./docs/integration-guide.md) — pick the backing mode and integrate React, Data Source, multiplayer, and agents.
+- [React](./docs/react.md) — `<AbloProvider>`, `useAblo`, presence, status, and bootstrap gating.
+- [Coordination](./docs/coordination.md) — `claim` / `claimState` / `queue` / `release` reference: hold a row across slow agent work, and observe the line waiting behind it.
 - [Client Behavior](./docs/client-behavior.md) — options, errors, retries, timeouts, and public imports.
 - [Connect Your Database](./docs/data-sources.md) — keep canonical rows in your app database without giving Ablo database credentials.
 - [Existing Python Backend](./docs/examples/existing-python-backend.md) — migrate existing Python endpoints to multiplayer and agent-safe writes gradually.
 - [AI SDK Tool](./docs/examples/ai-sdk-tool.md) — use Ablo inside an AI SDK tool call.
-- [Server Agent](./docs/examples/server-agent.md) — schema-backed worker plus advanced schema-less run.
+- [Server Agent](./docs/examples/server-agent.md) — schema-backed worker.
 
 ## License
 

package/dist/BaseSyncedStore.d.ts

@@ -21,7 +21,7 @@ import { QueryProcessor } from './core/QueryProcessor.js';
 import { Model } from './Model.js';
 import { ModelScope } from './ObjectPool.js';
 import type { Schema } from './schema/schema.js';
-import { type ReaderActions } from './react/useReader.js';
+import { type ReaderActions } from './mutators/readerActions.js';
 /** Constructor type for Model subclasses (accepts abstract classes) */
 export type ModelConstructor<T extends Model> = abstract new (...args: never[]) => T;
 /** Concrete constructor type for instantiation */
@@ -139,7 +139,7 @@ export interface UserContext {
      *  - `'full'` (default): pull every delta in scope before `ready()`
      *    resolves. The standard browser/user replica behavior.
      *  - `'none'`: open the WebSocket and process live deltas only.
-     *    Reads go through `resource.retrieve()` / filtered subscriptions
+     *    Reads go through `model.retrieve()` / filtered subscriptions
      *    backfilled by `Covering` deltas. Suitable for transactional
      *    participants — agent-worker, video-pipeline, routine runners —
      *    that don't need a local replica of the org's tenant plane.

package/dist/BaseSyncedStore.js

@@ -22,7 +22,7 @@ import { getContext } from './context.js';
 import { SyncSessionError } from './errors.js';
 import { ModelScope } from './ObjectPool.js';
 import { LazyReferenceCollection } from './LazyReferenceCollection.js';
-import { createReaderActions } from './react/useReader.js';
+import { createReaderActions } from './mutators/readerActions.js';
 /** Bootstrap timeout configuration */
 export const BOOTSTRAP_CONFIG = {
     OVERALL_TIMEOUT_MS: 15_000,
@@ -790,7 +790,7 @@ export class BaseSyncedStore {
             //
             // `bootstrapMode: 'none'` participants (agent-worker, headless
             // task runners) skip baseline replication — they read via
-            // `resource.retrieve()` round-trips and rely on covering deltas
+            // `model.retrieve()` round-trips and rely on covering deltas
             // from filtered subscriptions to populate the pool lazily. The
             // WS is already open by `setupWebSocketSync` above, so live
             // delta flow works regardless of this branch.

package/dist/api/index.d.ts

@@ -2,9 +2,9 @@
  * Internal compatibility entrypoint for the stateless hosted protocol client.
  *
  * Use this build for serverless functions, scripts, and backends that want
- * Resource / Intent / Commit over HTTP without the realtime sync runtime.
+ * model reads/writes and commits over HTTP without the realtime sync runtime.
  */
-export { createProtocolClient, createProtocolClient as Ablo, type AbloApi, type AbloApiClientOptions, type AbloApiIntents, type Agent, type AgentIntentInput, type AgentIntentOptions, type AgentOptions, type AgentResourceClient, type AgentResourceReadOptions, type AgentResourceMutationOptions, type AgentRunContext, type AgentRunDone, type AgentRunFailed, type AgentRunCancelled, type AgentRunOptions, type AgentRunResult, type AgentRunStatus, type Capability, type CapabilityCreateOptions, type CapabilityParticipantKind, type CapabilityRecord, type CapabilityResource, type CapabilityRevocation, type CapabilityScope, type Task, type TaskCloseOptions, type TaskCloseResult, type TaskCreateOptions, type TaskResource, } from '../client/ApiClient.js';
-export type { CommitCreateOptions, CommitOperationInput, CommitReceipt, CommitWait, IntentCreateOptions, IntentHandle, IntentWaitOptions, BusyOptions, BusyPolicy, ResourceClient, ResourceIntent, ResourceMutationOptions, ResourceReadOptions, ResourceRead, ResourceTarget, } from '../client/Ablo.js';
+export { createProtocolClient, createProtocolClient as Ablo, type AbloApi, type AbloApiClientOptions, type AbloApiIntents, type Agent, type AgentIntentInput, type AgentIntentOptions, type AgentOptions, type AgentModelClient, type AgentModelReadOptions, type AgentModelMutationOptions, type AgentRunContext, type AgentRunDone, type AgentRunFailed, type AgentRunCancelled, type AgentRunOptions, type AgentRunResult, type AgentRunStatus, type Capability, type CapabilityCreateOptions, type CapabilityParticipantKind, type CapabilityRecord, type CapabilityResource, type CapabilityRevocation, type CapabilityScope, type Task, type TaskCloseOptions, type TaskCloseResult, type TaskCreateOptions, type TaskResource, } from '../client/ApiClient.js';
+export type { CommitCreateOptions, CommitOperationInput, CommitReceipt, CommitWait, IntentCreateOptions, IntentHandle, IntentWaitOptions, 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

@@ -2,7 +2,7 @@
  * Internal compatibility entrypoint for the stateless hosted protocol client.
  *
  * Use this build for serverless functions, scripts, and backends that want
- * Resource / Intent / Commit over HTTP without the realtime sync runtime.
+ * 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';