8 Commits

Include renames

Author	SHA1	Message	Date
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	a69159e562	fmt: rustfmt breaks the tuple-index chain, and the desktop lane means it ... `cargo fmt --all --check` failed the desktop lane on one hunk in the new `client_headers_identify_app_and_protocol` test. Clippy and every test passed; only the formatter objected. rustfmt splits `client_headers()[0].1.starts_with(..)` across lines because an index followed by a tuple field followed by a call is a three-element chain, and it will not keep one on a single line inside a macro argument regardless of width. This is rustfmt's own output, pasted back. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c	2026-08-31 14:57:07 -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
bvandeusenandClaude Opus 5	fa89da1fab	notes: color leaves the model, the wire and all three surfaces ... Step 3 of M315, and the destructive half. Steps 1 and 2 stopped every read of this field: a card is one neutral surface per theme, and the only coloured thing on a board is a tag. What was left was a column written by a picker and read by nothing. Rule 22 — the old path comes out completely. No flag, no fallback, no "override if set". Server: the column, the `?color=` facet, the create/update/serialise paths, the sync assignment, the front-matter line, and Keep's colour map. Alembic 0029 drops it and sweeps `"color"` out of stored saved-filter params — a view that silently filtered on a field the app no longer has would return nothing and never say why. That sweep is Python, not `params::jsonb - 'color'`, because Postgres has no try-cast and one malformed blob would abort a migration that is running over somebody's saved views. `NOTE_COLORS` moves from `models/note.py` to `colors.py`. A palette defined on the model that lost one is an invitation to put the column back; labels still name a colour, so the vocabulary belongs where the normalizer already is. Core: the field, the facet, the `NoteCreateInput`, and every read and write in store/push/pull. Local schema v9 drops the column and does the same saved-filter sweep, guarded on `json_valid` so a corrupt blob loses a key rather than becoming NULL. The uniffi layer drops `NoteEdit::Color` and `NoteDraft.color` with it. Web: `ColorPicker.vue`, the per-card swatch popover and its stylesheet rule, the FilterBar colour row, the facet in the query round-trip, and the colour half of the editor's baseline-and-save. Android: the `ColorSheet`, the `Picker.COLOR` case, the toolbar's swatch dot, `EditorAction.SetColor`. ## The protocol: v4, and the floor deliberately stays at 3 Checked against `compat.rs` and the push handler rather than trusting the `#[serde(default)]` annotation, because the v2 precedent points the other way: v2 dropped `kind` and `title` and DID raise both floors, on the rule that dropping a field a client sends and expects back is breaking. `color` fails the second half of that test. A v3 client reading a v4 note gets `"default"` from its own serde default and draws the colour it derives locally — the board it drew yesterday. A v3 client pushing `color` has the key ignored, since `_assign_note_fields` reads its payload key by key and never validates the shape. Neither direction errors and neither shows anything wrong. `title` was the note's NAME; this is a field that no longer renders. So `SYNC_PROTOCOL_VERSION` and `CLIENT_PROTOCOL_VERSION` go to 4, and both floors stay at 3. `docs/sync.md` carries the reasoning and the per-version history, and its push example is brought back in line — it still listed `title`, `kind` and `items`, all gone before this. Import stays tolerant: a pre-M315 export or a Keep takeout carrying `color:` imports fine, the key simply read past. Old exports must still import. #3041 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 14:07:03 -04:00
bvandeusen	668f7faf03	core: the body is the checklist, and checklist_items is gone ... M304 steps 2 and the client half of 4, together — they cannot be separated. A commit where the store writes items into the body while push.rs still reads them from a table is one that silently pushes the wrong list, and dev publishes to the dev channel on every green build. Store: * load_items becomes items_of(body) — a parse, not a query. An item's id is its ORDINAL, which is all it ever amounted to: push.rs sent text and checked and never an id, and both sides replaced the whole list on every sync. * add_item / update_item / delete_item route through update_note, so they get revision snapshotting, #tag re-derivation and the dirty/updated_at bookkeeping without any of it being written a second time. * create_note folds its items: input into the body, and syncs tags from the FOLDED body — an item can carry a #tag too. * display_title no longer takes items, because items ARE body lines now. It strips the task marker instead: a list-only note is still named by its first item, and calling that note "- [ ] milk" would show someone the storage. Wire: items leave it. A second copy of data already in the body field of the same message is how the two come to disagree. CLIENT_PROTOCOL_VERSION and MIN_SERVER_PROTOCOL_VERSION go to 3, which is what makes this safe to land before the server: a v3 client refuses a v2 server outright rather than pushing a body whose list the old _apply_note_items would then delete. Schema v8 folds every existing row into its note's body before dropping the table. Written in Rust, not SQL: the fold has to produce exactly what derive::append_item produces, and group_concat only gained a guaranteed ORDER BY in SQLite 3.44 — a checklist that quietly reordered itself during a migration would be a poor way to learn that. updated_at and dirty are deliberately left alone, because the server's migration folds the same rows the same way and both sides land on identical bodies; marking every note dirty would push a body the server already has, from every device at once. NOT deployable yet. The server still speaks v2 and still has note_items, so a client built from this will refuse to sync until the server half lands.	2026-08-24 00:41:23 -04:00
bvandeusen	6d778f26a7	Fix the ktlint and compat-test failures, and start using the Rust gate ... Two more from the step-2 removals: **Two unused Kotlin imports** — `FilterChip` (the Note/List switch) and `Icons.Filled.Create` (the "switch to a note" icon), both orphaned when their callers went. ktlint treats them as errors. **`server_info_tolerates_unknown_and_absent_fields`** pinned `sync_protocol_version: 1` as a literal, so bumping the protocol to v2 made it fail for a reason that has nothing to do with what it tests. It is about unknown FIELDS; the versions now come from `CLIENT_PROTOCOL_VERSION`, like every other test in that file already did. The bigger fix is the habit. `ci-requirements.md` has documented since 2026-08-18 that the operator authorised running fmt/clippy/test against the CI image locally, and I had not been doing it. All three now pass here — 116 tests, clippy clean, fmt clean — and every Rust failure in this milestone so far would have been caught by them in under a minute instead of by CI, several commits downstream. Noted in ci-requirements so the next session doesn't relearn it: a removal is exactly the change that looks too safe to check.	2026-08-22 14:51:38 -04:00
bvandeusen	c46a4a7709	A checklist is something a note has, not something a note is ... `kind` was never a type. A plain TEXT column with no enum and no CHECK behind it, compared against a hardcoded ("text", "list") tuple in six places; `note_items` was always an ordinary child table keyed by note_id; serialization already emitted `items` whatever the kind; and the Android editor already toggled between the two losslessly, saying so in a comment. The storage has modelled "a body plus optional checkable items" the whole time. This deletes the gates that forbade it. Every surface: the create/PATCH gates, the ?kind= filter and its saved-filter facet, the three import/export branches, the column (alembic 0025); the core's `kind` field, its SQLite column (user_version 6), the sync wire, push and pull; the FFI records and `NoteEdit::Kind`; and on Android `NoteKind.kt`, `DraftKind`, the compose sheet's Note/List switch, and the branches in the card, the editor and the chrome. The editor's note⇄list toggle becomes "Add a checklist" — on both the web and Android. It is not a conversion any more: nothing moves, nothing is swapped, the body stays exactly where it is and the note gains somewhere to put items. The card renders both, in order. Two things that fell out of the merge rather than being aimed at: - The Keep importer was DISCARDING `textContent` whenever a note also had `listContent`, because the target could only hold one. Both survive now, and the test says so. - Markdown export wrote the body OR the checklist. It writes both. Protocol goes to v2, floor included: dropping a field a v1 client sends and expects back is breaking. `title` leaves in step 3 and lands in the same generation, so it needs no further bump. This is the change that will make the 0.1.227 build on the operator's phone refuse to sync — the in-app updater is independent of the handshake and remains the recovery path. The V1 SQLite schema deliberately KEEPS the kind column. V1 is the historical schema and every later block alters it, so removing it there would make a fresh database run V1 without the column and then v6's DROP COLUMN against a column that never existed — "no such column: kind" on every new install.	2026-08-22 12:53:53 -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