Trash had no end. A note sat in /trash until someone emptied it by hand, and
its attachment BYTES sat on disk the whole time — the pile-up the operator
asked about. Nothing purged; there was no scheduler at all.

Retention is server-owned: `trash_retention_days` (default 30, 0 = keep
forever) in the settings registry, so it lands in admin Settings with no
migration and takes effect without a restart. A background sweep started in
before_serving does the work. Clients learn about a purge the way they learn
about any deletion — as a tombstone on the delta feed.

An auto-purge nobody can see coming is data loss on a timer, so the window is
now visible: /api/config publishes it, notes carry `deleted_at`, Trash leads
with the policy, and each card counts down. The countdown rounds DOWN — saying
"1 day left" for a note with ten minutes on the clock is the one error here
that actually costs someone a note.

Three things this turned up on the way:

- `DELETE /api/notes/<id>` hard-deleted the row, leaving no tombstone at all.
  A permanent delete in the web UI never reached a linked device, which would
  keep its copy forever and push it back on the next edit. It now purges
  through the same path as everything else.
- The purge left `note_revisions` and `note_link_previews` behind. A revision
  holds the full body, so the text of a "permanently deleted" note was still
  sitting in the database.
- `deleted_at` now SURVIVES a purge instead of being cleared. It's still true,
  and it means every query that says "not trashed" excludes tombstones for
  free — without it a content-less row reads as a perfectly normal active note
  and shows up on the board as a blank card.

Desktop keeps its own clock only when there's nobody else to keep one: the
sweep runs at startup on an UNLINKED device and refuses otherwise. A linked
client that expired notes on its own schedule could destroy something the
server was deliberately keeping, then push that delete upstream. Local policy
must never outrank the server's — so it also adopts the server's window for
the countdown rather than showing its offline default.

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

2026-07-26 16:20:13 -04:00

packaging

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

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

src-tauri

Expire trash after 30 days, and make the deadline something you can see

2026-07-26 16:20:13 -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).