The surface that turns the engine into a feature (rule 27). Desktop-only —
the web build IS a server's UI, so a "connect a server" screen there would be
nonsense; the route redirects to the board and the nav entry is hidden.

UNLINKED IS THE RESTING STATE, not an incomplete setup. The empty case leads
with "Working offline on this device — everything works without a server",
because a screen that framed the default as a problem would push people into
configuring something they may never need. The app is local-first; this is
opt-in.

Probe before credentials. "Check" shows who actually answered — site name,
version, and the M10.6 verdict — before any password or token is typed. An
incompatible server is shown in red and the sign-in fields never appear, so
you cannot hand a credential to something that can't use it. `degraded` names
the missing capabilities rather than staying quiet and letting a feature
mysteriously do nothing.

Both credential paths, matching the Rust side: email+password (a fresh
install has no session to mint a token from) or a pasted device token (for
anyone who'd rather not type a password into a desktop app). Secrets are
cleared from component state the moment they're exchanged.

Disconnect states plainly that the token stays valid server-side and points
at Account -> Linked devices, rather than implying a remote revoke that
didn't happen (issue 2110). Wording avoids "revoke" for exactly that reason.

Push rejections are surfaced verbatim after a sync, never swallowed — a
duplicate label name is the realistic case and only a person can resolve it.

Adds schema v3: last_sync_at. The cursor can't answer "am I up to date?" —
it's a revision watermark, not a time, and it doesn't move at all when a sync
legitimately finds nothing new, so "synced a moment ago, nothing new" would
be indistinguishable from "never synced". Stamped only after BOTH halves of
the cycle succeed; a stamp after a partial cycle would claim currency the
data doesn't have. Cleared on unlink so a new server can't inherit it.

run_cycle now returns the post-cycle status, so the UI updates from one
round-trip instead of chasing every sync with a status call.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi

2026-07-26 00:30:37 -04:00

packaging

desktop: cross-compiled Windows NSIS installer lane (task 2015)

2026-07-25 20:14:55 -04:00

src-tauri

M10.7e: desktop Sync settings screen (task 2108)

2026-07-26 00:30:37 -04:00

README.md

M10.2: Tauri v2 desktop scaffold (desktop/) — Vue frontend as the webview

2026-07-24 11:13:09 -04:00

README.md

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).