bvandeusenandClaude Opus 5
b5f7dc2635
Local -> server, then push-then-pull as the only ordering the UI can invoke.
LOCAL TOMBSTONES (schema v2). Found while writing push: delete_forever and
remove_label just DROPPED the row, leaving no record it existed. Offline that
means the delete can never be pushed — and the next pull faithfully
resurrects the note from the server. A deletion that undoes itself is about
the worst thing sync can do, so deletes now record into pending_deletes until
the server acknowledges them. merge_labels had the same hole.
merge_labels also moved memberships without marking the affected notes dirty.
A note's label set only reaches the server via the note itself, so a merge
looked done locally and never synced. Now marked before the delete cascades
the rows away.
Result handling, per status:
created/applied -> clear dirty, store the returned sync_revision
noop -> clear dirty, drop the tombstone (a row the server never
saw, created and deleted entirely offline)
kept -> clear dirty WITHOUT touching content. Re-pushing would
lose the same last-write-wins comparison forever; the
following pull adopts the server's version.
rejected -> stay dirty and surface the reason. A duplicate label name
is the realistic case and only a human can resolve it.
The subtle one is `kept` plus a skewed clock. Normally the server's kept
revision sits above our cursor, so the next pull fetches it anyway. If the
clock makes a genuinely later local edit look older, that revision can be
BELOW the cursor — the pull skips it and the stale local copy stays on screen
with nothing marking it wrong. So a kept result at or below the cursor
rewinds the cursor to re-fetch that note. Both directions tested.
label_ids carries MANUAL memberships only. Tag-sourced ones are re-derived
server-side from the body; sending them would convert them into manual
assignments that no longer disappear when the #tag is deleted from the text.
engine::run_cycle is push-then-pull, and a failed push ABORTS before the
pull — pulling anyway would overwrite the exact rows we just failed to save,
turning a recoverable network error into lost work. sync_pull is removed from
the command surface accordingly: offering a bare pull would hand the UI a way
to discard unsent edits. sync_now and sync_has_pending replace it.
Both loops have anti-spin guards: push stops when a batch clears nothing,
pull stops when the cursor doesn't advance.
15 push tests against an in-memory database.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi
ThoughtSync desktop (Tauri v2)
Local-first desktop client. The window loads the shared Vue 3 frontend from
../frontend; the Rust core (src-tauri) owns the on-device store and the opt-in
sync engine (built out across the M10 milestone). Works fully offline; optionally
syncs to a self-hosted ThoughtSync server.
Layout
desktop/
src-tauri/
Cargo.toml
build.rs
tauri.conf.json # frontendDist -> ../../frontend/dist, devUrl :5173
capabilities/default.json
src/
main.rs # thin shim -> lib::run()
lib.rs # tauri::Builder entry point
The Vue frontend is the sibling ../frontend package, shared with the web
build. On desktop it is backed by a local data source via
frontend/src/adapters/ (M10.3) instead of the server REST API. frontend and
src-tauri are siblings, not nested, so the beforeDev/beforeBuild
commands cd "$(git rev-parse --show-toplevel)/frontend" to resolve regardless of
the CLI's working directory.
Prerequisites
The toolchain (Rust + Node + WebKitGTK 4.1 + tauri-cli) is provided by the
ci-tauri CI image. For local dev: install Rust + Node, cargo install tauri-cli,
and the Tauri v2 Linux system deps — see CI-tauri/Dockerfile in the CI-runner
repo for the exact apt list (libwebkit2gtk-4.1-dev, libgtk-3-dev, librsvg2-dev,
libayatana-appindicator3-dev, libxdo-dev, patchelf, ...).
Dev
cd desktop/src-tauri && cargo tauri dev
beforeDevCommand starts the Vite dev server (port 5173) in ../frontend.
Build (Linux)
cargo tauri icon "$(git rev-parse --show-toplevel)/frontend/public/icon.svg"
cd desktop/src-tauri && cargo tauri build # -> .deb + .AppImage
App icons are generated from the frontend's icon.svg via cargo tauri icon
(not committed; CI does this before cargo tauri build). Bundle targets: deb,
appimage (Linux-first; Windows/macOS later, no code changes expected).
Status
Scaffold (M10.2): boots the shared Vue UI in a native window. Until the local data
adapter lands (M10.3 + M10.5) the app has no server configured, so it shows the
login screen without a working backend — full offline functionality arrives with
the local SQLite store (M10.4) + adapters/local.ts (M10.5).