@abloatai/ablo 0.45.0 → 0.46.0

package/CHANGELOG.md

@@ -1,5 +1,18 @@
 # Changelog
 
+## 0.46.0
+
+### Pre-existing rows arrive on their own
+
+Connecting a database that already holds data no longer leaves those rows
+invisible until something touches them. Ablo snapshots the pre-existing rows
+automatically, `ablo connect check` refuses to report ready until that
+snapshot completes, and `ablo status --json` exposes the progress as
+`initialSnapshot.status`: `loading`, `retrying` with the underlying error, or
+`complete`. Keep an existing read fallback in place until the status reads
+`complete`. Row-touch backfill scripts are unnecessary; the snapshot is the
+engine's job.
+
 ## 0.45.0
 
 ### Claim admission is authoritative

package/docs/coordination.md

@@ -97,10 +97,9 @@ claim](#writing-under-a-claim)), and the [errors](#errors) you can catch.
 >
 > **Testing exclusion:** mint two sessions with different `agent.id` values,
 > assert those values differ, let A acquire the row, and inspect
-> `claim.state({ id })` before B calls `claim({ id, queue: false })`. B must
-> receive `null`. Creating two clients from the same key tests re-entrancy, not
-> contention. An empty `claim.state` is an observation/subscription issue; it
-> does not relax the authoritative lease check.
+> `claim.state({ id })` before B calls
+> `claim({ id, contention: { mode: 'skip' } })`. B must receive `null`.
+> Creating two clients from the same key tests re-entrancy, not contention.
 
 ---
 
@@ -502,6 +501,13 @@ ablo.<model>.claim.state({ id })
 Read who's currently working on a row, for observers and UI. Synchronous and
 reactive (it reads the local coordination snapshot). Never blocks.
 
+The first call also starts row-scoped observation. Because that subscription is
+asynchronous, an imperative script may briefly read `null` before the reactive
+snapshot arrives; subscribe to changes or wait for the expected holder when the
+observation itself is the test. Late subscriptions are backfilled across server
+instances, and a skipped conflict attempt seeds its authoritative holder
+summary into the same snapshot immediately.
+
 **You don't subscribe to anything first.** Reading or claiming a row
 automatically enrolls you in that row's sync group: reading it (including
 `retrieve`/`get`, or `claim.state` itself) gives you **read-interest**, and

package/docs/data-sources.md

@@ -74,6 +74,19 @@ yourself. Rotate the scoped passwords any time with `ablo connect rotate`.
 The rest of this page is what that command sets up, step by step, for when you want
 to run it by hand or review exactly what changes.
 
+### Existing rows load automatically
+
+When Ablo creates the replication slot, it takes a consistent initial snapshot of
+every mapped table in the publication before following new changes. Rows that
+predate `ablo connect` therefore become available to `retrieve`, `list`, and
+reactive `local.*` reads without an application backfill.
+
+Run `ablo connect check` before removing an existing HTTP/database read fallback.
+It reports the initial load as `loading` until the snapshot is complete. Do not
+write a script that updates every row to make it visible: an Ablo update requires
+the row to be visible already, and touching application rows is neither necessary
+nor a safe bootstrap mechanism.
+
 ## The setup, step by step
 
 ### 1. Enable logical decoding
@@ -172,6 +185,8 @@ checklist or the precise per-item fix:
   `REPLICA IDENTITY FULL`) so `UPDATE`/`DELETE` can replicate
 - the writer role is DML-ready — scoped, non-superuser, with the idempotency
   ledger in place
+- the initial snapshot is complete, so rows that existed before connecting are
+  available to Ablo reads
 
 Because Ablo checks from its own network, a database your own machine can't reach —
 IPv6-only, IP-allowlisted, behind a VPN — still verifies. Re-run it until every
@@ -195,8 +210,8 @@ export const ablo = Ablo({
 ```
 
 The Ablo schema describes **only your synced, collaborative models** — the rows
-Ablo coordinates and fans out in realtime. It is *not* your whole-database schema
-and does *not* replace your `schema.prisma` (or Drizzle schema). Your auth,
+Ablo coordinates and fans out in realtime. It is _not_ your whole-database schema
+and does _not_ replace your `schema.prisma` (or Drizzle schema). Your auth,
 billing, and other tables stay in your own ORM schema, owned by your own
 migrations. `ablo check` reflects this — it reports tables you didn't declare as
 "ignored / owned by you," which is exactly right.
@@ -226,13 +241,13 @@ state means and when to wait.
 
 This is the complete list. Nothing else.
 
-| Object | What it is | Owned by |
-|---|---|---|
-| `ablo_publication` | A publication naming the tables Ablo reads and confirms against. | You create it (step 2). |
-| `ablo_replicator` role | A `REPLICATION` + `SELECT` role Ablo reads and confirms through. | You create it (step 2). |
-| `ablo_writer` role | A scoped DML role Ablo writes your rows through: row DML + ledger, nothing more. | You create it (step 2). |
-| Replication slot | A logical slot Ablo subscribes through to track its WAL position. | Ablo's runtime creates it on first connect. |
-| `wal_level = logical` | A server setting that **requires a restart**. | You set it (step 1). |
+| Object                 | What it is                                                                       | Owned by                                    |
+| ---------------------- | -------------------------------------------------------------------------------- | ------------------------------------------- |
+| `ablo_publication`     | A publication naming the tables Ablo reads and confirms against.                 | You create it (step 2).                     |
+| `ablo_replicator` role | A `REPLICATION` + `SELECT` role Ablo reads and confirms through.                 | You create it (step 2).                     |
+| `ablo_writer` role     | A scoped DML role Ablo writes your rows through: row DML + ledger, nothing more. | You create it (step 2).                     |
+| Replication slot       | A logical slot Ablo subscribes through to track its WAL position.                | Ablo's runtime creates it on first connect. |
+| `wal_level = logical`  | A server setting that **requires a restart**.                                    | You set it (step 1).                        |
 
 Operational reality you should know up front:
 
@@ -254,7 +269,7 @@ have.
 
 ## What Ablo stores on its side
 
-Your schema *definition* (model names, fields, types — pushed with `ablo push`),
+Your schema _definition_ (model names, fields, types — pushed with `ablo push`),
 your hashed API keys, a safe projection of the connection registration (host,
 database, schema — the connection string itself is sealed and never echoed back),
 the replication slot position, and the ordered transaction log that drives sync and

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@abloatai/ablo",
-  "version": "0.45.0",
+  "version": "0.46.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.45.0",
-    "@abloatai/transaction": "^0.45.0"
+    "@abloatai/humans": "^0.46.0",
+    "@abloatai/transaction": "^0.46.0"
   },
   "peerDependencies": {
     "ai": "^6.0.0 || ^7.0.0",