37 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	ee771e3734	Every lock of the store goes through Db::conn ... Db::conn is documented as the one way to take the lock, yet five production and test sites reached past it with db.0.lock(): the startup summary, the desktop's trash sweep and config_get, and tests in sharing and update. All five now call conn(). DRY pass #2, batch 2, F8 (#5372). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 14:23:07 -04:00
bvandeusenandClaude Opus 5.5	ef839ba0cd	The store's layout names live in the core: local::DB_FILE, BLOBS_DIR ... "inkwell.db" and "blobs" were spelled out in the ffi and the desktop (whose copy of DB_FILE sat in the crossover shim). The layout is the core's, the same on every client, so the names are now core constants and both clients read them. DRY pass #2, batch 1, F4 (#5372). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 14:17:26 -04:00
bvandeusenandClaude Opus 5.5	b03c9cf81a	desktop: in-app updates follow the server you installed from ... Milestone 325 step 6 (Scribe #3254). The server publishes its AppImage in the updater's own format at /api/client/linux-appimage/update.json: the ordering key as `version`, the signature, and an absolute download URL built on the host that was asked, so the token the updater attaches goes nowhere else. Unsigned platforms and a server with no AppImage 404. The desktop's update source is now Fabled-Git (and its channel) or one server: - `read_source` is the one reader. The installer's `install-server` marker feeds the `update_server` pref once per new value, exactly as the channel marker feeds its pref; tauri.conf.json's endpoint is never consulted. - From a server, the check and the download carry the sync link's token when the app is linked to that same server. Without one the update shows and says to link rather than offering a button that 401s. - A server with no build says so. A 404 is "up to date" only on the forge, where it means an unpublished channel. - Sync → App updates offers the source once there is a server to offer (the chosen one, or the linked one), and only shows the channel for the forge. The trust anchor does not move: whatever the source, the updater verifies the AppImage against the public key built into the app. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 06:56:36 -04:00
bvandeusenandClaude Opus 5.5	b019172d47	all: remove saved views, the Has-reminder filter and the Created range ... Step 18 of the audit follow-through (#5180), on the operator's decisions. Inkwell is for capture and recall (note 2897), and these three duplicated a surface that does the job already: - Saved views. They lived only on the web; the desktop kept its own set that never synced, and Android had none. Tags in the drawer already give one-click recall. Gone from the server (routes, model, migration 0038 drops the table), the core (store functions, schema v13 drops its table), the desktop commands, the web adapters, the drawer's Views list and the "Save view" link. - The "Has reminder" facet. The Reminders page lists them, sorted by due. - The FilterBar's "Created" range. Timeline is the date lens and keeps the created_after/created_before query it builds from local days, which also retires the UTC/local-day disagreement between the two (B3). An old link that still carries the removed keys opens the plain board; a web test pins that. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-07 21:29:28 -04:00
bvandeusenandClaude Opus 5.5	7eacd0569c	all: delete the code nothing calls ... From the audit (#5178). Each was unreachable from every client: - Checklist add-item and delete-item: REST POST /items and DELETE /items/<id>, the Tauri commands, the store, rest and local adapters, the core's add_item/delete_item, set_item_text and remove_item, and the FFI exports. Adding, rewording and removing an item are body edits in every editor. The checked toggle stays, and its rewriter is simpler without the drop branch. - Manual unfurl: POST /unfurl and its adapters. Previews arrive in the background after a save (unfurl_queue). - The /api/config `android_client` key, android_release() and the APK_NAME/MANIFEST_NAME aliases. Phones poll /api/client/android. - users.email_verified and users.avatar_path (migration 0037). Nothing set the first or read the second; the SMTP reset never checked verification. - derive::extract_tags (only tests used it; the shared fixture now runs through extract_tag_spans), the unused check and link icons, and the unused editor_add_item string. - The blob scheme is renamed tsblob -> inkblob. URLs are built as notes are read, so nothing stored carries the old one. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-07 19:00:44 -04:00
bvandeusenandClaude Opus 5.5	aa36b43dc3	core: shared notes on the desktop and phone, and Share from the desktop ... The core pulls with shares from a server offering them (protocol 6): a note says how it is held (owner, edit, view) and who shared it, and a revoked note leaves the device. The first such pull starts the feed over once, so notes shared before this build arrive. The store refuses what a share doesn't allow (view: everything; edit: anything but the text), push sends only the text of someone else's note, and their notes stay out of trash, reminders and reordering. Unlinking drops them. The Share dialog's calls go to the linked server over the device token, as Tauri commands and through the FFI. The desktop now offers Share and "Shared with me"; unlinked, the dialog says sharing needs a server. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-07 15:33:16 -04:00
bvandeusenandClaude Opus 5.5	df85535ea2	desktop: reminders reach you when the window isn't in front ... A Rust worker reads due reminders from the local store every 15 s and announces each occurrence once: always to the main window as a toast, and as a system notification (tauri-plugin-notification) when that window isn't focused. The page no longer polls on the desktop; its Notification went nowhere in WebKitGTK and its timer stopped with the window. The Reminders page says what each surface actually does. Core gains store::due_reminders, compared by instant, not by string. Refs #5171 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-07 12:46:02 -04:00
bvandeusenandClaude Opus 5.5	5989ffc1c6	desktop: Import and Export work offline; the menu toggle is reachable; errors say why ... Export and Import were a link to the server and a reject("needs a server") on the desktop. Both now run in the core with no server: - core/src/local/portable.rs builds the same zip the server writes (notes.json, a Markdown file per note, each attachment this device holds) and reads either export marker or a Google Keep Takeout zip, with the server's decompression budget and an all-or-nothing transaction. Export saves to Downloads (no new plugin) and the sidebar says where; Import takes the archive as raw IPC bytes. - core/testdata/portable.json pins the format for both copies: the server runs its Keep and native readers against it (test_portable_fixture.py) and checks its real export's keys (test_integration.py); the core runs the same cases. - Found on the way: both importers skipped a Keep note that is only a photo as "empty". It now imports, on the server and in the core. - New dependency, approved: `zip` (deflate only) plus `flate2` on its pure-Rust backend, both already in the lockfile. The AppImage applications-menu toggle moves from Account, which the desktop never shows, to the Sync page; the first-run prompt now says so. errorMessage (#5236) replaces the hand-rolled `.error ?? …` / `.message ?? e` reads at the remaining catch sites, so a desktop failure shows its real reason. Task #5170. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-07 11:36:42 -04:00
bvandeusenandClaude Opus 5.5	2b2ceaa82e	attachments sync: attach offline, upload when linked, removals stick (#5168) ... Desktop could not create an attachment at all, and a removed attachment or dismissed preview came back on the next pull. Now: - core: add_attachment keeps the bytes in the blob store and queues the row (schema v10: attachments.uploaded / upload_error). Push uploads it once its note has landed. A refusal that retrying won't fix (too large, id clash, hash mismatch) is recorded on the file and not re-sent every cycle; the editor shows it. - core: removing a synced attachment or dismissing a preview leaves a tombstone in pending_deletes; push sends it as an `attachment`/`preview` delete, and a pull while it waits doesn't put the row back. A pull also keeps files still waiting to upload instead of replacing them wholesale. - server: PUT /api/sync/attachments/<id> (raw body, sha256-checked, idempotent, size-capped) and child deletes in push, which apply regardless of LWW and answer noop for rows the caller can't see. One store_attachment helper for the upload route, the importer and sync. Protocol 5, feature attachment_sync; the client sends neither to a server without it. - server: migration 0031 makes a link preview's insert/delete bump its note, so background-fetched previews and web dismissals reach linked devices. - desktop: Attach and paste-image work offline (raw-bytes IPC command). - SVG is served as a download by the desktop blob scheme too (as #1981 did for the web), and drawn as a file chip on both. - autosync: drop the catch_unwind; release builds abort on panic, so it only ever worked in debug builds. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-07 10:07:52 -04:00
bvandeusenandClaude Opus 5.5	efb141e555	desktop: syncs on its own — at launch, soon after an edit, every few minutes and on focus ... Until now the only caller of the sync engine was the "Sync now" button. A worker thread now owns every cycle (the button's included, so two never overlap): - launch: one cycle as the app opens; - edit: every 10s it reads a fingerprint of the pending set and sends when that moved. A fingerprint rather than "anything pending", because a rejected change stays pending and would otherwise be resent every tick forever; - timer: a pull every 5 minutes with nothing to send; - focus: at most once per 30s. Failed automatic cycles back off (doubling from 10s to 5 minutes). A panicking cycle counts as a failed one rather than ending the thread. Every cycle is emitted as inkwell://synced: the board reloads when the pull changed something, and the Sync screen shows the last automatic failure. No final push on quit; the launch cycle sends whatever was left. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 23:40:27 -04:00
bvandeusenandClaude Opus 5.5	fe6f0746b2	rename: the desktop is Inkwell — crates, Tauri identity, data move, packaging ... Step 3 of milestone 481 (Scribe note 5071: a full rename). - crates thoughtsync-{core,desktop,ffi,uniffi-bindgen} → inkwell-*, the Cargo.lock entries moved to match (checked with `cargo metadata --locked`) - Tauri: productName "Inkwell", identifier com.fabledsword.inkwell, binary `inkwell`, updater feed on bvandeusen/inkwell, store file inkwell.db - client agent inkwell-desktop, headers X-Inkwell-Client/-Protocol (the server reads neither), capture event inkwell://captured, display-version env - .deb: conflicts + replaces thought-sync, so the updater's install retires the old package instead of colliding on it. kebab-case("Inkwell") is `inkwell`, so the package name finally matches the command and verify.sh now asserts it - pacman: inkwell, conflicting with and replacing thoughtsync and thoughtsync-desktop - AppImage ~/Applications/Inkwell.AppImage, menu entry inkwell.desktop, installer, release titles, desktop asset names in fetch-clients.sh The one shim, chosen by the operator because it is the only copy of a local-first user's notes: crossover.rs moves the old com.fabledsword.thoughtsync app-data dir's contents into the new one on startup, before the store opens, renaming thoughtsync.db and its -wal/-shm with it. It skips when the new dir already has a store, and anything already in the new dir wins (the installer writes its channel marker there first). Tested. Android's Kotlin side (package, applicationId, uniffi class) is step 4. Its release asset names stay thoughtsync.* until then. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 14:27:26 -04:00
bvandeusenandClaude Opus 5.5	f806e35d41	rename: the apps say Inkwell — web, desktop, Android and server strings ... ThoughtSync is renamed Inkwell ("Fabled Inkwell" in full; Scribe note 5071). This is step 1 of milestone 481: every string a person reads in the running apps. Identities installed clients depend on are deliberately untouched — the Tauri productName (it derives the .deb Package: field), identifier and binary name, applicationId, X-ThoughtSync-* headers, the export's app marker, env vars, module and crate names. - web: title, PWA manifest (name "Fabled Inkwell", short_name "Inkwell"), offline page, icon labels, build labels, prompts, notification title - server: site_name default, import error, link-preview User-Agent - 0030: a stored site_name of exactly the old default follows the rename. The Settings page saves every key, so most servers hold "ThoughtSync" without an admin ever having chosen it; a name they typed is left alone - desktop: window title, default device name, local-mode site name, log line - android: app_name and the strings that name the app - core: probe and compatibility messages Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 13:16:14 -04:00
bvandeusenandClaude Opus 5	6c0153be1e	desktop: a global hotkey opens a small window to write in, now with its lockfile ... Restores 42e06da, which was reverted only because Cargo.lock had not been updated for the new crate and every cargo invocation in CI passes `--locked`. Both desktop jobs failed on that line before compiling anything, so nothing about the code had been judged. The lockfile was generated in CI's own `ci-tauri:1.97` image — one container, `cargo fetch`, nothing built. `cargo fetch` and NOT `generate-lockfile`: the latter re-resolves from scratch and would have churned versions across the whole workspace to add one dependency. The diff is 67 insertions, zero deletions, six packages — tauri-plugin-global-shortcut plus global-hotkey, x11rb, x11rb-protocol, xkeysym and gethostname. Nothing existing moved. The feature itself, unchanged from 42e06da: Press the combination anywhere and a small window arrives over whatever you were doing; type, Ctrl/Cmd+Enter, gone. The board never comes forward. There is no default shortcut on purpose — any default is a key combination taken away from something else on somebody's machine, silently, at install time. CommandOrControl+Shift+N is offered as a one-click suggestion. Stored and live are separate fields because they disagree: a combination another app holds is saved and does nothing when pressed, and a Wayland compositor may refuse global grabs outright. `capture_shortcut_set` registers before storing, so a refused combination is never written down as if it worked. The window hides rather than closes and keeps its text, so an interrupted capture is still there next press — which is what makes Escape safe. A failed save keeps it open too, rather than discarding the only copy of something just written in order to report a retryable problem. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c	2026-09-01 18:05:20 -04:00
bvandeusenandClaude Opus 5	10ea15bef0	Revert the desktop hotkey: a new crate needs a Cargo.lock this machine cannot write ... `42e06da` added `tauri-plugin-global-shortcut` to Cargo.toml without updating Cargo.lock, and every cargo invocation in CI passes `--locked`. Both desktop jobs failed on the same line before compiling anything: error: cannot update the lock file ... because --locked was passed So this says nothing about whether the code is right — clippy never ran. The gate did exactly its job. There is no Rust toolchain on this workstation (rule 10 — CI verifies), and a lockfile is the one artifact CI is deliberately forbidden to generate. Hand- writing the entries is not a real option: it needs the exact checksum and the whole transitive tree, and a wrong checksum fails harder than a missing one. Reverted rather than left red, because a red `dev` blocks everything behind it and the Android half of #1899 is green and unaffected at c8318c3. The work is intact in 42e06da and comes back with `git revert 5e0c...` once the lockfile exists — nothing here needs rewriting. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c	2026-09-01 09:10:33 -04:00
bvandeusenandClaude Opus 5	42e06da576	desktop: a global hotkey opens a small window to write in, and nothing else ... The other half of #1899. Press the combination anywhere and a 520x220 window arrives over whatever you were doing; type, Ctrl/Cmd+Enter, it is gone. The board never comes forward, which is the whole point — bringing the app up to write one line is the friction this removes. ## There is no default shortcut, deliberately A global shortcut is the one setting here that can collide with software this app knows nothing about. Any default is a key combination taken away from something on somebody's machine, silently, at install time. So the feature is OFF until a combination is chosen, and choosing one is how it turns on. CommandOrControl+Shift+N is offered as a one-click suggestion, never applied on the user's behalf. ## Stored and live are reported separately `CaptureShortcut` carries both `shortcut` and `registered`, because they genuinely disagree: a combination another app grabbed first is saved and does nothing when pressed, and on Wayland a compositor may refuse global grabs outright. Saying only "your shortcut is X" would be a lie with a keystroke attached, so the settings row says "saved but isn't active — something else is holding it". `capture_shortcut_set` registers BEFORE storing, so a combination the system refuses is never written down as though it worked. Registration at startup is best-effort and logged: a shortcut that worked when it was chosen can be taken by something installed later, and the app must still open. ## Two windows, one database, no shared store The capture window runs a second copy of the frontend with its own Pinia stores, so a note saved there is invisible to the board until it is told. It is told — `capture_done(saved)` emits to `main`, and BoardView reloads. The emit failing is cosmetic (the note is already in SQLite) so it is logged, not raised. The window is opened at `index.html?capture=1` rather than at `/capture` because the bundled assets are served as FILES: a path with no file behind it 404s in the production build while routing fine under the dev server. The router turns the query into the route. It is hidden rather than closed on the way out, and it keeps its text. A capture interrupted by something more urgent is still there on the next press, which is what makes Escape safe to press. A failed save also keeps the window open holding the text — hiding it would throw away the only copy of something just written in order to report a problem you could retry your way out of. ## Where the setting lives Rule 25 says a tunable belongs in the UI, and this one has to be. It sits in the desktop's Sync screen beside the update channel, not in admin Settings: that screen is the SERVER's and bounces on desktop anyway, while this is a property of one installation on one machine. Persisted with the same `store::set_pref` the update channel uses. No @tauri-apps/api dependency was added — everything routes through `invoke` and the `withGlobalTauri` global, as the rest of the bridge does. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c	2026-09-01 09:02:39 -04:00
bvandeusenandClaude Opus 5	c40916699b	sync: the client header said "desktop" from every phone, and named the wrong version ... `client_headers()` built `thoughtsync-desktop/{CARGO_PKG_VERSION}`, and both halves were wrong. This crate is compiled into the Android app as well as the desktop one, so every phone in the field announced itself as a desktop. And CARGO_PKG_VERSION here is the CORE crate's version — a number no build stamps and no user has ever seen — where the thing a reader of that header wants is the app's own build (note 3127 §5: with no version tags, the artifact's self-report is the only answer to "which build is this?"). The core cannot know either value, so the host says them. `set_client_agent` is a OnceLock the desktop fills in `run()` and Android fills in `ThoughtSyncApplication.onCreate`, before anything can sync. A host that never introduces itself sends `thoughtsync-unidentified/unknown` rather than a plausible default: nothing reads this header today, which is exactly why a wrong value could sit in it for months — the first person to look at a server log is the first who could catch it, and only if what they see is obviously a host that never said who it was. Android's version comes from the INSTALLED package, through a new `Context.installedVersionName()` that the foot of the Sync screen now shares. One answer to "which build is on this phone", so the line a person quotes in a bug report and the line in the server's log cannot disagree. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c	2026-08-31 08:40:01 -04:00
Bryan Van Deusen	f992439588	version: every surface can say which build it is, and two of them were lying ... Note 3127 §5 removed version tags, so an artifact's self-report is now the only answer to "which build is this?" — and nothing exists to contradict it when it is wrong. Three surfaces gain a dim build line: the foot of the web rail, the login screen, and the foot of Sync on Android. The login screen because "I can't sign in" is a bug report like any other, and requiring an account to read a build number withholds it from exactly the people who can't get past that page. `/api/config` is already public. Two of the values it was going to show were wrong, which is the part worth knowing about. The DESKTOP reported `env!("CARGO_PKG_VERSION")` from `config_get` and from the startup log. `cargo tauri build --config '{"version": ...}'` overrides tauri.conf.json, not Cargo's own metadata — so both read the literal `0.2.0` in Cargo.toml, on every build ever shipped. They now read a display version baked in by the lane through `option_env!`, hoisted to the crate root because two readers of one fact is how this repo keeps producing 2181-2183. Not the ordering key either: `1.0.<minutes>` is the opaque value Tauri's updater compares and must never be shown to a person, and `update.rs` still reads it because a comparator is exactly what it is (rule 149). The SERVER fell back to `__version__` when APP_VERSION was absent, so a server run from a checkout reported `0.2.0` — a real-looking version naming no build anybody could obtain. `__init__.py` already asserted the honest answer was "APP_VERSION being missing, which app.py already handles"; it did not, and a comment claiming a behaviour two files away is how that stayed true-sounding. Now an explicit "unknown", with the packaging version left where "unknown" is not a legal value. Android reads the INSTALLED package's versionName rather than BuildConfig, so it reports what is actually on the phone. Everything renders "unknown" rather than blank when it cannot say. A blank looks like a layout bug; a plausible default cannot be caught by anything. build.rs gets `rerun-if-env-changed` for the baked value: cargo does not track an `option_env!` variable on its own, and the desktop lane having no cache today is what makes that easy to forget the day one is added.	2026-08-29 23:07:29 -04:00
bvandeusen	7033995975	search is a facet on the board, not a place you go ... Operator (note 2930): tags exist so you can *"filter during a search"*. The server has always been able to do that — `GET /api/notes` composes `?q=` with `?label=` and the rest into one AND-ed query. The frontend never reached it. The header search box navigated to `/search`, and that view called a DIFFERENT endpoint — `GET /api/notes/search?q=`, full text only, no facets at all. So the one screen you landed on when you searched was the one screen where you could not narrow by tag. Tag filtering lived on the board's FilterBar, which is where you weren't searching. Two search boxes, two endpoints, and only the hidden one did what tags are for. Now the header box writes `?q=` into the board's URL beside whatever labels are already there, and stays on the lens you're in — searching while looking at Trash searches Trash. The box READS from the URL rather than holding its own copy, so it stays in step with the Filters panel's Clear and with a saved view opened from the sidebar. Deleted: `SearchView.vue`, its route, `GET /api/notes/search`, `repo.notes.search` and both adapter implementations, and the `notes_search` Tauri command whose only caller was the adapter entry. FilterBar loses its own "Search text…" input — it was the same facet, hidden behind a collapsed panel, duplicating a box that is always on screen. Filters now does what its name says: narrowing. The header does searching. `core::store::search` STAYS. Android calls it through the FFI (`search_notes`) and has its own search surface — which has the same no-tag-filter gap the web just lost, and deserves the same fix on its own terms rather than as a rider here.	2026-08-23 10:58:23 -04:00
bvandeusen	bc22f8e249	Remove [[wiki-links]], backlinks and the graph ... Operator, 2026-08-22 (note 2897): ThoughtSync is an intermediary surface. You write here because it's easy — a notebook in your pocket — and later you recall the thing and go finish it somewhere else. Recall is the product; organization is secondary. A linking system is organization, and it isn't what this is for. So: `[[wiki-links]]`, backlinks, the `[[` autocomplete, the note_links table, `/api/notes/link-search`, `/api/notes/<id>/backlinks`, the whole graph blueprint and GraphView. Rust core loses `extract_links`, `backlinks`, `link_search` and `create_titled`; the desktop loses the three Tauri commands that exposed them. This subsumes 982d24c rather than reverting it. That commit bound links to a note id so a rename would stop rewriting other notes' bodies — real infra, but infra for a feature that is now gone, and nothing it added survives. Alembic 0023 stays in the chain anyway: it shipped in an image and may already be applied, and deleting an applied revision strands a database's version pointer. 0024 drops the table and takes the column with it. The history stays honest about the fact that it existed for a day. Two things deliberately kept, because they were serving recall and only incidentally serving links: - `/api/notes/titles` and the titles store. The command palette lists them so you can jump to a note by name. `resolve()` — the name→note lookup that only linking needed — is gone. - `display_title`. Every note still has a name for search results and export filenames. What that name is FOR changed; that it exists did not. `notes/links.py` is now `notes/tags.py`, holding the #tag→label reconciliation it always also owned. A file called links.py with no links in it would have been exactly the drift this removal is meant to end. Also swept out on the way: `_escape_like`, whose only caller was link-search, and the `graph` icon. Nothing lost that a person typed — note_links was always derived, and the `[[text]]` is still sitting in every body it was written in.	2026-08-22 12:00:57 -04:00
bvandeusenandClaude Opus 5	0a7480cf9b	core: extract the store and sync engine into a shared crate (M12 step 1) ... Android becomes a native Kotlin client over this same code (Scribe note 2730), so the local store and sync engine stop being modules of the desktop app and become `thoughtsync-core`, a crate with no UI framework in it at all. This is a move, not a rewrite, and the measurement is why: every file in local/ and sync/ already carried ZERO Tauri references — 4,980 of 6,372 lines. The coupling was 473 lines of command shim, which stays behind in the desktop crate as src/commands/. Kept as git renames so history follows the files. The desktop imports them under their old names (`use thoughtsync_core::{local, sync}`) so every call site reads exactly as before. What moved is where they live, not what they are. Two things a workspace changes that are easy to miss, both caught before pushing: [profile.release] now lives at the workspace ROOT. Cargo silently ignores profiles declared by a non-root member — leaving it in the desktop crate would have dropped lto/strip/opt-level from every release build with only a warning. And a workspace shares ONE target dir, so the bundles moved from desktop/src-tauri/target to target/. Thirteen references across publish-release, debundle-graphics, verify.sh, package-prebuilt and the workflow now point there. Pinning target-dir back would have been the smaller diff, but the Android lane also produces Rust artifacts and they do not belong under desktop/. Also retires the Tauri Android lane in the same push rather than leaving a path that is being replaced: gen/android, android.yml and docs/android-dev.md are gone, the mobile_entry_point attribute with them, and the lib drops to rlib — staticlib/cdylib existed for Tauri mobile, and the .so Android loads will be built from the core crate instead. Rule 22, no parallel path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 23:12:26 -04:00
bvandeusenandClaude Opus 5	d6646a64fb	desktop: remove two dead ends from the shell, and stop the launch flash (task 1999) ... Sign out was a trap on the desktop, not an action. It nulls the synthetic local user and redirects to /login, but the offline adapter rejects every sign-in with "there's no account to sign in to" — so the only way back into your own notes was to restart the app. There is nothing to sign out of; the notes are on this machine either way. Linked devices was a quieter version of the same thing: it lists the tokens a SERVER has issued to native clients, and the desktop is one of those clients, so offline the list is always empty and issuing a token rejects. Its actual relationship with a server already has a home at /sync. Also hid the account name, which named a login the app doesn't have. /account is now blocked in the router too, not merely hidden — the mirror of the existing requiresDesktop guard — so a typed URL or a restored history entry can't reach the dead end either. Deliberately not applied to /login and /register: bouncing those on desktop would loop against the requiresAuth guard whenever a session is missing. The launch flash is the window painting before the webview does, showing the platform default white through the gap — worst on a dark-mode desktop, and widened by the software rendering we force on Linux. Set from the live system theme rather than app.windows[].backgroundColor, because that config carries one static colour and either choice would fix half of users while introducing the same flash for the other half. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-16 12:46:38 -04:00
bvandeusen	edf52da97f	desktop: the installer's channel choice now reaches the app (issue 2183) ... `install.sh --channel dev` set the channel in the installer and nowhere else. The app kept its `stable` default, stable advertises 0.1.0, and 0.1.0 is older than any dev build — so every update check said "up to date", forever, and the user had to know to go set it themselves. The installer now records the channel as a plain file in the app-data dir; the app adopts it at startup. A file rather than a write into the app's SQLite store, because shell has no business knowing that schema. Adoption compares against the value last adopted, not against "is the pref unset". Seeding only when unset would have fixed the first install and left the second silently wrong: install stable, then install dev, and the pref is already set so dev never takes. Comparing to the last marker makes both directions work — an in-app channel switch survives the next launch, and re-running the installer on a different channel is honoured. An unreadable marker is ignored rather than read as `stable`, so a truncated file can't move someone off the channel they're on.	2026-08-15 21:38:58 -04:00
bvandeusenandClaude Opus 5	d6734cf7a0	desktop: in-app updates, two channels, signed, fed by fixed-tag releases ... There was no in-place update anywhere. The app never checked, downloaded or applied anything, and the only published release predates the whole sync arc — so `install.sh` would hand out a build with no sync in it. Installing from per-run CI artifacts, which is what's been happening, is not something an updater can point at: ephemeral, auth-gated, no stable URL. Two channels, switchable in the app: `stable` follows tagged releases, `dev` follows every green push. The feed is a Fabled-Git release asset, not a ThoughtSync server route. This reverses the lean recorded in task 1998, and the reason matters — a server-hosted feed can only reach a desktop that has linked a server, and local-first-with-no-server is the whole premise. An unlinked install has to be able to update itself. Each channel reads a `latest.json` on a release whose TAG NEVER MOVES. That's forced, not stylistic: Forgejo has no /releases/latest/download/<asset> route (verified — it 404s with no redirect), so "newest" cannot be named in a URL. `dev` carries the rolling bundles; `stable` is a pointer release holding only the manifest, whose URLs aim at the versioned release's assets, so nothing is duplicated. The manifest is written by a third job that runs after both bundle jobs. They build in separate workspaces and neither can see the other's output, but one manifest has to describe both platforms — generating it inside either job would silently omit the other, and a missing platform reads to a user as "no update available" rather than as a broken feed. It reads what actually landed on the release, so it can never advertise a bundle that failed to upload. Signing is gated on the secret existing, in the script rather than an `if:` (the secrets context isn't reliably available to step conditions). No key means no updater artifacts and no publish: a feed the app would refuse to verify is worse than no feed, because it looks like it works. CI stays green until the key lands. On Linux the updater can only replace an AppImage — a deb or pacman install is owned by its package manager and must never be overwritten underneath it. The app detects that case up front and says so, instead of failing halfway through with a permissions error nobody can read. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-26 19:03:12 -04:00
bvandeusenandClaude Opus 5	c40263967d	desktop: render synced attachments instead of broken images (task 2114) ... A synced note carried the SERVER's relative attachment path (/api/notes/<id>/attachments/<aid>). In the webview that resolves against the app origin and 404s, so every synced image rendered broken even though the bytes were already on disk from M10.7d. The absolute server URL wouldn't have worked either: that route wants a bearer token the webview never sends, and it would put an offline app on the network to show a file it already has. The bytes now come off disk over a custom URI scheme, served straight from the content-addressed blob store. The webview caches and range-requests them like any other resource — which a data: URI would have thrown away — and the URL is immutable-cacheable because a content address can never describe different bytes. Two things worth knowing about the shape of this: The URL is rewritten in `load_attachments`, the single place the desktop builds an attachment for the UI. NoteCard and NoteEditor are untouched, so there's no second render site to drift. The scheme's URL form is NOT the same on every platform: `scheme://localhost/` on Linux and macOS, `http://scheme.localhost/` on Windows and Android. Getting it wrong breaks exactly one channel, silently, and a headless CI runner can never tell you. The mime rides in the URL, and this scheme is an origin of its own, so an attachment claiming to be text/html would run as a document there. Only media families are echoed back; everything else is served as an opaque download, which is the right treatment for an arbitrary file anyway. Path safety is inherited rather than re-implemented — the handler reads through BlobStore, which already refuses anything that isn't a bare sha256. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-26 17:16:44 -04:00
bvandeusenandClaude Opus 5	e64d67e904	Expire trash after 30 days, and make the deadline something you can see ... 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
bvandeusenandClaude Opus 5	ed623a7bef	M10.7d: download attachment bytes into a content-addressed store (task 2107) ... The client half of task 1942's server work. Metadata already rides the delta feed; this fetches the payload so a synced image exists on the device. Blobs are filed under their own sha256, so the same image attached to five notes is stored once and re-downloading it is free — the dedupe the task asks for falls out of content addressing rather than needing bookkeeping. The hash is also the integrity check, applied on the way IN. Bytes that don't hash to what the server advertised are refused rather than filed under a name that lies about them — and because the blob then still counts as missing, the next sync simply tries again. SECURITY: the hash arrives in a server response and becomes a FILENAME, so it is validated as 64 hex characters before touching the filesystem. Without that, a hostile or buggy server could send "../../..." and steer a write outside the blob directory. Tested. A failed attachment never fails the sync. Notes are the primary data and have already landed; aborting here would let one unreachable file block every future sync. Counted, logged, surfaced in the UI as "they'll retry on the next sync", and retried because the blob is still absent. sha2 is pure Rust, so the Windows cross-compile lane pays nothing for it — the constraint recorded in ci-requirements.md. SPLIT, deliberately: this stores the bytes but does NOT yet render them in the webview. That half needs a custom URI scheme or the asset protocol, whose URL form differs by platform (Windows uses http://scheme.localhost/, others scheme://localhost/) — and CI cannot verify webview rendering at all, being headless with no webview. Guessing at it here would ship an unverifiable change on the most fragile lane. Follow-up filed; synced images will show as broken until it lands. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-26 00:43:34 -04:00
bvandeusenandClaude Opus 5	b5f7dc2635	M10.7c: push + the full sync cycle (task 2106) ... 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	2026-07-26 00:20:09 -04:00
bvandeusenandClaude Opus 5	dc8b2d360d	M10.7b: pull the change feed into the local store (task 2105) ... Server -> local. sync/wire.rs mirrors the delta-feed JSON exactly as notes/serialize.py sends it; sync/pull.rs applies it. ATOMICITY IS THE POINT. The cursor is written in the SAME transaction as the page it describes. A cursor committed ahead of its data would skip those rows forever while reporting a clean sync — the worst kind of failure, because nothing looks wrong. A test forces a mid-page failure and asserts the cursor stayed put. Every degradation leans toward re-downloading rather than skipping: an unparseable cursor means full sync, wire fields are all defaulted so a newer server adding a field (or an older one omitting one) yields a partial note instead of a rejected page, and a page that fails rolls back whole. Labels are applied before notes so a membership never references a row that doesn't exist. A note also carries enough of its labels to materialize them, because notes and labels page from ONE shared sequence and a note can arrive referencing a label whose own delta landed in an earlier page. via_tag is applied verbatim rather than re-deriving #tags from the body. The server already reconciled them on save, and re-deriving would go through the local find-or-create path, which marks new labels dirty — pushing them straight back. Sync churn manufactured out of nothing. Duplicate-label merge, the subtle one: a label created offline can collide by name with one the server already had under a different id. Both sides enforce one label per name, so the server's row has to win — but simply deleting the local duplicate would CASCADE its note_labels away, stripping the label off notes this pull never mentions, with no later page to repair it. So we free the name, insert the server's row, re-point the memberships, then drop the husk. Tested. Children (items/attachments/previews/labels) are replaced wholesale rather than diffed: a delta carries the note's FULL state, so what arrived IS the complete set, and diffing could strand a row the server no longer has. The loop trusts the data over the flag — a server claiming has_more without advancing its cursor stops with an error instead of spinning forever. Pull can overwrite a row with unpushed local edits. The documented cycle is push-then-pull (M10.7c), so that should never happen; when it does it's counted as clobbered_dirty and logged rather than hidden. 17 tests, all against an in-memory database. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-26 00:05:27 -04:00
bvandeusenandClaude Opus 5	bbb2fd9b1c	M10.7a: link/unlink a server — device auth + sync_state (task 2104) ... The pairing step. Nothing else in the sync arc can move until this works. sync/state.rs owns the link record in the sync_state row M10.4 already put in the local schema. Two safety properties are the reason it isn't just three setters: - Linking a DIFFERENT server resets the change-feed cursor. A cursor is only meaningful against the server that issued it; carrying one across would silently skip every change on the new server below that watermark — data loss wearing the costume of a successful sync. Re-linking the SAME server (a token refresh) keeps it, so a routine re-auth doesn't force a full re-download. - Unlink clears the cursor too, so a later link can't inherit a watermark from a server that never issued it. An unparseable or absent cursor reads as 0 (full sync). That direction is always safe: a redundant re-sync costs time, a too-high cursor costs notes. Likewise a half-written row (server but no token) reports NOT linked. state::Status deliberately has no device_token field — it crosses into the webview, and a long-lived bearer token has no business reachable from page scripts. A test asserts the token never appears in its serialization. Token lives in the app-data SQLite file, not an OS keyring: the keyring crate needs libsecret/DBus on Linux, which adds a C dependency to a binary that has to cross-compile and fails outright on headless/minimal-WM setups — the same class of environment assumption behind the black-window bug. sync_link runs the M10.6 handshake FIRST and refuses an incompatible server before any credential is sent. Two credential paths, because neither covers everyone: device-login (a fresh install has no session to mint a token from) and a pasted token (some users would rather not type a password into a desktop app). A pasted token is verified against /api/auth/me before being stored — auth.py's login_required accepts bearer — since an unverified paste would turn a copy/paste slip into a failure surfacing at the next sync, far from its cause. The store lock is taken only after all network work: a std MutexGuard isn't Send so it cannot cross an await, and holding the store for a round-trip would freeze every note operation in the UI. Unlink is LOCAL only — the token stays valid server-side until revoked under Account -> Linked devices. A pasted token arrives without its device id, so a reliable remote revoke isn't possible from here; the UI must say so rather than imply a revoke that didn't happen. Follow-up filed. No UI yet — that's M10.7e. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-25 23:35:51 -04:00
bvandeusenandClaude Opus 5	4eb92942d0	M10.6: HTTP transport for the handshake (task 1995) ... Adds the client's first outbound call: GET {server}/api/config, carrying X-ThoughtSync-Client and X-ThoughtSync-Protocol, feeding compat::evaluate. Deliberately its OWN commit. This introduces the first HTTP+TLS stack into a crate that cross-compiles to Windows from Linux via cargo-xwin — the lane that has already broken once on a transitive C dependency (libsqlite3-sys needing llvm-lib). Landing it alone means a failure here has exactly one possible cause, instead of surfacing mid-way through M10.7's much larger change where it would be expensive to bisect. TLS backend is native-tls, NOT rustls, and that is the whole point of the choice: on x86_64-pc-windows-msvc native-tls resolves to `schannel`, which is pure-Rust bindings to the OS TLS stack, so nothing C or assembly has to cross-compile on the fragile lane. rustls would pull in ring/aws-lc-rs and their assembler. On Linux native-tls uses OpenSSL, whose headers ci-tauri already ships (libssl-dev, part of Tauri's own Linux prerequisites). Verified from run 2884's log rather than assumed: tokio and http are already in the Windows tree via tauri, but no HTTP client and no TLS stack were — so this genuinely is new surface there, not a no-op. probe() distinguishes "never got a usable answer" (Err) from "answered, but we can't work with it" (Ok + verdict). Those need very different messages: one is "check what you typed", the other is "update something". Transport errors are translated out of reqwest's Display, which is accurate but reads like a stack trace. Still no UI — M10.7 owns the link/settings surface that calls server_probe. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-25 22:47:10 -04:00
bvandeusenandClaude Opus 5	fbbe877c46	M10.6: client↔server sync protocol handshake (task 1995) ... Version the sync WIRE PROTOCOL separately from either program's release version, so a self-hosted server and the desktop app can sit on different releases and still work out whether they can talk. Each side declares two numbers — what it speaks, and the oldest counterpart it accepts. Either side can therefore mark a change breaking without the other shipping in step, which is the whole point: no app↔server lockstep. Server advertises on the existing public /api/config (a client must be able to ask "can I talk to you?" before it holds a device token, or even has an account): sync_protocol_version, min_client_protocol_version, sync_features. sync_features exists because a version number can only say newer/older. An ADDITIVE change earns a capability name instead of a minimum bump, so a newer client meeting an older server drops that one feature and syncs the rest, rather than refusing. Raising a minimum is reserved for genuinely breaking changes — it's the switch that hard-blocks the other side. Client half is pure decision logic (sync/compat.rs), no I/O, so every branch is unit-testable — there's no live-server lane in CI. Three outcomes: ok / degraded{unavailable} / incompatible{reason, client_must_update}. The last names which side can fix it, so the message is actionable. A server that predates the handshake sends no protocol fields at all; that reads as "update the server", deliberately not as a parse error, which would look to the user like they mistyped the URL. normalize_base_url defaults a bare host to https://, never http:// — silently downgrading would put a long-lived device token on the wire in cleartext because someone omitted five characters. Plain HTTP on a trusted LAN stays supported; the user types http:// and thereby chooses it. Transport (the actual fetch) lands next, separately: it needs an HTTP/TLS stack, and that's a real risk to the Windows cross-compile lane, so it gets its own CI run to bisect against rather than riding along with this. No UI here by design — the link/settings surface it feeds is M10.7's, per this task's own sequencing. Policy documented in docs/sync.md. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-25 22:40:25 -04:00
bvandeusenandClaude Opus 4.8	f325402902	desktop: robust startup + operation logging (portability troubleshooting) ... There was essentially no logging — useless for proving the app renders across different environments. Add real observability: - tauri-plugin-log -> stdout (so `2>&1 | tee` captures a run) AND a persistent file in the app log dir (grabbable after the fact on any machine). Level Info. - Startup diagnostics: app version, OS/arch, the Linux display/session stack (XDG_SESSION_TYPE, desktop, Wayland/X11, GDK_BACKEND), the WebKit render- hardening vars actually in effect, resolved log + data dirs, DB open/migrate result, and note/label counts. - log_event command + a frontend logEvent() helper: boot line (data source + WebKit user-agent) from main.ts, first-route config/session/destination from the router guard, and — via the bridge invoke() wrapper — every failed Tauri command named with its error, so a broken basic function is self-identifying. Task 2040. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-25 10:18:06 -04:00
bvandeusenandClaude Opus 4.8	ed1b3aa814	desktop M10.4: Rust local SQLite store + Tauri commands ... The on-device core that makes the desktop app work with no server and no login. - rusqlite (bundled SQLite, so no system libsqlite dependency to vary across builds); uuid v4 ids; RFC3339/Date.toISOString-compatible timestamps. - Schema mirroring the note model: notes, labels, note_labels (with via_tag), checklist_items, attachments, link_previews, note_revisions, saved_filters, plus per-row sync_revision/dirty + a sync_state row for the M10.7 engine. user_version-gated migrations. - derive.rs: pure [[wiki-link]] + #tag scanners (mirror the frontend inline rules, no regex dep) with unit tests; #tags re-sync via_tag labels on save, [[links]] drive backlinks at query time (derived, never stored). - store.rs: the full repository surface (facet/label/date/text list, create, PATCH-semantics update, pin/archive/color/kind, checklist items, labels CRUD + merge, reminders complete/snooze, reorder, trash/restore/delete, revisions + restore, titles/search/backlinks/link-search, saved filters). - commands.rs: ~38 #[tauri::command]s over a Mutex<Connection> in managed state. - lib.rs: opens the DB in the platform app-data dir on setup; synthetic offline config/user so the auth-gated router resolves with no login. Attachment upload / URL unfurl / import are intentionally deferred (network/file concerns); adapters/local.ts (M10.5) wires all of the above via invoke. Task 1993. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-24 22:54:58 -04:00
bvandeusenandClaude Opus 4.8	98d918dda2	M10 (task 2022, issue 2021): Arch pacman package + commit icon set (native, system libs) ... Native-first fix for the AppImage black window: a PKGBUILD that builds from source, linked against SYSTEM graphics libs, so it renders on the host driver. - desktop/packaging/arch/{PKGBUILD,thoughtsync.desktop,README.md}: `makepkg -si` installs /usr/bin/thoughtsync + .desktop + icon; deps webkit2gtk-4.1/gtk3/...; builds the frontend + `cargo build --release` (no tauri-cli). Uses the host graphics stack -> avoids EGL_BAD_PARAMETER. - Commit the icon set (desktop/src-tauri/icons/*.png, un-gitignored) so BOTH `cargo build` (pacman) and `cargo tauri build` (deb/appimage) work without a generate step; bundle.icon -> the 4 committed PNGs; drop the `cargo tauri icon` step from desktop.yml. - Broaden the WebKit software-render hardening (lib.rs) to ALL Linux (was AppImage-scoped) so the native build also renders if system WebKit is finicky. Can't CI-test the PKGBUILD (Arch-only; CI is Debian) -- operator builds locally. desktop.yml re-verifies the deb+AppImage build with the committed icons. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-24 17:02:40 -04:00
bvandeusenandClaude Opus 4.8	3f5b87682e	issue 2021: harden Linux WebKit rendering (fixes black AppImage window) ... WebKitGTK's DMA-BUF/EGL renderer fails to init on many Linux GPU/driver/Wayland setups -> 'EGL_BAD_PARAMETER' -> black window (known WebKitGTK issue, not app code). Per Tauri's Linux-graphics guidance, set the software-fallback env vars at startup before the webview is created, scoped to AppImage launches (native installs keep GPU accel): __NV_DISABLE_EXPLICIT_SYNC / WEBKIT_DISABLE_DMABUF_RENDERER / WEBKIT_DISABLE_COMPOSITING_MODE, each only if the user already set it. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-24 14:38:27 -04:00
bvandeusenandClaude Opus 4.8	877a6a572f	M10 (task 2013): integrated AppImage — app self-integration (OOBE + Account toggle) ... The Linux AppImage can now install itself into the applications menu, so it behaves like an installed app instead of a loose file. - Rust (desktop/src-tauri/src/integration.rs): integration_status / integrate_desktop / unintegrate_desktop commands — detect $APPIMAGE, copy the AppImage to ~/Applications, write ~/.local/share/applications/thoughtsync.desktop + embedded icon, update-desktop-database. Registered in lib.rs. - Frontend: withGlobalTauri exposes window.__TAURI__.core.invoke; desktop/bridge.ts (isDesktop + typed invoke, NO @tauri-apps/api dep -> web bundle unaffected); DesktopIntegrationPrompt (first-run OOBE, remembered) mounted in App.vue; AccountView "Desktop app" add/remove control. All desktop-guarded -> no-ops on web. - desktop.yml: upload the .deb + .AppImage as a run artifact (continue-on-error) so the build is downloadable for hand-testing. Verified by CI: ci.yml (vue-tsc) for the frontend, desktop.yml (cargo + tauri build) for the Rust + AppImage. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-24 13:24:20 -04:00
bvandeusenandClaude Opus 4.8	db24d7ea18	M10.2: Tauri v2 desktop scaffold (desktop/) — Vue frontend as the webview ... New desktop/ Tauri v2 project (Linux-first, cross-platform-ready): - src-tauri: Cargo.toml (lib + thin main.rs shim), build.rs, lib.rs (Builder entry point), tauri.conf.json (frontendDist -> ../../frontend/dist, devUrl :5173, deb+appimage bundles), capabilities/default.json (core:default), .gitignore. - The shared Vue 3 frontend is the sibling ../frontend; before-commands cd via "$(git rev-parse --show-toplevel)/frontend" since frontend and src-tauri are siblings, not nested. - Icons generated from frontend/public/icon.svg via `cargo tauri icon` in CI (M10.8), not committed. Boots the shared UI in a native window. The local data adapter (M10.3/M10.5) and CI build verification (M10.8) follow. desktop/** is not yet in the CI paths filter — added with the desktop lane in M10.8. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-24 11:13:09 -04:00