@abloatai/ablo 0.46.0 → 0.48.0

package/docs/operating-on-your-database.md

@@ -46,7 +46,7 @@ Sort any action you're about to take into one of these, and the right move
 follows.
 
 **Run freely — read-only or reversible.**
-Reads (`retrieve`, `list`, `get`), `ablo check`, and `ablo pull` observe and
+Reads (`get`, `list`), `ablo check`, and `ablo pull` observe and
 never change anything. Previews — `--show-sql`, `--dry-run` — print the exact
 SQL a command would run without executing it. Model writes through
 `ablo.<model>.create` / `update` are claim-checked, optimistic, rolled back if
@@ -95,7 +95,7 @@ read-only checks:
   Read-only, like `prisma db pull`.
 - `--show-sql` / `--dry-run` on `connect` and `migrate` — the exact statements,
   printed and unexecuted, so you approve the SQL before it runs.
-- Read the row and its claim state before you write — `retrieve` / `list`, and
+- Read the row and its claim state before you write — `get` / `list`, and
   `ablo.<model>.claim.state({ id })` for who is already working on it.
 
 The pattern underneath all of it is steady: reads and model writes flow freely

package/docs/react.md

@@ -143,7 +143,7 @@ const reports = useAblo((ablo) =>
 const report = await ablo.weatherReports.get({ id });
 ```
 
-Use `retrieve` in Server Components when the row may not be in the local pool
+Use `get` in Server Components when the row may not be in the local pool
 yet — it hydrates from the local store and the server, and returns a Promise, so
 `await` it. (Server reads come in two shapes: `get({ id })` for one row and
 `list({ where })` for many; both are async. The synchronous local reads are
@@ -162,7 +162,6 @@ await ablo.weatherReports.update({
   data: patch,
   readAt: snap.stamp,
   onStale: 'reject',
-  wait: 'confirmed',
 });
 ```
 
@@ -180,7 +179,6 @@ async function markReady() {
     data: { status: 'ready' },
     readAt: snap.stamp,
     onStale: 'reject',
-    wait: 'confirmed',
   });
 }
 ```

package/docs/schema-contract.md

@@ -6,7 +6,7 @@ Ablo's schema is the integration contract. Define it once, pass it to `Ablo(...)
 and every actor gets the same typed model surface:
 
 ```txt
-defineSchema(...) -> ablo.<model>.create/retrieve/update/claim(...)
+defineSchema(...) -> ablo.<model>.create/get/update/claim(...)
 ```
 
 That one object drives:
@@ -84,7 +84,7 @@ const pending = ablo.weatherReports.local.list({ where: { status: 'pending' } })
 Use model writes for every actor:
 
 ```ts
-await ablo.weatherReports.update({ id: reportId, data: { status: 'ready' }, wait: 'confirmed' });
+await ablo.weatherReports.update({ id: reportId, data: { status: 'ready' } });
 ```
 
 ## Coordination

package/examples/README.md

@@ -21,7 +21,7 @@ const ablo = Ablo({ schema, apiKey: process.env.ABLO_API_KEY });
 Then:
 
 - create with `ablo.weatherReports.create`
-- read with `ablo.weatherReports.retrieve` or `ablo.weatherReports.list`
+- read with `ablo.weatherReports.get` or `ablo.weatherReports.list`
 - coordinate long-running work with `ablo.weatherReports.claim`
 - write with `ablo.weatherReports.update`
 - dispose the client when the worker finishes

package/llms.txt

@@ -61,11 +61,10 @@ await using claim = await ablo.weatherReports.claim({ id: 'report_stockholm' });
 const updated = await ablo.weatherReports.update({
   id: claim.data.id,
   data: { status: 'ready', forecast: await getForecast(claim.data) },
-  wait: 'confirmed',
 });
 ```
 
-That is the normal app path: declare models in a schema, then use `ablo.<model>.retrieve(...)`, `ablo.<model>.create(...)`, `ablo.<model>.update(...)`, and `ablo.<model>.delete(...)`.
+That is the normal app path: declare models in a schema, then use `ablo.<model>.get({ id })`, `ablo.<model>.create(...)`, `ablo.<model>.update(...)`, and `ablo.<model>.delete(...)`. Every verb takes a single options object.
 
 Treat the schema as the integration contract. It drives typed model clients,
 React selectors, server and agent writes, Data Source request/response shape,
@@ -137,7 +136,7 @@ frees. Use `ifClaimed: 'fail'` when you'd rather refuse to read a claimed row.
 
 ## Guarantees
 
-`wait: 'confirmed'` means the server accepted the write. Schema model writes are optimistic by default; server rejection rolls back local state. To prevent lost updates, read with `snapshot(...)` to capture a `readAt`, then write with `onStale: 'reject'` — the server rejects your update if someone else changed the row after that `readAt`.
+Schema model writes update local state optimistically, while their returned promise always waits for authoritative confirmation. Server rejection rolls back local state. To prevent lost updates, read with `snapshot(...)` to capture a `readAt`, then write with `onStale: 'reject'` — the server rejects your update if someone else changed the row after that `readAt`.
 
 Claims coordinate writers; they do not block readers. Most users should stay on
 schema-backed reads/writes and `claim(...)`; manual protocol bookkeeping is not

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@abloatai/ablo",
-  "version": "0.46.0",
+  "version": "0.48.0",
   "description": "The public Ablo SDK for coordinated reads, commits, claims, observation, and reactive applications.",
   "license": "Apache-2.0",
   "type": "module",
@@ -124,8 +124,8 @@
     "directory": "packages/ablo"
   },
   "dependencies": {
-    "@abloatai/humans": "^0.46.0",
-    "@abloatai/transaction": "^0.46.0"
+    "@abloatai/humans": "^0.48.0",
+    "@abloatai/transaction": "^0.48.0"
   },
   "peerDependencies": {
     "ai": "^6.0.0 || ^7.0.0",

package/docs/internal/agent-orchestration.md

@@ -1,58 +0,0 @@
-# Agent Orchestration
-
-Do not model parent and child agents as directly talking to each other over WebSocket.
-
-Model them as actors coordinating through models:
-
-```txt
-parent creates job -> child claims job -> child commits result -> parent reads result
-```
-
-The WebSocket is delivery infrastructure. The product model is shared state.
-
-## Model Shape
-
-A parent creates a job through its typed model client:
-
-```ts
-const jobId = `forecast:${runId}`;
-await ablo.agentJobs.create({
-  id: jobId,
-  idempotencyKey: `job:${runId}`,
-  data: {
-    status: 'open',
-    kind: 'forecast_report',
-    target: { model: 'weatherReports', id: 'report_stockholm', field: 'forecast' },
-  },
-  wait: 'confirmed',
-});
-```
-
-The child claims the job. If another worker holds it, the claim waits fairly,
-then returns the fresh row:
-
-```ts
-await using claim = await ablo.agentJobs.claim({
-  id: jobId,
-  description: 'complete',
-  ttl: '5m',
-});
-const job = claim.data;
-
-await ablo.agentJobs.update({
-  id: job.id,
-  data: {
-    status: 'completed',
-    result: { text },
-  },
-});
-```
-
-The child commits completion through the normal `update`, which is stale-guarded
-under the held claim. The claim releases when its scope exits.
-
-The parent retrieves the job result by model ID. Later, `ablo.events` can make that reactive, but the state model does not change.
-
-## Rule
-
-Nested agents should create or complete models. They should not require a separate agent-to-agent protocol for normal work.