@abloatai/ablo 0.5.1 → 0.7.0

package/docs/interaction-model.md

@@ -1,17 +1,10 @@
 # Interaction Model
 
-Ablo separates the data path from the authority path.
-
-The data path is what your application does on every write:
-
-```
-Schema -> Model load -> Intent -> Model update -> Confirmation
-```
-
-The authority path is what makes that write defensible:
+Ablo's public model is the path every human UI, server action, and agent uses on
+every write:
 
 ```
-Capability -> Task -> Usage
+Schema -> Model load -> Claim -> Model update -> Confirmation
 ```
 
 ## Primitives
@@ -19,16 +12,10 @@ Capability -> Task -> Usage
 | Primitive | Plane | Purpose |
 |---|---|---|
 | `Schema` | State | Declares typed models the app and agents can read and write. |
-| `Model` | State | The generated `ablo.<model>` resource. Use `load`, `retrieve`, `create`, `update`, and `delete`. |
-| `Intent` | Coordination | Who is working on a target, as one Stripe-shaped object with a single `status`. Opened and read through `ablo.<model>.intent(id)`. Ephemeral — never persisted. |
+| `Model` | State | The generated `ablo.<model>` model. Use `load`, `retrieve`, `create`, `update`, and `delete`. |
+| `Claim` | Coordination | Who is working on a target. Claimed via `ablo.<model>.claim(id, ...)` and read via `ablo.<model>.claimState(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'`. |
-| `Capability` | Control | Signed credentials. It says who can do what, where, for how long, and on whose behalf. |
-| `Task` | Control | One agent run. It groups prompts, commits, child tasks, and cost. |
-| `Usage` | Control | Metering and audit rows derived from accepted work. |
-
-Capabilities, tasks, and usage do not mutate product data. They define and
-record the authority around mutation.
 
 ### Why each primitive is separate
 
@@ -37,94 +24,54 @@ lose a property that's hard to recover later. A reader coming from
 Replicache or Yjs would expect just `Commit`; here's what the others buy
 you over that minimum:
 
-- **`Intent` is not a lock.** A pessimistic lock blocks a writer; an
-  intent *announces* one. Other writers can yield, wait, or proceed —
-  the choice is theirs, not the system's. This is the only primitive
-  that lets two agents discover each other's planned work *before* the
-  conflict and self-arbitrate. Without intents, agents only learn about
-  contention at commit time, when one of them has already wasted a
-  token budget.
+- **`Claim` is not a read lock.** Reads stay open. Claims serialize
+  acting-on-the-row, so slow work can wait in FIFO order, re-read, and write
+  from fresh state.
 - **`Receipt` is not a `200 OK`.** It's the durable artifact a commit
   produced — accepted commit id, server-assigned timestamps, stale-check
   outcome — addressable after the fact and replayable into a different
   client. A status code can't be re-read by a sub-agent that wasn't on
   the original call.
-- **`Capability` is not the actor.** The actor (`Task`) is what *ran*;
-  the capability is what it was *allowed* to do. Same human can spawn
-  many tasks under one cap (cheap re-run); same task can attenuate to
-  many sub-caps (sub-agent delegation). Folding them collapses both
-  directions of that fan.
-- **`Task` is not the credential.** It's the audit envelope: prompt,
-  commits, child tasks, tokens, duration. Long after the cap has
-  expired, the task row is what answers "what did this run do." Folding
-  task into capability loses the post-expiry audit.
-- **`Usage` is not derived from logs.** It's denormalized at commit
-  accept time so quota enforcement and billing reads stay O(1). Log
-  scans would work for audit but not for hot-path gating.
 
 The shape is borrowed from systems that learned the cost of collapse:
-intents from operational-transform CRDTs and Linear's
-optimistic-multiplayer model, capabilities + tasks from AWS IAM
-(`Role` ≠ `RoleSession`) and Vault (`policy` ≠ `lease`).
+coordination from operational-transform CRDTs and Linear's optimistic
+multiplayer model, and receipts from durable write protocols.
 
 ## Run Loop
 
 A normal schema-backed run is:
 
 ```
-const [task] = await ablo.tasks.load({ where: { id } });
-const busy = ablo.intents.list({ resource: 'tasks', id });
-const snap = ablo.snapshot({ tasks: id });
-await ablo.tasks.update(id, patch, {
-  readAt: snap.stamp,
-  onStale: 'reject',
-  wait: 'confirmed',
+const [report] = await ablo.weatherReports.load({ where: { id } });
+const active = ablo.weatherReports.claimState(id);
+await ablo.weatherReports.claim(id, async (report) => {
+  await ablo.weatherReports.update(report.id, patch, { wait: 'confirmed' });
 });
 ```
 
-## Participants
-
-Every action is performed by one of three kinds:
-
-- `user` — a human, authenticated via session.
-- `agent` — an AI process acting on behalf of a human, authenticated via a capability minted from that human's session.
-- `system` — a customer-backend process acting on behalf of an organization, authenticated via an API key.
-
-The participant kind is enforced at the boundary. An agent capability cannot impersonate a user. A user session cannot open a task.
-
-## Delegation chain
-
-Every capability resolves to a `delegationChainRootUserId` — the human at the head of the chain. The chain is denormalized onto every commit's `on_behalf_of_*` columns so audit queries answer "what did this human authorize" with one lookup, not a recursive join.
-
-## Enforcement
-
-Capabilities are enforced per operation, not per request. When a commit arrives, Ablo decodes the bearer token, checks each operation against `operations` and `syncGroups`, and rejects with `capability_scope_denied` if the scope is missing. Revocation takes effect within seconds of `DELETE /v1/capabilities/:id`.
-
-Three independent checks gate every commit. The redundancy is intentional — each check covers a failure mode the others don't:
-
-- **Lease (TTL on the token).** Decoded from the bearer; no DB lookup. Caps the lifetime of a leaked token. Without this, a stolen token works until manually revoked.
-- **Signature + scope verification.** Stateless. Detects forged or tampered tokens and rejects operations outside the cap's `operations` / `syncGroups`. Without this, a malformed token with the right shape could pass.
-- **Revocation.** `DELETE /v1/capabilities/:id` flips status server-side; live WS sessions close, future commits reject. Closes the gap between lease refresh cycles when you need *immediate* cutoff. Without this, a compromised cap with a long lease leaks until expiry.
-
-Removing any one of the three leaves a class of attack uncovered. The pattern matches AWS STS, Vault leases, and the OAuth 2.1 / MCP agent-auth recommendation; see [Capabilities](./capabilities.md#the-three-layer-security-model) for the full design discussion.
-
 ## Coordination
 
-Intents broadcast across the org. Open and read one on any row through the
-model accessor:
+> Loop view only. Full claim reference — methods, the claim-state object, the
+> `queue`, errors — is [Coordination](./coordination.md).
+
+Claims broadcast across the org. Claim a row through the flat model verb, write
+through the normal `update`, and the claim releases when the callback returns:
 
 ```ts
-const task = ablo.tasks.intent('task_123');
-if (task.current) await task.whenFree();     // someone's working — wait
-await task.claim({ action: 'editing' });     // claim so others yield
-await task.update({ status: 'done' });        // commits + releases
+await ablo.weatherReports.claim(
+  'report_stockholm',
+  async (report) => {
+    await ablo.weatherReports.update(report.id, { status: 'ready' }); // stale-guarded under the claim
+  },
+  { action: 'editing' },
+);
 ```
 
-`task.current` is the live `Intent` (or `null`); `task.whenFree()` resolves when
-the holder finishes. The same signal is visible to every schema client through
-`ablo.intents.list(...)` and the live intent stream, so callers decide whether
-to yield, wait, or fail fast. See [API → Intent](./api.md#intent) for the object
-reference and lifecycle.
+`ablo.weatherReports.claimState('report_stockholm')` reads the live claim (or `null`) without
+blocking. The claim is **advisory**: if another participant holds the row,
+`claim` waits for them to finish and re-reads before handing back the row. The
+same signal is visible to every schema client through `claimState(id)` and the live
+claim stream.
 
 ## Conflict resolution
 
@@ -137,16 +84,6 @@ Schema updates can carry `readAt` and `onStale`. If the state advanced past
 
 The choice is per-commit. No CRDT default; the policy is explicit.
 
-## Audit
-
-Three tables observe the run:
-
-- `agent_tasks` — one row per open/close cycle. Cost stats, prompt hash, capability id.
-- `agent_actions_log` — one row per write, attributed to the task and the capability.
-- `usage_event` — one row per accounted API call, attributed to the api key, the participant, and the task.
-
-Joins between them answer "what did this agent do, on whose authority, at what cost." That answer is what makes giving an agent write access defensible.
-
 ## The contract in one sentence
 
-Declare schema, load state, coordinate intent, update the model, and wait for confirmation.
+Declare schema, load state, coordinate a claim, update the model, and wait for confirmation.

package/docs/mcp/claude-code.md

@@ -10,14 +10,14 @@ That's it. The next `/help` in Claude Code will list the Ablo Sync tools.
 
 ## With auth
 
-If your deployment requires a capability token (production setups should):
+If your deployment requires a scoped bearer token (production setups should):
 
 ```bash
 claude mcp add --transport http ablo-sync https://<your-app>/api/mcp \
   --header "Authorization=Bearer $ABLO_MCP_TOKEN"
 ```
 
-Create a session-scoped capability from the dashboard or via the API — see
+Create a session-scoped bearer token from your server or dashboard — see
 [MCP overview](/docs/mcp#auth).
 
 ## Verify
@@ -28,7 +28,7 @@ In Claude Code, run:
 /mcp list
 ```
 
-You should see `ablo-sync` with the resource tools enumerated.
+You should see `ablo-sync` with the model tools enumerated.
 
 ## Removing
 

package/docs/mcp/cursor.md

@@ -44,7 +44,7 @@ in your shell config.
 ## Verify
 
 In Cursor's agent panel, open the MCP tools list. You should see the
-Ablo Sync resource tools and their JSON schemas.
+Ablo Sync model tools and their JSON schemas.
 
 ## More
 

package/docs/mcp/windsurf.md

@@ -37,7 +37,7 @@ Cascade → MCP. Restart Windsurf after saving.
 ## Verify
 
 Cascade's MCP panel lists every configured server with its tools. You
-should see `ablo-sync` with resource tools enumerated.
+should see `ablo-sync` with model tools enumerated.
 
 ## More
 

package/docs/mcp.md

@@ -1,7 +1,7 @@
 # Model Context Protocol
 
-Ablo Sync ships an MCP server at `/api/mcp`. Connect any MCP-compatible AI
-assistant — Claude Code, Cursor, Windsurf — and your sync resources become
+Ablo ships an MCP server at `/api/mcp`. Connect any MCP-compatible AI
+assistant — Claude Code, Cursor, Windsurf — and your sync models become
 typed, callable tools.
 
 ## Install
@@ -14,38 +14,23 @@ Pick your client:
 
 ## How it works
 
-Each resource you declare becomes one or more MCP tools:
+Each model you declare becomes one or more MCP tools:
 
-| Resource method | MCP tool name | What it does |
+| Model method | MCP tool name | What it does |
 |---|---|---|
-| `retrieve` | `<resource>.retrieve` | Returns the row + a stamp. |
-| `list` | `<resource>.list` | Cursor-paginated discovery. |
-| `update` | `<resource>.update` | Write, requires the prior stamp. |
-| `<model>.intent` | `intent.create` | Claim a row before writing, then auto-release on update. |
+| `retrieve` | `<model>.retrieve` | Returns the row + a stamp. |
+| `list` | `<model>.list` | Cursor-paginated discovery. |
+| `update` | `<model>.update` | Write, requires the prior stamp. |
+| `<model>.claim` | `claim.create` | Claim a row before writing, then release when held work finishes. |
 
 The assistant gets typed JSON schemas, real argument types, and typed
 rejections when it writes stale state. No invention, no hallucinated IDs.
 
 ## Auth
 
-The MCP transport requires a capability token. Create one scoped to the
-assistant's session:
-
-```ts
-const capability = await ablo.capabilities.create({
-  participantKind: 'agent',
-  participantId: 'agent:claude-code',
-  // Strings derive from the schema's `identityRoles` templates
-  // (see integration-guide.md §1).
-  syncGroups: ['org:acme'],
-  operations: ['tasks.retrieve', 'tasks.update'],
-  label: 'claude-code dev session',
-  lease: '8h',
-});
-```
-
-Pass `capability.token` into the MCP client's auth header configuration.
-See your client's setup guide for the exact mechanism.
+The MCP transport uses a scoped bearer token issued by your server. Pass that
+token into the MCP client's auth header configuration. See your client's setup
+guide for the exact mechanism.
 
 ## Limits
 

package/docs/quickstart.md

@@ -21,7 +21,7 @@ export ABLO_API_KEY=sk_test_...
 ```
 
 `ABLO_API_KEY` is for trusted server runtimes. Browser apps should use the React
-provider with a scoped capability/session route, not a bundled API key.
+provider with a scoped session route, not a bundled API key.
 
 ## 3. Declare a Schema
 
@@ -44,7 +44,7 @@ export const ablo = Ablo({
 ```
 
 Customer apps should always pass `schema`. Treat it like Prisma's schema file:
-it is the source of truth for typed model resources, realtime subscriptions,
+it is the source of truth for typed model clients, realtime subscriptions,
 agent writes, and Data Source requests.
 
 ## 4. Create and Update
@@ -81,71 +81,65 @@ ABLO_API_KEY=sk_test_... npx tsx quickstart.ts
 ## 6. AI Activity on Existing State
 
 When AI or background work will touch an existing row for more than a quick
-write, coordinate through `ablo.<model>.intent(id)`. It returns a handle
-synchronously — read `.current` to see who's working on the row, `claim()` to
-claim it, `update()` to write under the claim (which auto-releases).
+write, coordinate through the flat model verbs: `ablo.<model>.claim(id, ...)` to
+claim the row (returns the row), `ablo.<model>.claimState(id)` to read who's working
+on it (synchronous; never blocks), and the normal `ablo.<model>.update(id, ...)`
+to write. Normal reads still work while the claim is held; server reads can opt
+into `ifClaimed: 'wait'` or `ifClaimed: 'fail'` when they should not read through
+active work. The callback form releases the claim when the callback returns or
+throws.
 
 ```ts
-const report = ablo.weatherReports.intent('weather_stockholm');
-
-// If another participant holds it, wait for them to finish.
-if (report.current) await report.whenFree();
-
-// Claim it so other participants yield while we work.
-await report.claim({ action: 'checking_weather', field: 'forecast', ttl: '2m' });
-
-// Your existing weather tool or agent call. While this runs, other clients see
-// that weather_stockholm is being checked.
-const row = ablo.weatherReports.retrieve('weather_stockholm');
-const weather = await weatherAgent.getWeather(row.location);
-
-await report.update({
-  status: 'ready',
-  forecast: weather.summary,
-});
+// Claim the row so other participants serialize behind us while we work.
+await ablo.weatherReports.claim(
+  'weather_stockholm',
+  async (report) => {
+    // Your existing weather tool or agent call. While this runs, other clients
+    // see that weather_stockholm is being checked.
+    const weather = await weatherAgent.getWeather(report.location);
+
+    await ablo.weatherReports.update(report.id, {
+      status: 'ready',
+      forecast: weather.summary,
+    });
+  },
+  { action: 'checking_weather', ttl: '2m' },
+);
 ```
 
-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 releases the intent automatically once the write lands.
+Ablo does not fetch the weather. The claim is **advisory**: if another
+participant already holds the row, `claim` waits for them to finish and re-reads
+before handing back the row. While you hold the claim, `update(id, ...)` is
+stale-guarded and rejects with `AbloStaleContextError` if the row changed under
+you. The claim releases automatically once the callback returns or throws.
 
-## 7. Multiplayer and Busy Work
+## 7. Multiplayer and Claimed Work
 
 There is no separate multiplayer mode. Use the same schema client for human UI,
 server actions, and agents; Ablo fans out confirmed writes and keeps active
-intents visible on the same resource.
+claims visible on the same model row.
 
-Intents tell you when another human or agent is active on the same target. For
-schema clients, wait on the intent stream and then write through the model.
+`claimState(id)` tells you when another human or agent is active on the same row.
+For schema clients, `claim(id, work)` waits fairly, re-reads, and then lets you
+write through the model.
 
 ```ts
-const busy = ablo.intents.list({
-  resource: 'weatherReports',
-  id: 'weather_stockholm',
-});
-
-if (busy.length > 0) {
-  await ablo.intents.waitFor(
-    { resource: 'weatherReports', id: 'weather_stockholm' },
-    { timeout: 30_000 },
-  );
+const active = ablo.weatherReports.claimState('weather_stockholm');
+if (active) {
+  console.log(`${active.heldBy} is ${active.action}`);
 }
 
-await ablo.weatherReports.update('weather_stockholm', { status: 'ready' });
+await ablo.weatherReports.claim('weather_stockholm', async (report) => {
+  await ablo.weatherReports.update(report.id, { status: 'ready' });
+});
 ```
 
-`ifBusy` controls what happens when another human or agent is already working
-on the same target:
-
-- `return` returns immediately with active intents.
-- `wait` waits for the intent stream to clear.
-- `fail` throws `AbloBusyError` with the active intents attached.
+Use `{ wait: false }` on `claim` when work should be skipped instead of queued
+behind an active holder.
 
 ## 8. Next Steps
 
-Keep using the schema client for app and agent writes. Reach for the advanced
-schema-less agent wrapper only when a worker intentionally cannot import the
-app schema.
+Keep using the schema client for app and agent writes.
 
 - [Integration Guide](./integration-guide.md) explains the full app, React, Data Source, multiplayer, and agent path.
 - [Guarantees](./guarantees.md) explains what confirmed writes and stale checks mean.

package/docs/react.md

@@ -14,21 +14,71 @@ The React bindings ship with the main package — no extra install.
 import { useAblo } from '@abloatai/ablo/react';
 ```
 
-## useAblo — model resource
+## AbloProvider
+
+Mount it once near the root of your tree. It owns the connection, the local
+pool, and the engine lifecycle; everything below it reads with `useAblo`.
+
+```tsx
+'use client';
+
+import { AbloProvider } from '@abloatai/ablo/react';
+import { schema } from '@/ablo/schema';
+
+export function Providers({
+  children,
+  user, // resolved server-side from YOUR auth
+}: {
+  children: React.ReactNode;
+  user: { id: string; teamIds: string[] };
+}) {
+  return (
+    <AbloProvider
+      schema={schema}
+      userId={user.id}
+      teamIds={user.teamIds}
+      fallback={<AppSkeleton />}
+    >
+      {children}
+    </AbloProvider>
+  );
+}
+```
+
+`schema` is the only required prop. The rest are situational:
+
+| Prop                | Default                | Purpose                                                                                                   |
+| ------------------- | ---------------------- | --------------------------------------------------------------------------------------------------------- |
+| `schema`            | —                      | **Required.** From `defineSchema()`. Determines the typed hook surface.                                   |
+| `userId`            | resolved from auth     | App participant id for app-owned fields and your `identityRoles.extract`. Not the security boundary.      |
+| `teamIds`           | resolved from auth     | Team ids expanded into team sync groups via `identityRoles`.                                               |
+| `syncGroups`        | full allowed set       | **Narrows** the subscription to a subset of what auth allows (e.g. `['deck:abc123']`). Never widens it.   |
+| `url`               | hosted endpoint        | WebSocket URL of the sync server (`wss://…`). Hosted apps omit it.                                         |
+| `apiKey`            | session/cookie         | Bootstrap auth. Browser apps **omit this** — the key stays server-side. See Identity below.               |
+| `fallback`          | neutral spinner        | Rendered during the *first* bootstrap only. Pass a branded skeleton, `null`, or `'passthrough'`.          |
+| `bootstrapMode`     | `'full'`               | `'full'` pulls the org's baseline before ready; `'none'` skips the baseline and processes live deltas only.|
+| `persistence`       | `'volatile'`           | `'indexeddb'` opts into a durable browser cache that survives reloads.                                     |
+| `onSessionExpired`  | —                      | Fired after the engine has already purged on a rejected session — use for redirect-to-sign-in.            |
+| `onError`           | —                      | Engine / WebSocket / `postBootstrap` errors. Wire to Sentry / Datadog.                                    |
+
+Where `userId` / `teamIds` / `syncGroups` come 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 org
+/ team / user map to what a participant can see.
+
+## useAblo — model client
 
 ```tsx
 'use client';
 
 import { useAblo } from '@abloatai/ablo/react';
 
-export function TaskView({ task: serverTask }: { task: { id: string; title: string } }) {
-  const task = useAblo((ablo) => ablo.tasks.retrieve(serverTask.id)) ?? serverTask;
-  const intents = useAblo((ablo) =>
-    ablo.intents.list({ resource: 'tasks', id: serverTask.id }),
-  ) ?? [];
-  const busy = intents.length > 0;
+export function ReportView({ report: serverReport }: { report: { id: string; location: string } }) {
+  const report = useAblo((ablo) => ablo.weatherReports.retrieve(serverReport.id)) ?? serverReport;
+  const active = useAblo((ablo) => ablo.weatherReports.claimState(serverReport.id));
+  const claimed = Boolean(active);
 
-  return <article>{task.title}</article>;
+  return <article>{report.location}</article>;
 }
 ```
 
@@ -37,9 +87,9 @@ The hook:
 1. Reads through the same `ablo.<model>` methods as the rest of the SDK.
 2. Tracks the model fields read by the selector and re-renders when confirmed
    deltas arrive.
-3. Lets Server Component data stay outside the hook: use `?? serverTask` when a
+3. Lets Server Component data stay outside the hook: use `?? serverReport` when a
    parent already loaded the row.
-4. Works for coordination state too, such as `ablo.intents.list(...)`.
+4. Works for coordination state too, such as `ablo.weatherReports.claimState(id)`.
 
 Use the zero-argument form only when you need the full client for callbacks,
 effects, or writes:
@@ -50,16 +100,16 @@ const abloClient = useAblo();
 
 Prefer selector reads like `useAblo((ablo) => ablo.<model>.retrieve(id))`.
 String model names are kept on older hooks for compatibility, but first examples
-should use the same model-resource shape as the rest of the SDK.
+should use the same model-client shape as the rest of the SDK.
 
-For collections, keep the selector on the model resource too:
+For collections, keep the selector on the model client too:
 
 ```tsx
-const tasks = useAblo((ablo) =>
-  ablo.tasks.list({
+const reports = useAblo((ablo) =>
+  ablo.weatherReports.list({
     where: { projectId },
-    filter: (task) => task.status !== 'done',
-    scope: 'live',
+    filter: (report) => report.status !== 'ready',
+    state: 'live',
   }),
 );
 ```
@@ -67,7 +117,7 @@ const tasks = useAblo((ablo) =>
 ## Server Load
 
 ```tsx
-const [task] = await ablo.tasks.load({ where: { id } });
+const [report] = await ablo.weatherReports.load({ where: { id } });
 ```
 
 Use `load` in Server Components when the row may not be in the local pool yet.
@@ -79,8 +129,8 @@ For Server Actions and route handlers, call the SDK directly:
 ```ts
 import { ablo } from '@/lib/ablo';
 
-const snap = ablo.snapshot({ tasks: id });
-await ablo.tasks.update(id, patch, {
+const snap = ablo.snapshot({ weatherReports: id });
+await ablo.weatherReports.update(id, patch, {
   readAt: snap.stamp,
   onStale: 'reject',
   wait: 'confirmed',
@@ -88,17 +138,17 @@ await ablo.tasks.update(id, patch, {
 ```
 
 For client event handlers, get the provider-owned client and call the same
-model resource:
+model client:
 
 ```tsx
 const ablo = useAblo();
 
-async function markDone() {
+async function markReady() {
   if (!ablo) return;
-  const snap = ablo.snapshot({ tasks: id });
-  await ablo.tasks.update(
+  const snap = ablo.snapshot({ weatherReports: id });
+  await ablo.weatherReports.update(
     id,
-    { status: 'done' },
+    { status: 'ready' },
     { readAt: snap.stamp, onStale: 'reject', wait: 'confirmed' },
   );
 }

package/docs/roadmap.md

@@ -4,22 +4,32 @@ What is shipped, what is next, and what we will not build.
 
 ## Shipped
 
-- **Resources, intents, commits** — the core API.
-- **Capability tokens** — Biscuit-signed, scoped, attenuable, hot-revocable.
+- **Models, claims, commits** — the core API.
 - **Audit log** — hash-chained per principal, with `delegationChainRoot`.
 - **MCP transport** — HTTP server at `/api/mcp`.
 - **TypeScript SDK** — `@abloatai/ablo`, with React bindings.
 - **Dashboard** — keys, audit, metrics, allowed origins.
+- **Schema migrations** — declarative model schema changes. Pure
+  diff/classify/cast-safety/backfill planning engine (`diffSchema`,
+  `classifyMigration`, `classifyCast`, `isAutoApplicable`) ships in the SDK;
+  `ablo generate` emits typed clients from a pushed schema; the server
+  applies and activates migrations only on success.
+- **Structured error contract** — versioned (`ERROR_CONTRACT_VERSION`),
+  drift-guarded code registry shared across the HTTP, WebSocket, and MCP
+  planes, with always-on request ids and an OpenAPI error envelope.
+- **Relation-driven sync groups** — membership-routed fan-out via branded
+  `SyncGroup` + schema-declared identity roles (schema-JSON v2).
+- **Intent coordination plane** — Stripe-shaped `Intent` with per-model
+  `intent(id)` handles for lease/await/commit coordination between agents.
 
 ## In flight
 
-- **Real-time presence** — see who else is viewing/editing a resource.
+- **Real-time presence** — see who else is viewing/editing a model
+  (coordination primitives landed; presence surface in progress).
 - **Cross-instance fan-out via Redis** — pub/sub deltas at scale.
-- **Hot capability revocation UI** — in the dashboard, today via API only.
 
 ## On deck
 
-- **Schema migrations** — declarative resource schema changes.
 - **Field-level subscriptions** — subscribe to one path, not the whole row.
 - **Bulk import/export** — CSV/JSON round-trip with chain verification.
 
@@ -31,11 +41,11 @@ What is shipped, what is next, and what we will not build.
 
 ## We will not build
 
-- **A general-purpose Postgres wrapper** — Ablo Sync is for state with
+- **A general-purpose Postgres wrapper** — Ablo is for state with
   concurrency semantics, not for storing every table.
 - **Server-side compute** — no triggers, no stored procedures. Compute
   belongs in your application code.
-- **A document database UI** — your data lives in Ablo Sync; the UI is your
+- **A document database UI** — your data lives in Ablo; the UI is your
   product, not ours.
 
 ## How priorities shift