All packsOffline Sync EngineSolve
offline sync clock skew local edits reverting
A wrong device clock makes your own edits disappear
A device with a slow clock loses every edit it makes to a value it just pulled from a fast-clocked device -- the user watches their own edit revert.
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?
Last-write-wins conflict resolution needs a way to compare "when" two writes happened, and if that comparison is based on each device's own physical clock without correction, a device whose clock is meaningfully behind another device's will lose every conflict, even for edits made after the fact from the user's perspective. The user edits a field on screen, it saves, and then a later sync pulls the other device's earlier-clock-but-higher-priority write back over it -- the edit visibly reverts with no error shown.
Why this one is easy to get wrong
Using Date.now() as a write's timestamp is the obvious, simplest implementation of last-write-wins, and it works correctly on every device whose clock happens to be accurate -- which is nearly all of them, nearly all of the time, in casual testing. The failure mode requires an actual clock skew between two specific devices to reproduce, which most development and QA setups don't have.
What you get instead
The engine's observe() method folds in every remote physical timestamp it sees -- from pulled changes and from serverTimeMs on every sync response -- so a device's next locally minted timestamp is guaranteed to exceed everything it has ever observed, regardless of its own clock's accuracy. On top of that, the server outright rejects (400 clock_skew) any push whose physical time is more than 5 minutes ahead of server time, and the client re-stamps its entire outbox using server time and retries, rewriting its own local cells so it doesn't just correct future writes but stops rejecting legitimate past ones too.
Source: ARCHITECTURE.md 'Clock skew policy (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 →