@abloatai/ablo 0.8.0 → 0.9.1

package/docs/examples/agent-human.md

@@ -12,16 +12,17 @@ The same reports are edited by both humans and agents. They must not collide:
   the human's newer edit.
 
 A **claim** does both jobs. 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. And once you hold a claim, any `update`
-you make inside it is stale-checked for free: the SDK records the row version you
-were handed and rejects the write with a typed error if the row moved underneath
-you while the agent was busy.
+`claim` waits for them, re-reads the fresh row, then hands it back to you on
+`claim.data`, so two writers serialize instead of clobbering. The handle is an
+`AsyncDisposable`: hold it with `await using` and it releases on scope exit. And
+once you hold a claim, any `update` you make while it's held is stale-checked for
+free: the SDK records the row version you were handed and rejects the write with
+a typed error if the row moved underneath you while the agent was busy.
 
 ## Schema-Backed Worker
 
 The worker uses the same schema client the app uses. It reads the report from
-the server with `retrieve(id)`, claims the row, and writes through
+the server with `retrieve({ id })`, claims the row, and writes through
 `ablo.weatherReports.update(...)` with a stale-check so a human's concurrent edit
 can't be overwritten.
 
@@ -41,42 +42,43 @@ const ablo = Ablo({ schema, apiKey: process.env.ABLO_API_KEY });
 export async function markReady(reportId: string) {
   await ablo.ready();
 
-  // retrieve(id) is an async server read — await it.
-  const report = await ablo.weatherReports.retrieve(reportId);
+  // retrieve({ id }) is an async server read — await it.
+  const report = await ablo.weatherReports.retrieve({ id: reportId });
   if (!report) return { status: 'not_found' };
 
   try {
-    const updated = await ablo.weatherReports.claim(
-      reportId,
-      async (claimed) =>
-        // Inside an active claim, `update` is stale-checked automatically: the
-        // SDK attaches the claim's snapshot version as `readAt` and sets
-        // `onStale: 'reject'`. The write below is therefore equivalent to
-        // passing those options yourself:
-        //
-        //   ablo.weatherReports.update(claimed.id, { status: 'ready' }, {
-        //     wait: 'confirmed',
-        //     readAt: <claim snapshot version>,
-        //     onStale: 'reject',
-        //   });
-        //
-        // If a human saved a newer version mid-run, the row no longer matches
-        // `readAt`, so the server rejects this commit with AbloStaleContextError
-        // (caught below) instead of clobbering their edit.
-        ablo.weatherReports.update(
-          claimed.id,
-          { status: 'ready' },
-          { wait: 'confirmed' },
-        ),
-      {
-        // wait: false → don't queue behind a current holder. If a human already
-        // holds the row, claim rejects with AbloClaimedError (caught below), so
-        // the agent yields instead of waiting. Omit it, or pass wait: true, to
-        // queue behind them. action → the label observers see while we work.
-        wait: false,
-        action: 'marking_ready',
-      },
-    );
+    // wait: false → don't queue behind a current holder. If a human already
+    // holds the row, claim rejects with AbloClaimedError (caught below), so the
+    // agent yields instead of waiting. Omit it, or pass wait: true, to queue
+    // behind them. action → the label observers see while we work.
+    await using claim = await ablo.weatherReports.claim({
+      id: reportId,
+      wait: false,
+      action: 'marking_ready',
+    });
+    const claimed = claim.data;
+
+    // Inside an active claim, `update` is stale-checked automatically: the SDK
+    // attaches the claim's snapshot version as `readAt` and sets
+    // `onStale: 'reject'`. The write below is therefore equivalent to passing
+    // those options yourself:
+    //
+    //   ablo.weatherReports.update({
+    //     id: claimed.id,
+    //     data: { status: 'ready' },
+    //     wait: 'confirmed',
+    //     readAt: <claim snapshot version>,
+    //     onStale: 'reject',
+    //   });
+    //
+    // If a human saved a newer version mid-run, the row no longer matches
+    // `readAt`, so the server rejects this commit with AbloStaleContextError
+    // (caught below) instead of clobbering their edit.
+    const updated = await ablo.weatherReports.update({
+      id: claimed.id,
+      data: { status: 'ready' },
+      wait: 'confirmed',
+    });
 
     return { status: 'ready', report: updated };
   } catch (err) {
@@ -101,7 +103,7 @@ import { useAblo } from '@abloatai/ablo/react';
 
 export function ReportRow({ report: serverReport }: Props) {
   const data = useAblo((ablo) => ablo.weatherReports.get(serverReport.id)) ?? serverReport;
-  const active = useAblo((ablo) => ablo.weatherReports.claim.state(serverReport.id));
+  const active = useAblo((ablo) => ablo.weatherReports.claim.state({ id: serverReport.id }));
   const agentActive = active?.participantKind === 'agent';
 
   return (
@@ -116,10 +118,10 @@ export function ReportRow({ report: serverReport }: Props) {
 ## Why It Works
 
 - The claim is visible to everyone: the UI reads it synchronously with
-  `claim.state(id)`, and it also arrives over the live stream.
-- `claim(id, work)` makes writers take turns instead of racing — with
+  `claim.state({ id })`, and it also arrives over the live stream.
+- `claim({ id })` makes writers take turns instead of racing — with
   `wait: false`, the agent simply yields when a human already holds the row.
-- The `update` inside the claim is stale-checked automatically, so a human's
+- The `update` made while the claim is held is stale-checked automatically, so a human's
   edit landing mid-run rejects the agent's write with a typed
   `AbloStaleContextError` instead of overwriting it.
 - That same write carries the claim, so each accepted change is attributed to

package/docs/examples/ai-sdk-tool.md

@@ -34,26 +34,30 @@ const updateReport = tool({
     await ablo.ready();
 
     // retrieve hits the server for the latest row (async — await it).
-    const report = await ablo.weatherReports.retrieve(reportId);
+    const report = await ablo.weatherReports.retrieve({ id: reportId });
     if (!report) return { ok: false, reason: 'not_found' };
 
     // If another agent or user already holds this row, claim waits for them
-    // to finish, re-reads the fresh row, then runs the callback. The claim
-    // is released when the callback returns or throws.
-    return ablo.weatherReports.claim(
-      reportId,
-      async (claimed) => {
-        // Because you hold the claim, this update is rejected if the row
-        // changed underneath you, instead of silently overwriting it.
-        const updated = await ablo.weatherReports.update(claimed.id, {
-          status: status ?? claimed.status,
-          forecast: forecast ?? claimed.forecast,
-        });
+    // to finish, re-reads the fresh row, then hands it back on `claim.data`.
+    // The claim is released automatically when it goes out of scope.
+    await using claim = await ablo.weatherReports.claim({
+      id: reportId,
+      action: 'editing',
+      ttl: '2m',
+    });
+    const claimed = claim.data;
 
-        return { ok: true, report: updated };
+    // Because you hold the claim, this update is rejected if the row
+    // changed underneath you, instead of silently overwriting it.
+    const updated = await ablo.weatherReports.update({
+      id: claimed.id,
+      data: {
+        status: status ?? claimed.status,
+        forecast: forecast ?? claimed.forecast,
       },
-      { action: 'editing', ttl: '2m' },
-    );
+    });
+
+    return { ok: true, report: updated };
   },
 });
 
@@ -73,5 +77,5 @@ The model provider is interchangeable. What matters is that the tool:
 - reads the latest weather report with `retrieve` (a server read),
 - claims the row — if someone else holds it, the claim waits for them, then re-reads,
 - writes through `update`, which is rejected if the row changed underneath you,
-- releases the claim automatically when the callback returns or throws,
+- releases the claim automatically when the handle goes out of scope,
 - waits for server confirmation.

package/docs/examples/existing-python-backend.md

@@ -87,7 +87,7 @@ export function ReportRow({
   report: { id: string; location: string; status: string };
 }) {
   const report = useAblo((ablo) => ablo.weatherReports.get(serverReport.id)) ?? serverReport;
-  const active = useAblo((ablo) => ablo.weatherReports.claim.state(serverReport.id));
+  const active = useAblo((ablo) => ablo.weatherReports.claim.state({ id: serverReport.id }));
   const claimed = Boolean(active);
 
   return (
@@ -213,11 +213,13 @@ The app does not need a flag-day rewrite. Move one model at a time.
 ```ts
 const snap = ablo.snapshot({ weatherReports: reportId });
 
-await ablo.weatherReports.update(
-  reportId,
-  { status: 'ready' },
-  { readAt: snap.stamp, onStale: 'reject', wait: 'confirmed' },
-);
+await ablo.weatherReports.update({
+  id: reportId,
+  data: { status: 'ready' },
+  readAt: snap.stamp,
+  onStale: 'reject',
+  wait: 'confirmed',
+});
 ```
 
 Use `readAt` and `onStale: 'reject'` for actions that depend on state the user
@@ -247,14 +249,16 @@ and timestamp. If the change originated from an Ablo commit, include the same
 Agents use the same model API as the UI:
 
 ```ts
-const report = await ablo.weatherReports.retrieve(reportId);
+const report = await ablo.weatherReports.retrieve({ id: reportId });
 const snap = ablo.snapshot({ weatherReports: reportId });
 
-await ablo.weatherReports.update(
-  reportId,
-  { status: 'ready' },
-  { readAt: snap.stamp, onStale: 'reject', wait: 'confirmed' },
-);
+await ablo.weatherReports.update({
+  id: reportId,
+  data: { status: 'ready' },
+  readAt: snap.stamp,
+  onStale: 'reject',
+  wait: 'confirmed',
+});
 ```
 
 Agents reach for the exact same calls the UI does — the same write contract

package/docs/examples/nextjs.md

@@ -38,7 +38,7 @@ export default async function ReportPage({
   params,
 }: { params: { id: string } }) {
   await ablo.ready();
-  const report = await ablo.weatherReports.retrieve(params.id);
+  const report = await ablo.weatherReports.retrieve({ id: params.id });
   if (!report) return null;
 
   return <ReportEditor report={report} />;
@@ -54,22 +54,24 @@ export default async function ReportPage({
 import { ablo } from '@/lib/ablo';
 
 export async function markReady(id: string) {
-  const report = await ablo.weatherReports.claim(
+  await using claim = await ablo.weatherReports.claim({
     id,
-    async (claimed) =>
-      ablo.weatherReports.update(
-        claimed.id,
-        { status: 'ready' },
-        { wait: 'confirmed' },
-      ),
-    { wait: false, action: 'marking_ready' },
-  );
+    wait: false,
+    action: 'marking_ready',
+  });
+  const claimed = claim.data;
+
+  const report = await ablo.weatherReports.update({
+    id: claimed.id,
+    data: { status: 'ready' },
+    wait: 'confirmed',
+  });
 
   return { status: 'ready', report };
 }
 ```
 
-The write runs inside the `claim` callback. If another participant commits
+The write runs while the `claim` is held. If another participant commits
 between the read and the write, the commit is rejected because the row changed
 underneath you. The action can re-fetch and ask the user to retry.
 
@@ -82,7 +84,7 @@ import { useAblo } from '@abloatai/ablo/react';
 
 export function ReportEditor({ report: serverReport }: Props) {
   const data = useAblo((ablo) => ablo.weatherReports.get(serverReport.id)) ?? serverReport;
-  const active = useAblo((ablo) => ablo.weatherReports.claim.state(serverReport.id));
+  const active = useAblo((ablo) => ablo.weatherReports.claim.state({ id: serverReport.id }));
   const claimed = Boolean(active);
 
   return (

package/docs/examples/scoped-agent.md

@@ -78,7 +78,7 @@ const ablo = useAblo<(typeof schema)['models']>();
 // Other participants subscribed to deck:<deckId> — the human in the editor,
 // a reviewer agent — receive this delta in realtime. Participants on other
 // decks never see it.
-await ablo.slides.update(slideId, { body: 'Q4 revenue up 12% YoY' });
+await ablo.slides.update({ id: slideId, data: { body: 'Q4 revenue up 12% YoY' } });
 ```
 
 The slide's delta is stamped `deck:<deckId>`, derived server-side from the

package/docs/examples/server-agent.md

@@ -5,12 +5,13 @@ reads and writes your app's records outside the browser. The hard part is doing
 it without racing the live UI: if your worker and a user edit the same report at
 once, one write clobbers the other. This is what `claim()` is for. Below, a
 worker finishes a weather report by claiming it, writing the result, and
-releasing it — all in one call.
+releasing it automatically when the claim goes out of scope.
 
-`claim(id, work)` takes the record for your worker, runs your update inside the
-callback, then releases it when the callback returns. 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.
+`claim({ id })` takes the record for your worker and returns a disposable handle:
+the fresh post-lease row is on `claim.data`, and holding the handle with
+`await using` releases the claim on scope exit (or call `claim.release()`). 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.
 
 ```ts
 import Ablo from '@abloatai/ablo';
@@ -32,35 +33,37 @@ const ablo = Ablo({
 export async function completeReport(reportId: string) {
   await ablo.ready();
 
-  const report = await ablo.weatherReports.retrieve(reportId);
+  const report = await ablo.weatherReports.retrieve({ id: reportId });
   if (!report) return { status: 'not_found' };
 
-  const updated = await ablo.weatherReports.claim(
-    reportId,
-    async (claimed) =>
-      ablo.weatherReports.update(
-        claimed.id,
-        { status: 'ready' },
-        { wait: 'confirmed' },
-      ),
-    { wait: false, action: 'completing' },
-  );
+  await using claim = await ablo.weatherReports.claim({
+    id: reportId,
+    wait: false,
+    action: 'completing',
+  });
+  const claimed = claim.data;
+
+  const updated = await ablo.weatherReports.update({
+    id: claimed.id,
+    data: { status: 'ready' },
+    wait: 'confirmed',
+  });
 
   return { status: 'ready', report: updated };
 }
 ```
 
-`retrieve(id)` is an async server read — it hits the server and returns the row
-(or `null`, which the early `not_found` guard handles). The update runs inside
-the claim callback, and `{ wait: 'confirmed' }` makes that update resolve only
-once the server has accepted it.
+`retrieve({ id })` is an async server read — it hits the server and returns the
+row (or `null`, which the early `not_found` guard handles). The update runs while
+the claim is held, and `wait: 'confirmed'` makes that update resolve only once
+the server has accepted it.
 
 The two options on the claim:
 
 - `wait: false` — skip this record if another claim is already in progress,
   rather than queueing behind it. (The default queues.)
 - `action: 'completing'` — a human-readable label for what your worker is doing,
-  visible to anyone reading `claim.state(id)`.
+  visible to anyone reading `claim.state({ id })`.
 
 Because the worker uses the same schema and `claim()` as the UI, its writes sync
 to every connected client in real time and never collide with edits already in

package/docs/guarantees.md

@@ -16,11 +16,11 @@ of clobbering.
 the authoritative sync cursor.
 
 ```ts
-const updated = await ablo.weatherReports.update(
-  'report_stockholm',
-  { status: 'ready' },
-  { wait: 'confirmed' },
-);
+const updated = await ablo.weatherReports.update({
+  id: 'report_stockholm',
+  data: { status: 'ready' },
+  wait: 'confirmed',
+});
 ```
 
 If the call resolves, the write was accepted by the server. If it rejects, the
@@ -51,11 +51,13 @@ read:
 ```ts
 const snap = ablo.snapshot({ weatherReports: 'report_stockholm' });
 
-await ablo.weatherReports.update(
-  'report_stockholm',
-  { status: 'ready' },
-  { readAt: snap.stamp, onStale: 'reject', wait: 'confirmed' },
-);
+await ablo.weatherReports.update({
+  id: 'report_stockholm',
+  data: { status: 'ready' },
+  readAt: snap.stamp,
+  onStale: 'reject',
+  wait: 'confirmed',
+});
 ```
 
 `onStale: 'reject'` prevents lost updates. If the target changed after the
@@ -76,17 +78,17 @@ Advanced policies exist for controlled product flows:
 
 Claims are live coordination signals. They are not database locks.
 
-`ablo.<model>.claim(id, ...)` serializes on contention: if another human or agent
+`ablo.<model>.claim({ id })` serializes on contention: if another human or agent
 already holds the row, the claim waits for them to finish, then re-reads the row
 before handing it back, so you proceed from fresh state. Reads stay open while a
-claim is held — `ablo.<model>.claim.state(id)` returns the current claim state
+claim is held — `ablo.<model>.claim.state({ id })` returns the current claim state
 (or `null`) without ever blocking. A server read can pass `ifClaimed: 'wait'` to
 wait for the claim to clear, or `ifClaimed: 'fail'` to error out, when it should
 not return a row while someone else is mid-edit.
 
 A claim does not reject or block other writers; it announces work so peers
 serialize behind it rather than racing. While you hold a claim, the matching
-`ablo.<model>.update(id, ...)` is rejected with `AbloStaleContextError` if the row
+`ablo.<model>.update({ id, ... })` is rejected with `AbloStaleContextError` if the row
 changed underneath you after your claim point.
 
 ## Agent Runs

package/docs/index.md

@@ -13,7 +13,7 @@ changed the row first.
 
 ```ts
 // The same call, whether a person, a server action, or an agent makes it.
-await ablo.deck.update(deckId, { title: "Q3 Strategy" });
+await ablo.deck.update({ id: deckId, data: { title: "Q3 Strategy" } });
 ```
 
 Claims don't lock. If another writer holds the row, `claim` waits for them,
@@ -42,7 +42,7 @@ Three things stay true no matter how you use Ablo:
 - [Quickstart](./quickstart.md) — Make your first schema-backed write.
 - [Schema Contract](./schema-contract.md) — One schema becomes typed model clients, React reads, agent writes, Data Source shape, and schema push.
 - [CLI & Migrations](./cli.md) — `init` / `migrate` / `push` / `generate`, the shared Zod→Postgres type map, and structured migration errors.
-- [Identity & Sync Groups](./identity.md) — Bring your own auth; tell Ablo who's connecting and how org / team / user map to sync-group scope.
+- [Identity & Sync Groups](./identity.md) — Use your own authentication; tell Ablo who's connecting and how org / team / user map to sync-group scope.
 - [Integration Guide](./integration-guide.md) — Choose Ablo-managed state, Data Source, React, multiplayer, and agent patterns.
 - [Guarantees](./guarantees.md) — What confirmed writes, stale checks, and claims guarantee.
 - [Interaction Model](./interaction-model.md) — The schema, claim, update, confirmation loop.

package/docs/integration-guide.md

@@ -225,7 +225,7 @@ and waits.
 ```ts
 await ablo.ready();
 
-const report = await ablo.weatherReports.retrieve('report_stockholm');
+const report = await ablo.weatherReports.retrieve({ id: 'report_stockholm' });
 if (!report) throw new Error('report not found');
 ```
 
@@ -255,7 +255,7 @@ export function ReportRow({
   report: { id: string; location: string; status: string };
 }) {
   const report = useAblo((ablo) => ablo.weatherReports.get(serverReport.id)) ?? serverReport;
-  const active = useAblo((ablo) => ablo.weatherReports.claim.state(serverReport.id));
+  const active = useAblo((ablo) => ablo.weatherReports.claim.state({ id: serverReport.id }));
 
   return <button disabled={Boolean(active) || report.status === 'ready'}>{report.location}</button>;
 }
@@ -272,7 +272,7 @@ const ablo = useAblo();
 For simple writes:
 
 ```ts
-await ablo.weatherReports.update('report_stockholm', { status: 'ready' }, { wait: 'confirmed' });
+await ablo.weatherReports.update({ id: 'report_stockholm', data: { status: 'ready' }, wait: 'confirmed' });
 ```
 
 For writes based on state the user or agent already read, snapshot first and
@@ -281,15 +281,13 @@ reject stale updates:
 ```ts
 const snap = ablo.snapshot({ weatherReports: 'report_stockholm' });
 
-await ablo.weatherReports.update(
-  'report_stockholm',
-  { status: 'ready' },
-  {
-    readAt: snap.stamp,
-    onStale: 'reject',
-    wait: 'confirmed',
-  }
-);
+await ablo.weatherReports.update({
+  id: 'report_stockholm',
+  data: { status: 'ready' },
+  readAt: snap.stamp,
+  onStale: 'reject',
+  wait: 'confirmed',
+});
 ```
 
 `wait: 'confirmed'` resolves after the server accepts the write. Rejections roll
@@ -407,20 +405,20 @@ 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.
 
 ```ts
-const report = await ablo.weatherReports.retrieve(reportId);
+const report = await ablo.weatherReports.retrieve({ id: reportId });
 if (!report) return;
 
-await ablo.weatherReports.claim(
-  reportId,
-  async (claimed) => {
-    await ablo.weatherReports.update(
-      claimed.id,
-      { status: 'ready', forecast: await getForecast(claimed) },
-      { wait: 'confirmed' }
-    );
-  },
-  { wait: false, action: 'forecasting' }
-);
+await using claim = await ablo.weatherReports.claim({
+  id: reportId,
+  wait: false,
+  action: 'forecasting',
+});
+const claimed = claim.data;
+await ablo.weatherReports.update({
+  id: claimed.id,
+  data: { status: 'ready', forecast: await getForecast(claimed) },
+  wait: 'confirmed',
+});
 ```
 
 Use AI SDK for the model loop. Put Ablo inside the tool that persists the final
@@ -435,11 +433,13 @@ const completeReport = tool({
   }),
   execute: async ({ reportId, forecast }) => {
     const snap = ablo.snapshot({ weatherReports: reportId });
-    return ablo.weatherReports.update(
-      reportId,
-      { status: 'ready', forecast },
-      { readAt: snap.stamp, onStale: 'reject', wait: 'confirmed' }
-    );
+    return ablo.weatherReports.update({
+      id: reportId,
+      data: { status: 'ready', forecast },
+      readAt: snap.stamp,
+      onStale: 'reject',
+      wait: 'confirmed',
+    });
   },
 });
 ```
@@ -474,7 +474,7 @@ them.
 | `create(data, options?)`     | Create through the model client.                                            |
 | `update(id, data, options?)` | Update through the model client.                                            |
 | `delete(id, options?)`       | Delete through the model client.                                            |
-| `claim.state(id)`            | See who is currently working on a row (synchronous).                       |
+| `claim.state({ id })`            | See who is currently working on a row (synchronous).                       |
 | `claim(id, work, options?)`  | Wait for your turn, re-read, and hold the row while `work` runs.            |
 
 Keep first integrations on the model methods above.

package/docs/interaction-model.md

@@ -9,11 +9,10 @@ Here's the whole path in one block — claim a row, update it inside the claim,
 let the claim release when your callback returns:
 
 ```ts
-const report = await ablo.weatherReports.retrieve('report_stockholm');
+const report = await ablo.weatherReports.retrieve({ id: 'report_stockholm' });
 
-await ablo.weatherReports.claim('report_stockholm', async (report) => {
-  await ablo.weatherReports.update(report.id, { status: 'ready' }, { wait: 'confirmed' });
-});
+await using claim = await ablo.weatherReports.claim({ id: 'report_stockholm' });
+await ablo.weatherReports.update({ id: claim.data.id, data: { status: 'ready' }, wait: 'confirmed' });
 ```
 
 Claims don't lock. If another writer holds the row, `claim` waits for them,
@@ -26,7 +25,7 @@ of clobbering.
 |---|---|---|
 | `Schema` | State | Declares typed models the app and agents can read and write. |
 | `Model` | State | The generated `ablo.<model>` model. Use `retrieve`/`list` (async server reads), `get`/`getAll`/`getCount` (synchronous local reads), `create`, `update`, and `delete`. |
-| `Claim` | Coordination | Who is working on a target. Taken via `ablo.<model>.claim(id, work)` and read via `ablo.<model>.claim.state(id)`. Ephemeral — never persisted. |
+| `Claim` | Coordination | Who is working on a target. Taken via `ablo.<model>.claim({ id })` and read via `ablo.<model>.claim.state({ id })`. Ephemeral — never persisted. |
 | `Commit` | Protocol | The durable write underneath model updates. Most users do not call it directly. |
 | `Receipt` | Protocol | The lower-level durable result for custom runtimes. Schema writes use `wait: 'confirmed'`. |
 
@@ -50,14 +49,13 @@ expect just `Commit`; here's what the other two buy you over that minimum:
 A normal schema-backed run is:
 
 ```ts
-const report = await ablo.weatherReports.retrieve(id);
-const active = ablo.weatherReports.claim.state(id);
-await ablo.weatherReports.claim(id, async (report) => {
-  await ablo.weatherReports.update(report.id, patch, { wait: 'confirmed' });
-});
+const report = await ablo.weatherReports.retrieve({ id });
+const active = ablo.weatherReports.claim.state({ id });
+await using claim = await ablo.weatherReports.claim({ id });
+await ablo.weatherReports.update({ id: claim.data.id, data: patch, wait: 'confirmed' });
 ```
 
-`retrieve(id)` is an async server read (await it). `claim.state(id)` is a
+`retrieve({ id })` is an async server read (await it). `claim.state({ id })` is a
 synchronous local read of who currently holds the row — it never blocks.
 
 ## Coordination
@@ -65,24 +63,22 @@ synchronous local read of who currently holds the row — it never blocks.
 > Loop view only. Full claim reference — methods, the claim-state object, the
 > `claim.queue`, errors — is [Coordination](./coordination.md).
 
-Claims broadcast across the org. Call `claim(id, callback)`, do your writes with
-the normal `update` inside the callback, and the claim releases automatically
-when the callback returns:
+Claims broadcast across the org. Call `claim({ id })`, do your writes with the
+normal `update` inside the `await using` scope, and the claim releases
+automatically when the scope exits:
 
 ```ts
-await ablo.weatherReports.claim(
-  'report_stockholm',
-  async (report) => {
-    await ablo.weatherReports.update(report.id, { status: 'ready' }); // rejected if the row changed under the claim
-  },
-  { action: 'editing' },
-);
+await using claim = await ablo.weatherReports.claim({
+  id: 'report_stockholm',
+  action: 'editing',
+});
+await ablo.weatherReports.update({ id: claim.data.id, data: { status: 'ready' } }); // rejected if the row changed under the claim
 ```
 
-`ablo.weatherReports.claim.state('report_stockholm')` reads the live claim (or
+`ablo.weatherReports.claim.state({ id: 'report_stockholm' })` reads the live claim (or
 `null`) without blocking. Claims don't lock: if another participant holds the
 row, `claim` waits for them to finish, re-reads, and then hands you the fresh
-row. The same signal is visible to every schema client through `claim.state(id)`
+row. The same signal is visible to every schema client through `claim.state({ id })`
 and the live claim stream.
 
 ## Conflict resolution