@abloatai/ablo 0.51.0 → 0.53.0

package/docs/context.md

@@ -21,13 +21,13 @@ import { generateText } from 'ai';
 const ctx = await context({
   ablo,
   data: {
-    task: ablo.tasks.get({ id: taskId }),
-    documents: ablo.documents.list({ where: { taskId } }),
-    memory: loadMemories(taskId),
+    record: ablo.records.get({ id: recordId }),
+    records: ablo.records.list({ where: { recordId } }),
+    memory: loadMemories(recordId),
   },
 });
 
-if (!ctx.data.task) throw new Error('Task not found');
+if (!ctx.data.record) throw new Error('Record not found');
 
 const result = await generateText({
   model,
@@ -35,8 +35,8 @@ const result = await generateText({
   tools,
 });
 
-await ablo.tasks.update({
-  id: ctx.data.task.id,
+await ablo.records.update({
+  id: ctx.data.record.id,
   data: parseTaskUpdate(result.text),
   reads: ctx.reads,
 });
@@ -80,7 +80,7 @@ This distinction is visible in `sources`:
 ```ts
 ctx.sources;
 // [
-//   { key: 'task', kind: 'ablo', guarantee: 'guardable', cursor: 42 },
+//   { key: 'record', kind: 'ablo', guarantee: 'guardable', cursor: 42 },
 //   { key: 'memory', kind: 'value', guarantee: 'informational', cursor: null },
 // ]
 ```
@@ -89,7 +89,7 @@ A top-level value may contain both kinds. It is then marked `mixed` and only
 its exact Ablo rows appear in `ctx.reads`:
 
 ```ts
-// data: { briefing: { task, memory } }
+// data: { briefing: { record, memory } }
 // sources: [
 //   { key: 'briefing', kind: 'mixed', guarantee: 'partial', cursor: 42 },
 // ]
@@ -108,10 +108,10 @@ Reducto, or another system behind their own interfaces.
 const ctx = await context({
   ablo,
   data: {
-    task: ablo.tasks.get({ id: taskId }),
+    record: ablo.records.get({ id: recordId }),
     memory: loadMemories({ query, userId }),
     related: findRelatedChunks({ projectId, query }),
-    evidence: extractEvidence({ documentId }),
+    evidence: extractEvidence({ recordId }),
   },
 });
 ```
@@ -141,7 +141,7 @@ await generateText({
   model,
   messages: [
     ...history,
-    contextMessage(ctx, { include: ['task', 'documents', 'memory'] }),
+    contextMessage(ctx, { include: ['record', 'documents', 'memory'] }),
   ],
   tools,
 });

package/docs/coordination.md

@@ -9,7 +9,7 @@ meaning. Choose the narrowest one that matches the operation.
 |---|---|---|
 | Set an independent value | `update({ id, data })` | Last-write-wins when no claim applies. |
 | Compute a value from the current row | `update(id, current => next)` | Re-reads and retries if the row changes concurrently. |
-| Write only if earlier rows are still current | `reads: [task, policy]` | Rejects when an explicitly named dependency changed. |
+| Write only if earlier rows are still current | `reads: [record, policy]` | Rejects when an explicitly named dependency changed. |
 | Read, call a model, then write | `claim({ id })` | Other participants cannot write the claimed target by default until your claim ends. |
 
 **If a model call sits between the read and the write, take a claim.** A stale
@@ -25,16 +25,16 @@ does not carry a stale premise. It is intentionally last-write-wins.
 Pass the exact rows that produced a decision on the write:
 
 ```ts
-const task = await ablo.tasks.get({ id: taskId });
+const record = await ablo.records.get({ id: recordId });
 const policy = await ablo.policies.get({ id: policyId });
-if (!task || !policy) throw new Error('required input is missing');
+if (!record || !policy) throw new Error('required input is missing');
 
-const result = await model({ task, policy });
+const result = await model({ record, policy });
 
-await ablo.tasks.update({
-  id: task.id,
+await ablo.records.update({
+  id: record.id,
   data: result,
-  reads: [task, policy],
+  reads: [record, policy],
 });
 ```
 
@@ -57,7 +57,7 @@ When the next value is a function of the current one, pass an updater rather
 than fixed data:
 
 ```ts
-const document = await ablo.documents.update(documentId, (current) => ({
+const document = await ablo.records.update(recordId, (current) => ({
   revision: current.revision + 1,
   content: revise(current.content),
 }));
@@ -75,8 +75,8 @@ effect inside it.
 You can bound or cancel reconciliation:
 
 ```ts
-await ablo.documents.update(
-  documentId,
+await ablo.records.update(
+  recordId,
   (current) => ({ revision: current.revision + 1 }),
   { retries: 8, signal: request.signal },
 );
@@ -184,8 +184,8 @@ protect the row version rather than a participant-held claim.
 For deduplicated jobs, skip work when another participant already owns it:
 
 ```ts
-const claim = await ablo.tasks.claim({
-  id: taskId,
+const claim = await ablo.records.claim({
+  id: recordId,
   contention: { mode: 'skip' },
 });
 
@@ -201,8 +201,8 @@ try {
 To wait with limits, keep the policy together:
 
 ```ts
-const claim = await ablo.tasks.claim({
-  id: taskId,
+const claim = await ablo.records.claim({
+  id: recordId,
   contention: {
     mode: 'wait',
     maxDepth: 3,
@@ -217,9 +217,9 @@ const claim = await ablo.tasks.claim({
 Narrow a claim when independent fields may be edited concurrently:
 
 ```ts
-await using claim = await ablo.tasks.claim({
-  id: taskId,
-  fields: (task) => task.status,
+await using claim = await ablo.records.claim({
+  id: recordId,
+  fields: (record) => record.status,
 });
 ```
 
@@ -239,8 +239,8 @@ The target options are:
 Read current claim state without blocking:
 
 ```ts
-const holder = ablo.tasks.claim.state({ id: taskId });
-const queue = ablo.tasks.claim.queue({ id: taskId });
+const holder = ablo.records.claim.state({ id: recordId });
+const queue = ablo.records.claim.queue({ id: recordId });
 ```
 
 Use this state for presence and progress UI. Do not use an observed `null` as a

package/docs/customer-organizations.md

@@ -0,0 +1,215 @@
+# Customer Organizations
+
+> Serve many customer organizations from one backend and one shared schema without weakening tenant isolation.
+
+An application serving many customers has two independent choices: where
+customer data is isolated and where the schema is authored. Ablo lets every
+customer keep a hard organization boundary while all of them use the schema
+pushed once by the owning project.
+
+## Choose the customer boundary first
+
+| Customer model | Isolation guarantee | Choose it when |
+|---|---|---|
+| One Ablo organization with customer scope roots | Whatever read boundary every model declares in `policy` | Cross-customer reads are intentional, or every model is explicitly and continuously policy-partitioned |
+| One Ablo organization per customer | Structural organization filtering and RLS on every row | Customers must stay isolated even when a model has no customer-specific policy |
+
+Sync-groups decide which changes are delivered. They do not, by themselves,
+authorize HTTP reads. If you cannot audit matching policies across every model,
+use one Ablo organization per customer.
+
+The rest of this guide uses organization-per-customer: one trusted backend
+holds one dedicated mint key, every customer has an `organizationId`, and each
+user session names that customer organization.
+
+## What you need
+
+- An owning project containing the schema every customer uses.
+- The schema pushed to that project's production root.
+- A server-side `sk_` carrying only `ephemeral:mint-any-org`.
+- A customer `organizationId` resolved from your authenticated application
+  membership, never accepted unchecked from the browser.
+- A model-by-model `can` grant for the UI being opened.
+
+The cross-organization key is a minting credential, not a tenant-data
+credential. Keep it in a secret manager and expose only your own authenticated
+session endpoint.
+
+## Mint on your backend
+
+Create the Ablo client once in server-only code:
+
+```ts
+import Ablo from '@abloatai/ablo';
+import { schema } from '@/ablo/schema';
+
+export const customerSessions = Ablo({
+  schema,
+  apiKey: process.env.ABLO_API_KEY,
+});
+```
+
+After your application authenticates the user, resolve the customer from that
+trusted membership and mint the session:
+
+```ts
+import { credentialEndpointSuccessSchema } from '@abloatai/ablo/auth';
+import { customerSessions } from '@/ablo/customer-sessions';
+
+export async function POST() {
+  const member = await requireSignedInCustomerMember();
+
+  const session = await customerSessions.sessions.create({
+    user: { id: member.userId },
+    organizationId: member.abloOrganizationId,
+    can: {
+      projects: ['read'],
+      records: ['read', 'create', 'update'],
+    },
+  });
+
+  return Response.json(
+    credentialEndpointSuccessSchema.parse({
+      token: session.token,
+      expiresAt: session.expiresAt,
+      credentialKind: 'ephemeral',
+    }),
+    { headers: { 'Cache-Control': 'no-store' } },
+  );
+}
+```
+
+Do not take `organizationId` directly from request JSON. A signed-in user could
+replace it with another customer's id. Derive it from the server-side membership
+you just authenticated.
+
+## Connect the browser
+
+The browser knows only your session endpoint. It never receives the
+cross-organization key:
+
+```tsx
+'use client';
+
+import Ablo from '@abloatai/ablo';
+import { AbloProvider } from '@abloatai/ablo/react';
+import { schema } from '@/ablo/schema';
+
+const ablo = Ablo({
+  schema,
+  authEndpoint: '/api/ablo-session',
+});
+
+export function Providers({ children }: { children: React.ReactNode }) {
+  return <AbloProvider client={ablo}>{children}</AbloProvider>;
+}
+```
+
+The client re-mints before expiry. Your endpoint should return
+`session_expired` only when the application's own login is gone; network and
+server failures are transient and must not sign the user out.
+
+## Schema and data stay on different axes
+
+For a cross-organization mint, Ablo derives the schema binding from the owning
+key automatically:
+
+```text
+owning key organization/project    -> schema shape
+customer organization              -> rows, RLS, database, sync groups
+session can                         -> allowed model operations
+model policy                        -> allowed reads inside that organization
+```
+
+Most applications should not pass a schema option. An explicit override exists for
+migrations or advanced routing:
+
+```ts
+await customerSessions.sessions.create({
+  user: { id: member.userId },
+  organizationId: member.abloOrganizationId,
+  schemaProject: {
+    organizationId: schemaOwnerOrganizationId,
+    projectId: migratingSchemaProjectId,
+  },
+  can: { records: ['read', 'update'] },
+});
+```
+
+Both schema coordinates move together; customer data does not move with them.
+
+## Customer lifecycle checklist
+
+When onboarding a customer:
+
+1. Provision or resolve its Ablo organization and store that immutable id on
+   your customer record.
+2. Connect that organization's production data source if it owns a separate
+   database.
+3. Keep the shared schema in the owning project; do not copy it into every
+   customer organization.
+4. Mint a test user session through the same backend route production uses.
+5. Verify one known read and write in the customer organization before enabling
+   the integration.
+
+When offboarding, stop minting immediately, revoke active sessions when an
+immediate cutoff is required, and retire the customer's data-source access
+through the control-plane process you use for provisioning.
+
+## Security checklist
+
+- Store the cross-organization key only in the backend secret manager.
+- Give it only `ephemeral:mint-any-org`; do not combine minting with schema or
+  data authority.
+- Resolve `organizationId` from authenticated membership server-side.
+- Keep `can` to the smallest model/verb set the UI needs.
+- Use organization-per-customer when a missing model policy must not expose
+  another customer's rows.
+- Rotate the cross-organization key on a schedule and after personnel or
+  infrastructure changes.
+- Record target organization, user, session id, and request id without logging
+  plaintext credentials.
+
+## Troubleshooting
+
+### The mint is forbidden
+
+The presenting credential must be a secret `sk_` with
+`ephemeral:mint-any-org`. A normal project key can mint users into its own
+organization but cannot name another one. Run `npx ablo whoami --json` in the
+backend environment to confirm which project and branch the configured key
+actually belongs to; the command never prints the full secret.
+
+### The session mints but bootstrap is empty
+
+Confirm that the cross-organization key belongs to the project where the schema
+was pushed, and that the customer's organization has its data source/root
+branch ready. Do not copy the schema into the customer organization. If you
+supplied `schemaProject`, remove it unless you intentionally override the
+owning-key default.
+
+### The mint reports an unknown model
+
+Every model named by `can` must exist in the active shared schema. Check the
+model key spelling against the schema used to construct `customerSessions`, then
+push that schema to the key's branch deliberately.
+
+### Data appears under the wrong customer
+
+Inspect the membership-to-`organizationId` lookup in your backend route first.
+The schema project never selects the data tenant. The `organizationId` passed to
+`sessions.create` does, and it must come from trusted server-side membership.
+
+### Realtime looks isolated but an HTTP read is too broad
+
+Sync-groups route changes; they are not a read policy. Add or correct the
+model's `policy`, or move customers to separate Ablo organizations when the
+boundary must hold structurally across every model.
+
+## Related guides
+
+- [Sessions](./sessions.md) — session lifecycle, refresh, revocation, and grants.
+- [API Keys](./api-keys.md) — credential classes, scopes, inspection, and rotation.
+- [Identity & Sync Groups](./identity.md) — participant delivery groups versus model read policy.
+- [Connect Your Database](./data-sources.md) — customer-owned database setup.
+- [Deployment](./deployment.md) — production schema and database rollout order.

package/docs/data-sources.md

@@ -149,8 +149,8 @@ own schema:
 ABLO_API_KEY="$MAIL_KEY" DATABASE_URL="$PRODUCTION_URL" \
   npx ablo connect apply --schema mail --yes
 
-ABLO_API_KEY="$SLIDES_KEY" DATABASE_URL="$PRODUCTION_URL" \
-  npx ablo connect apply --schema slides --yes
+ABLO_API_KEY="$ENTRIES_KEY" DATABASE_URL="$PRODUCTION_URL" \
+  npx ablo connect apply --schema entries --yes
 ```
 
 For a Neon or Supabase preview branch, use that branch's direct URL and keep the
@@ -380,7 +380,7 @@ export const ablo = Ablo({
 The API key still selects the project and branch; during `ready()` Ablo asks the
 server what the key actually targets and refuses startup when either coordinate
 differs. `ablo dev` writes all three values together, so accidentally exporting
-a slides key into the mail app—or a mail development key into production—fails
+a entries key into the mail app—or a mail development key into production—fails
 before any read, write, or subscription begins.
 
 The Ablo schema describes **only your synced, collaborative models** — the rows

package/docs/debugging.md

@@ -72,12 +72,12 @@ Precedence: an explicit `logLevel` wins, then `debug: true` (⇒ `debug`), then
 These lines (all at `info`) let you watch the handover you built:
 
 ```
-[Ablo] claim: requesting documents:doc_42 for "editing" (will queue if contended)
-[Ablo] claim: queued for documents:doc_42 — position 2 of 3, waiting
+[Ablo] claim: requesting records:doc_42 for "editing" (will queue if contended)
+[Ablo] claim: queued for records:doc_42 — position 2 of 3, waiting
 [Ablo] claim: granted 7f3c… — your turn (waited in queue)
-[Ablo] claim: rejected documents:doc_42 — held by agent_writer
-[Ablo] claim: lost documents:doc_42 (preempted or expired)
-[Ablo] claim: released documents:doc_42
+[Ablo] claim: rejected records:doc_42 — held by agent_writer
+[Ablo] claim: lost records:doc_42 (preempted or expired)
+[Ablo] claim: released records:doc_42
 ```
 
 Read it as the lifecycle of one claim:
@@ -189,7 +189,7 @@ function ActivityFeed({ log }: { log: ClaimLog }) {
 For **"who holds *this* row right now"** (a badge, not a feed), don't use `ClaimLog` — read the reactive claim state directly. It re-renders on change with no extra wiring:
 
 ```tsx
-const holder = useAblo((ablo) => ablo.documents.claim.state({ id }));   // Claim | null
+const holder = useAblo((ablo) => ablo.records.claim.state({ id }));   // Claim | null
 ```
 
 See [React](./react.md) and [Coordination](./coordination.md) for the claim-read APIs.
@@ -265,7 +265,7 @@ Every rejected live commit carries `requestId` on the thrown error and
 import { AbloError } from '@abloatai/ablo';
 
 try {
-  await ablo.documents.create({
+  await ablo.records.create({
     data,
   });
 } catch (error) {
@@ -289,7 +289,7 @@ evidence that the replication source has no history.
 Use:
 
 ```ts
-await ablo.documents.list({ type: 'complete' });
+await ablo.records.list({ type: 'complete' });
 ```
 
 `type: 'complete'` waits for a server round trip and returns the confirmed

package/docs/examples/agent-human.md

@@ -2,16 +2,16 @@
 
 > An agent that yields the row when a person is already holding it.
 
-A task-writing agent that yields when a person is editing the same task.
+A record-writing agent that yields when a person is editing the same record.
 
 ## Scenario
 
-The same tasks are edited by agents and by the people watching them. They must
+The same records are edited by agents and by the people watching them. They must
 not collide:
 
 - If a person already holds the row, the agent yields instead of fighting for it.
 - While the agent is updating, the UI can show who is active.
-- If the task changes mid-run, the commit is rejected instead of overwriting the
+- If the record changes mid-run, the commit is rejected instead of overwriting the
   newer edit.
 
 A **claim** does both jobs. Claims don't lock — if another writer holds the row,
@@ -24,9 +24,9 @@ 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 task from the
+The worker uses the same schema client the app uses. It reads the record from the
 server with `get({ id })`, claims the row, and writes through
-`ablo.tasks.update(...)` with a stale-check so a concurrent edit can't be
+`ablo.records.update(...)` with a stale-check so a concurrent edit can't be
 overwritten.
 
 ```ts
@@ -34,7 +34,7 @@ import Ablo, { AbloClaimedError, AbloStaleContextError } from '@abloatai/ablo';
 import { defineSchema, model, z } from '@abloatai/ablo/schema';
 
 const schema = defineSchema({
-  tasks: model({
+  records: model({
     title: z.string(),
     status: z.enum(['todo', 'doing', 'done']),
   }),
@@ -46,19 +46,19 @@ const ablo = Ablo({
   transport: 'http',
 });
 
-export async function markDone(taskId: string) {
+export async function markDone(recordId: string) {
   await ablo.ready();
 
   // get({ id }) is an async server read — await it.
-  const task = await ablo.tasks.get({ id: taskId });
-  if (!task) return { status: 'not_found' };
+  const record = await ablo.records.get({ id: recordId });
+  if (!record) return { status: 'not_found' };
 
   try {
     // queue: false → don't queue behind a current holder. If another
     // participant holds the row, claim resolves null, so the agent yields
     // instead of waiting. Omit it, or pass queue: true, to queue behind them.
-    const acquired = await ablo.tasks.claim({
-      id: taskId,
+    const acquired = await ablo.records.claim({
+      id: recordId,
       queue: false,
       description: 'marking_done',
     });
@@ -72,7 +72,7 @@ export async function markDone(taskId: string) {
     // `onStale: 'reject'`. The write below is therefore equivalent to passing
     // those options yourself:
     //
-    //   ablo.tasks.update({
+    //   ablo.records.update({
     //     id: claim.data.id,
     //     data: { status: 'done' },
     //     readAt: <claim snapshot version>,
@@ -82,12 +82,12 @@ export async function markDone(taskId: string) {
     // If a newer version landed mid-run, the row no longer matches `readAt`, so
     // the server rejects this commit with AbloStaleContextError (caught below)
     // instead of clobbering that edit.
-    const updated = await ablo.tasks.update({
+    const updated = await ablo.records.update({
       id: claim.data.id,
       data: { status: 'done' },
     });
 
-    return { status: 'done', task: updated };
+    return { status: 'done', record: updated };
   } catch (err) {
     // The lease was lost or a foreign holder rejected the write.
     if (err instanceof AbloClaimedError) return { status: 'yielded' };
@@ -108,9 +108,9 @@ Keep workers on the same schema-backed client as the app.
 
 import { useAblo } from '@abloatai/ablo/react';
 
-export function TaskRow({ task: serverTask }: Props) {
-  const data = useAblo((ablo) => ablo.tasks.local.get(serverTask.id)) ?? serverTask;
-  const holder = useAblo((ablo) => ablo.tasks.claim.state({ id: serverTask.id }));
+export function RecordRow({ record: serverTask }: Props) {
+  const data = useAblo((ablo) => ablo.records.local.get(serverTask.id)) ?? serverTask;
+  const holder = useAblo((ablo) => ablo.records.claim.state({ id: serverTask.id }));
   const agentActive = holder?.participantKind === 'agent';
 
   return (

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

@@ -27,7 +27,7 @@ import { z } from 'zod';
 export const runtime = 'nodejs';
 
 const schema = defineSchema({
-  tasks: model({
+  records: model({
     title: schemaZ.string(),
     status: schemaZ.enum(['todo', 'doing', 'done']),
     summary: schemaZ.string().optional(),
@@ -40,15 +40,15 @@ const ablo = Ablo({
   transport: 'http',
 });
 
-const updateTask = updateTool(ablo.tasks, {
-  title: 'Update task',
-  description: 'Update a task without overwriting concurrent work.',
+const updateTask = updateTool(ablo.records, {
+  title: 'Update record',
+  description: 'Update a record without overwriting concurrent work.',
   inputSchema: z.object({
-    taskId: z.string(),
+    recordId: z.string(),
     status: z.enum(['todo', 'doing', 'done']).optional(),
     summary: z.string().optional(),
   }),
-  id: ({ taskId }) => taskId,
+  id: ({ recordId }) => recordId,
   apply: (current, { status, summary }) => ({
     status: status ?? current.status,
     summary: summary ?? current.summary,

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

@@ -95,7 +95,7 @@ export async function POST() {
   const userId = await currentUserId(); // your auth
   const { token, expiresAt } = await ablo.sessions.create({
     user: { id: userId },
-    can: { tasks: ['read', 'update'] },
+    can: { records: ['read', 'update'] },
   });
   return Response.json(
     credentialEndpointSuccessSchema.parse({

package/docs/examples/nextjs.md

@@ -21,11 +21,11 @@ app/
   api/
     ablo-session/
       route.ts              # mints a per-user ek_ token for the browser
-  tasks/
+  records/
     [id]/
       page.tsx              # RSC: get + render
       actions.ts            # Server Action: claim, then write
-      TaskEditor.tsx        # Client: live updates
+      RecordEditor.tsx        # Client: live updates
 lib/
   ablo.ts                   # Server Ablo client (holds ABLO_API_KEY)
   ablo.schema.ts            # shared schema
@@ -82,7 +82,7 @@ export async function POST() {
 
   const { token, expiresAt } = await ablo.sessions.create({
     user: { id: user.id },
-    can: { tasks: ['read', 'create', 'update'] },
+    can: { records: ['read', 'create', 'update'] },
   });
   return Response.json(
     credentialEndpointSuccessSchema.parse({
@@ -137,40 +137,40 @@ export default function RootLayout({ children }: { children: React.ReactNode })
 ## RSC Initial Render
 
 ```tsx
-// app/tasks/[id]/page.tsx
+// app/records/[id]/page.tsx
 import { ablo } from '@/lib/ablo';
 
-export default async function TaskPage({
+export default async function RecordPage({
   params,
 }: { params: Promise<{ id: string }> }) {
   const { id } = await params;
   await ablo.ready();
-  const task = await ablo.tasks.get({ id });
-  if (!task) return null;
+  const record = await ablo.records.get({ id });
+  if (!record) return null;
 
-  return <TaskEditor task={task} />;
+  return <RecordEditor record={record} />;
 }
 ```
 
 ## Server Action Commit
 
 ```ts
-// app/tasks/[id]/actions.ts
+// app/records/[id]/actions.ts
 'use server';
 
 import { ablo } from '@/lib/ablo';
 
 export async function markDone(id: string) {
   // Claim grants exclusive, ordered access and hands back the fresh row.
-  await using claim = await ablo.tasks.claim({ id });
+  await using claim = await ablo.records.claim({ id });
 
-  const task = await ablo.tasks.update({
+  const record = await ablo.records.update({
     id,
     data: { status: 'done' },
     claim,
   });
 
-  return { status: 'done', task };
+  return { status: 'done', record };
   // claim auto-releases as the action returns
 }
 ```
@@ -186,9 +186,9 @@ you — re-fetch and retry.
 
 import { useAblo } from '@abloatai/ablo/react';
 
-export function TaskEditor({ task: serverTask }: Props) {
-  const data = useAblo((ablo) => ablo.tasks.local.get(serverTask.id)) ?? serverTask;
-  const holder = useAblo((ablo) => ablo.tasks.claim.state({ id: serverTask.id }));
+export function RecordEditor({ record: serverTask }: Props) {
+  const data = useAblo((ablo) => ablo.records.local.get(serverTask.id)) ?? serverTask;
+  const holder = useAblo((ablo) => ablo.records.claim.state({ id: serverTask.id }));
   const busy = Boolean(holder);
 
   return (