All packsOffline Sync EngineSolve
offline queue schema migration versioned messages
An app upgrade can leave the offline queue speaking the old schema
A device with a full offline queue that upgrades to a new app version can push messages shaped for a schema the server no longer accepts.
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?
A device that's been offline for a while, accumulating queued writes, and then receives an app update before reconnecting now holds an outbox full of messages shaped for the old wire schema -- while the server (and every other already-updated client) expects the new one. Pushing those old-shaped messages either corrupts data under the new schema's assumptions or fails outright, and the failure can strand a real user's legitimately queued offline work.
Why this one is easy to get wrong
Schema migrations are normally reasoned about as a server-and-database concern -- run a migration, update the code, done. A client-side outbox holding messages written under a previous version of the wire format is a consequence specific to offline-first sync that doesn't come up in a typical online CRUD app, where there's no persisted client-side queue spanning an app upgrade to begin with.
What you get instead
Every outbox entry stores the schemaVersion it was written under, and migrateOutbox() walks each queued message forward through a registry of per-version migration functions before anything gets pushed -- SyncEngine.sync() calls it first, unconditionally, so an app upgrade with a full offline queue migrates the queue before ever touching the network. The server additionally accepts only the current wire version and returns 426 upgrade_required on anything else, so a client that somehow skipped migration fails loudly instead of writing malformed data.
Source: ARCHITECTURE.md 'Schema migration of queued mutations (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 →