All packsOffline Sync EngineSolve
crdt tombstone deleted row resurrected by edit
An edit to another field shouldn't undelete a row
If a later edit to any column of a deleted row silently undoes the delete, every offline edit made against stale data becomes a potential zombie record.
This is one of the things Offline Sync Engine already handles. Let your app keep working with no internet, then merge the changes correctly when it reconnects.
Is this you?
In a system without an explicit delete-wins rule, a device that queued an offline edit to some field of a row -- unaware the row was deleted elsewhere in the meantime -- can have that edit sync in and effectively resurrect the row, because nothing about writing to one column inherently respects a delete recorded on a different column. A record the user explicitly deleted comes back, seeded from whatever stale offline edit happened to arrive after the delete.
Why this one is easy to get wrong
Per-field conflict resolution (each column merges independently, which is the pack's whole point for concurrent edits to different fields) makes "the delete is just another cell" a very natural, consistent-sounding design -- until you ask what happens when a different cell on the same row gets written after the delete cell, which requires deliberately deciding that reads should treat _deleted specially rather than symmetrically with every other column.
What you get instead
The pack encodes delete as an ordinary cell (_deleted = true) that replicates and resolves by HLC like anything else, but readers (getRow, listRows) explicitly drop any row whose _deleted cell reads true, regardless of what any other column says. Undelete requires an explicit _deleted = false write with a later HLC -- there's no implicit resurrection path, and the pack documents the exact boundary of this guarantee: it holds within the 90-day tombstone retention window, not indefinitely.
Source: ARCHITECTURE.md 'Deletes and tombstones (decided)' — checkable in the pack you receive
How you actually use this
You don’t install a library or wire up an SDK. Your own coding agent builds the code in your project, and you keep it — no runtime dependency on us.
Step 1
Download and unzip
You get a folder: the docs that tell an agent what to build, a starting skeleton, and the test suite that decides when it's done.
Step 2
Open it in Claude Code or Cursor
Point your coding agent at the folder. Nothing to install, no account with us, no API key.
Step 3
Paste one prompt
The pack contains the exact prompt. Paste it as your first message and leave it alone — it works through the build itself, choosing a cheaper or stronger model per task.
Step 4
Run ./verify.sh
One command. It prints a pass or fail for every check. Green means the build is done — the same script we ran to produce the receipt on this page.
Typical build: about 12 minutes of your agent working, mostly unattended. Then you integrate the working module into your app the way you would any code you’d written yourself.
Why you can believe this
2 of 3 runs passedWe ran this pack from an empty folder 3 times and published exactly what happened — every check, the model, the token cost, the wall time. Not a testimonial, and not our opinion: the same verify.sh you run yourself. Read the full receipt →