Files
thoughtsync/desktop
bvandeusenandClaude Opus 5 d8b0cd9b96
Desktop (Tauri) / Windows installer (cross-compiled) (push) Failing after 2m36s
Desktop (Tauri) / Tauri desktop (Linux) (push) Failing after 4m32s
Desktop (Tauri) / Update manifest (push) Has been skipped
packaging: the installer learns the same two channels the app updates on
install.sh asked /releases/latest and installed whatever came back. That is
v0.1.0 today, which predates the updater, and it was about to get worse: the
`stable` pointer release write-manifest.sh creates is non-prerelease and holds
only latest.json, so from the next v* tag onward it would have WON
/releases/latest and the installer would have found nothing to install.

So resolve a channel instead of a "latest". `--channel stable|dev` (or
TS_CHANNEL), default stable, named to match update.rs's Channel exactly. dev
reads /releases/tags/dev. stable reads the pointer's own latest.json, takes its
version, and installs that v* release — the same file the app reads, so the
installer and the updater cannot disagree about what stable means.

Two things found on the way. The dev release's description still told people to
run the stable command, and always would have: publish-release.sh writes a body
only when it CREATES a release, and a fixed-tag release is only created once, so
the text froze at the first build. The 409 path now PATCHes it. And the asset
greps were unanchored, so a .AppImage.sig URL could match as the bundle URL —
harmless by coincidence, not by construction.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MKsUY9Z45KQd34V956hZ9Q
2026-07-27 23:03:12 -04:00
..

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