The shape we agreed: each PC keeps its own local SQLite and they exchange
CHANGES through a folder the operator already has — Seafile, OneDrive, a NAS, a
USB stick. Not the database file: SQLite over SMB or NFS corrupts, and in WAL
mode the shared-memory index has no meaning across machines at all.
The rule that makes a shared folder safe is one writer per file, append only.
Each machine writes only its own <machine>.ndjson and never touches another's,
so a sync client that replicates whole files can never merge two writers into
one — there are never two. That is the exact opposite of putting the database
there, and it is why it works.
This is the half internal/offlineq deliberately refuses to be: its own doc says
"no mirror, no pull, no merge, no tombstones". All four are here.
Four decisions worth naming, each with a test:
Tombstones. A delete is a record. Without one, a QSO removed on the laptop comes
back on the next sync from the shack PC, for ever — and a contact logged again
after a deletion has to come back, which the ordering also has to allow.
Determinism. Last writer wins, ordered on (time, the writer's own counter, the
writer's id) — not on time alone. Two PCs' clocks are never equal, so a bare
timestamp is not even a total order: two machines merging the same pair in
different orders could reach different answers and disagree for ever. Skew still
decides WHICH edit wins and nothing can fix that; what this guarantees is that
every machine agrees on the winner.
Resumption. Readers resume at a byte offset, so a 40 000-contact file is read
once and thereafter only its tail — and the offset advances only past COMPLETE
lines, because a folder sync catches a file mid-upload sooner or later. A file
that SHRANK was replaced rather than appended to, and is re-read from the start.
Survivability. One unreadable line costs one record. A record stamped with a
FUTURE format version is skipped, never guessed at.
Core only: no UI and nothing wired to the logbook yet, so nothing is
user-visible and there is no changelog entry. Next is the sync_uid column, the
add/update/delete hooks and the settings panel.
