Fresh install bugs usually look like UI bugs. This one wasn't.
In Wimemo, a reinstall synced before restore finished, pushed plans: [], and tombstoned the server backup 4 minutes after login.
The dangerous assumption was simple: an empty client on a fresh install is authoritative. It isn't.
The audit found 2 affected founder-controlled accounts, 9 recoverable plans, and 0 third-party users.
The first fix was blunt: stop destructive empty sweeps when the snapshot is empty.
The durable fix was a restore_state handshake: pending, completed, or skipped. Now an empty snapshot can only delete server data after recovery is settled.
Reusable lesson: in a local-first or offline-first product, "empty" is at least two different states: intentionally empty and not-restored-yet. If your sync protocol can't tell them apart, restore is not part of the contract yet.
What client state in your product is currently allowed to delete server data, and how do you prove it's post-restore rather than merely empty?