bvandeusenandClaude Opus 5
5c1ae574f6
The desktop crate is a binary, and binaries commit their lockfile. Without one every run re-resolved the graph: a tagged .deb/.AppImage/.exe couldn't be rebuilt from its tag, any semver-compatible upstream release landed automatically on the next build — the failure mode hardest to read, because the commit that broke it changed nothing relevant — and Renovate had no lockfile to bump, leaving Rust dependency movement invisible to the Dashboard. Generated with cargo generate-lockfile inside ci-tauri:1.97, the same image CI builds in, so the format and the picked versions are what CI would have chosen itself. That takes the artifact-upload round-trip the issue proposed off the table: ci-requirements.md already blesses the image for cargo fmt, and resolving a dependency graph is no more a build than formatting is. 503 packages. Enforcement goes on each job's FIRST cargo invocation rather than the bundle build: cargo clippy --locked on Linux, and its own cargo fetch --locked step on Windows, whose only crate-graph command is otherwise the cross-compile itself. Drift fails in the first thirty seconds instead of thirty minutes in, and everything after the gate in that job compiles the recorded versions anyway. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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).