117 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	c35e7fd589	cargo fmt: three chains rustfmt splits ... Formatting only. portable::instant (from F5), and the ffi's link and unlink (F2/F3), were laid out by hand without a toolchain; rustfmt splits each chain. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 14:23:57 -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	1f2ddd70d3	Unlinking a device is one flow in the core: link::unlink ... The desktop's sync_unlink and the ffi's unlink were both written out in full: try the revoke, clear the link either way, and log the outcome. link::unlink(db, held) now does that. Each client reads its link with state::credentials (with its seal) before the await and passes it in. DRY pass #2, batch 1, F3 (#5372). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 14:16:59 -04:00
bvandeusenandClaude Opus 5.5	91c47245ab	Linking a device is one flow in the core: sync::link ... The desktop's sync_link and the ffi's link_with_password/link_with_token were the same steps written out twice: probe, refuse an incompatible server before any credential is sent, log in or verify a pasted token, keep the link, and adopt the server's trash retention. link::authenticate(url, Credential) does the network half and link::store(conn, ..., seal) keeps it, sealed when the client has a seal. Each client now only reads its input and picks its seal. The desktop checks for a missing email/password before probing rather than after. Same error, sooner. DRY pass #2, batch 1, F2 (#5372). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 14:16:53 -04:00
bvandeusenandClaude Opus 5.5	70274347af	One read of a device's link: state::credentials, with the client's seal ... Five places read the server address and token straight from sync_state: sharing, autosync, sync_unlink, update's download token, and the ffi. Reading it raw is how Android came to send its sealed token to the share routes (#5381). state::credentials(conn, seal) now holds that read. With a seal it opens the token (open_token), and without one (the desktop keeps it plain) it returns it as stored. Every site calls it. DRY pass #2, batch 1, F1 (#5372). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 14:14:18 -04:00
bvandeusenandClaude Opus 5.5	be4897276c	Android sharing sends the opened device token, not the sealed one ... Android has stored its device token sealed ("sealed:…") since 8592b83, and core's sharing calls read the token from the store themselves. The ffi opened it in credentials() and then threw the result away, so every Share-sheet request went out as `Bearer sealed:…` and the server refused it. The sharing functions now take the server address and token from the caller. The ffi passes what credentials() opened; the desktop, which stores its token plain, reads it through sharing::stored_link. A new ffi test serves one request on a loopback port and checks the bearer token that arrives (#5381). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 14:05:10 -04:00
bvandeusenandClaude Opus 5.5	8592b83538	android: the device token is stored sealed under a Keystore key ... Family idea #5105, practice 12, as the operator chose on 2026-10-08: the token is encrypted, and Android backup stays on. The core: - Adds a TokenSeal trait in sync/state.rs, with set_sealed_link and open_token. - A sealed token is stored as "sealed:<value>". - A plain token, stored before this change or while sealing failed, is sealed in place on its next read. - A sealed token that won't open is dropped, and the server address and cursor are kept, so the app reads as unlinked and asks to sign in again. That is what happens after Android restores the app onto another phone. - The desktop passes no seal and keeps storing the token as before. The FFI: - Exports TokenSeal as a uniffi foreign trait (seal_token / open_token, null rather than an exception). - Requires it in Inkwell's constructor, so there is no moment a token could be stored unsealed. - Routes credentials(), unlink() and store_link() through it. Kotlin: - KeystoreTokenSeal is AES-GCM under an Android Keystore key, using the SealedBox framing from Minstrel's KeystoreSessionVault (Scribe snippet #5025), with no new dependency. - SealedBoxTest checks the framing on the JVM. allowBackup stays true, and the manifest says why. An unlinked phone's notes exist only on the phone, and the backup is their one other copy. The backup carries a token nothing can open. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 10:23:22 -04:00
bvandeusenandClaude Opus 5.5	97b04f9f92	Close the gaps family idea #5103 found in how Inkwell distributes its app ... Three of the idea's practices this project still owed (Scribe #5118): Practice 3, CI fails on the wrong signer. The signing step printed the certificate and went on. It now fails unless the APK has exactly one signer and that signer is the release certificate (SHA-256 408a5835…, pinned from run 8753). The steps that publish come after it in the same job, so a wrongly signed build is never staged or published. Practice 6, app downloads are throttled and carry a sha256 ETag. - The download route counts per account and answers 429 with Retry-After past the limit. The limit is a new Settings → Security value, "App downloads per account per hour" (default 30), live like the sign-in limits. - The ETag is the sidecar's sha256, not Quart's mtime-and-path, so a phone resuming a download across a redeploy is not told its partial copy is stale. Quart's own ETag and conditional handling are off, and the route runs the conditional pass after setting the ETag, so Range and If-Range are judged against the content. Practice 9, the update offer and debug builds. - The install-permission notice re-reads the grant each time the app comes back, as ReminderNotice does. Read once, it stayed up after someone granted the permission in Settings and came back. - A debuggable build says it can't update itself and checks for nothing. Android would refuse the release-signed APK over a debug signature anyway. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 09:21:40 -04:00
bvandeusenandClaude Opus 5.5	f0ce5687cc	android: build the signed APK's Rust with the release profile ... Every APK so far carried a debug-profile libinkwell_ffi.so (opt-level 0), because the workspace's release profile sets strip = true, which removes the symbols uniffi's --library mode reads the interface from (run 4077). The cargoNdk task now builds --release with two environment overrides, for this build only: - CARGO_PROFILE_RELEASE_STRIP=debuginfo keeps the symbol table. A release build has no debug info, so this keeps symbols and nothing else. - CARGO_PROFILE_RELEASE_PANIC=unwind keeps a core panic reaching Kotlin as an exception, which the board shows as an error, not an app exit. Phones have always had unwind, because debug unwinds, so this keeps what they do. Overrides rather than a profile of our own because cargo-ndk copies its -o output from the release directory, and nothing says it handles another. The desktop's binaries are unchanged. android.yml passes release on the signed path; the unsigned debug path keeps debug. Scribe #2810. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 08:39:36 -04:00
bvandeusenandClaude Opus 5.5	87725ecab7	android: search narrows the board in view, and combines with its filters ... As on the web, the search box is now one more facet on the board you are looking at, rather than a separate unfiltered search. "These words, in notes tagged grocery" works: on the main board the text is sent to the core together with the Filters sheet's tags, attachment and shared switches, and the core ANDs them in list_notes. Archive, Trash and a tag's view take the text alone. A search typed on Reminders, which is not a board view, moves to the main board, as the web does. The Filters chip stays while you search; it was hidden before, on the mistaken claim that the web hides its filters too. Drag-to-reorder stays off during a search, since a filtered subset can't be renumbered against notes it can't see. store::search and the FFI's search_notes had no other callers, and are removed. They also searched archived notes and ignored pinning, which the board's query does not. Scribe #2942. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 08:19:50 -04:00
bvandeusenandClaude Opus 5.5	5fa261cea7	android: hold Coil at 3.5.0, the last release that builds on compileSdk 36 ... Run 8731 failed checkAarMetadata: Coil 3.6.x requires compileSdk 37, and it pulls in Compose 1.12, which requires AGP 9.1. This project is on compileSdk 36 and AGP 9.0.1. Coil 3.5.0's AARs ask for 36, and its Compose (JetBrains 1.11.1) is within this project's BOM (Compose 1.11.2). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 07:59:09 -04:00
bvandeusenandClaude Opus 5.5	a213e2e186	android: link preview cards show the page's image, as on the web ... The card draws the linked page's og:image in a strip down its left edge, cropped to the card's height: 96dp full, 48dp compact, matching the web's w-24 and w-12. The image is remote, so the phone fetches it from whatever host the link points at, exactly as a browser does for the web card. The operator chose that parity (Scribe #3307). The image is Coil 3's AsyncImage, with OkHttp as its fetcher. Coil's disk cache means a card scrolled past twice costs one download. When there is no image, or it fails to load, nothing is drawn rather than an empty box, and the card is the text card it was before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 07:47:26 -04:00
bvandeusenandClaude Opus 5.5	802eab4ef9	android: bring BoardScreen and NoteCard back under detekt's complexity limit ... Run 8693's detekt failed both on CyclomaticComplexMethod (17 and 15 against 15) after the filters and drag-to-reorder landed. - BoardState now carries `filterable` and `reorderable`, so the board's rules for when the filter row shows and when a card can be carried live with the state they read instead of as boolean chains in the screen. - NoteCard's contents (tags, body, links, attachments, reminder, sharing) move to their own CardContents composable, leaving NoteCard the gestures, the frame and the menu. No behaviour change. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-07 23:38:37 -04:00
bvandeusenandClaude Opus 5.5	3b4fe310b8	android: the board's Filters and drag-to-reorder, as on the web ... Filters: a chip under the search bar opens a sheet with Has attachment, Shared with me and tags (a note must carry all of them), applied as they are tapped, with a count on the chip and a Clear beside it. Only the main board filters and search spans everything, as on the web; opening another view starts it unfiltered, a deleted tag drops out of the filters as it does from the lens, and an empty filtered board says so. Reorder: hold a card, then move it. The hold is the long press that opens the card's menu, which closes as the card starts to move; lifting without moving leaves the menu as before, and moving before the hold is a scroll. Cards trade places live and the drop writes the order through the core's reorder, newly exposed over the ffi as reorder_notes. Only on the plain main board, and only on the same side of the pinned line, since the store sorts pinned first. #5313. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-07 23:28:22 -04:00
bvandeusenandClaude Opus 5.5	82aa5ba7b6	android: wrap the board's column choice the way ktlint wants ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-07 21:48:15 -04:00
bvandeusenandClaude Opus 5.5	d6757fc0fc	android: the board takes three and four columns on a wide window, as the web does ... The board was Fixed(2) at every width, so a tablet showed two wide columns where the web shows three or four (#5311). The column count now follows the web's NoteGrid breakpoints on the window's width: three from 1024dp, four from 1280dp. A phone keeps two. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-07 21:36:41 -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	888c6410f0	all: trim the history essays out of the longest comments ... From the audit (#5179). Ten comment blocks narrated how the code got here: milestone numbers, earlier values, the operator's verdict on an old design. Each now says what the code does and why, and the history stays in git, Scribe and docs/sync.md. The protocol-version comment in sync.py points at docs/sync.md's policy section, which already lists every bump. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-07 20:03:44 -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	fd1d50662f	android: share a note with a group ... The Share sheet lists groups after people, shows a group share as its name and how many are in it, and shares through the FFI's ShareTarget. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-07 18:25:16 -04:00
bvandeusenandClaude Opus 5.5	4f5459cb94	android: pin and archive a note someone shared with you ... The card's long-press menu and the editor's overflow now open on shared notes with Pin and Archive; Labels, Share and Move to trash stay the owner's. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-07 17:13:58 -04:00
bvandeusenandClaude Opus 5.5	5e8c6dc7bf	android: detekt — check the link before loading shares, and NoteAccess gets its own file ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-07 15:52:21 -04:00
bvandeusenandClaude Opus 5.5	2e7db21b21	android: share a note, and read or edit one shared with you ... The editor's menu has Share…, which opens a sheet of who the note is shared with and lets you add someone at view or edit, change it, or stop sharing; unlinked, it says sharing needs a server. A note shared to view opens read-only; at edit only its text can change. Cards say who shared a note ("From Robin") or that yours is shared, and a view-only note's boxes don't tick. Also: two core store tests used unwrap_err on a Result<Note>, which needs Note: Debug; they use err().expect() now. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-07 15:42:30 -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	ac4427f834	android: shows and attaches files, and the share sheet takes images ... The phone downloaded every attachment and drew none of them, so a photo note looked empty. Now: - Cards show a note's first image and name its other files; the editor shows every image at full width and every file as a row. Tapping one opens it in whatever app handles its type (a cache copy under its real name, through a FileProvider that serves only those copies). Each can be removed, and a file the server refused says why under it. - The editor's toolbar has an Attach button (any type, several at once). Files are stored on the phone straight away and upload on the next sync that reaches a server, through the core's step-6 path. Link previews show in the editor too, and can be dismissed. - Share → Inkwell accepts one or several images, with or without a caption, finishing #1899's deferred image/* target. - The FFI gains add_attachment, delete_attachment, delete_preview and blob_path. The sync summary counts uploads and failed uploads. Images decode at the size they are drawn (BitmapFactory sampling plus EXIF rotation, small LRU cache), so no image library is added. Files over 50 MB are refused on the phone before they are read whole into memory. Task #5169. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-07 10:59:36 -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	535331c5b2	tests: one fixture for the note grammar, run by the core, the server and the web ... The checklist grammar and the #tag rule are implemented three times (derive.rs, checklist.py/tags.py, markdown.ts), and the tag colour twice (colors.ts, DerivedTint.kt). Only Rust and Kotlin had tests. core/testdata/grammar.json now holds one set of cases (task lines, rendered items, tags, standalone-tag lifts and the tint hashes), and every suite reads it. - web: vitest, a dev dependency approved for #5166, with `npm test`. grammar.test.ts runs the fixture, and titles.test.ts pins #5165's palette fix. - ci.yml runs the web tests in the job the image build needs. desktop.yml's verify job runs them too, because the installers embed this frontend and can't see ci.yml's verdict (rule 177). - core: derive.rs reads the fixture. server: tests/test_grammar_fixture.py. - Android keeps its hand-written tint values; its doc now points at the fixture. The server is expected red here, on purpose. tags.py only takes a tag after whitespace and lets it start with a digit or `_`, while the core (the definition) takes any non-tag boundary and needs a letter. So `(#todo)` is a label on the phone and plain text on the server. The fix follows. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 23:11:26 -04:00
bvandeusenandClaude Opus 5.5	81cd719327	rename: Android is Inkwell — package, applicationId, uniffi class, assets ... Step 4 of milestone 481 (Scribe note 5071: a full rename). - namespace and applicationId com.fabledsword.inkwell; the Kotlin package moves with them, and ktlint re-sorted the imports the rename reordered (checked locally with CI's ktlint 1.4.0 and detekt 1.23.7, both clean) - uniffi: class Inkwell in com.fabledsword.inkwell.core, InkwellApplication, InkwellTheme, Theme.Inkwell, log tags, prefs and work names, client agent inkwell-android - the lane publishes inkwell.apk / inkwell-android.json; fetch-clients, guard-forward, publish-release and write-manifest read the same names A new applicationId is a new app. The old ThoughtSync app keeps its own store and stays installed beside it. Notes cross over by syncing, and the old app is then removed by hand. Kept: the signing keyAlias is still "thoughtsync". It names the key inside the existing keystore, and the key, and so the certificate, are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 14:34:02 -04:00
bvandeusenandClaude Opus 5.5	256fba3610	icon: Inkwell's mark is a black inkpot and quill on the brand yellow ... Step 5 of milestone 481. Replaces the linked-notes constellation, which had been stale since note links were dropped (alembic 0024). The colour scheme stays. packaging/icons.py draws the mark once and renders every variant from it: the rounded tile (web, desktop), the maskable full-bleed web icon, and the Android adaptive foreground. The detail (shaft, vane splits, glint) is cut out of the ink with a mask rather than painted on in yellow, because the Android foreground is now transparent and its alpha is also the themed-icon silhouette. The old foreground was the opaque maskable tile, which a themed icon would have drawn as a solid square. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 14:30:51 -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	cf2854a029	ktlint: a multiline .border() left the next '.' orphaned, exactly as #3110 records ... `standard:chain-method-continuation` on `LinkPreviewRow.kt:83`. The `.border(…)` call took three arguments across four lines, and the `.padding(…)` after it then began a line with a `.` — which the rule only accepts glued to the closing paren, `).padding(…)`. Issue #3110 hit this same rule in `NoteCard.kt` and recorded the fix: do not write the multiline element. Naming `shape`, `padH` and `padV` first collapses `.border` back to one line and removes the duplicated RoundedCornerShape at the same time, which is better than what ktlint was willing to accept. Also did what #3110's verification note says to do rather than fixing only the line the linter named: scanned every Kotlin file this branch touched for the same shape — a multiline chain element followed by a `.` on a new line — and found no others. ktlint reports one violation and stops, so a second would have cost another full Android lane. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c	2026-09-01 19:01:09 -04:00
bvandeusenandClaude Opus 5	62338bb0a4	android: a link in a note renders as a link card, not a bare URL ... The web and desktop have shown link previews since #2898; the phone showed the raw address. The data was already on the device — `Note.previews` is populated by the core and carried through the FFI — and nothing under `app/src/main` read the field. The three presentation rules are copied from `NoteCard.vue` rather than re-decided, so the same note reads the same way on every surface: * A note that is NOTHING but a URL renders as its preview and nothing else. Printing the address under a card that already says where it goes is saying the same thing twice, badly. * Links mentioned INSIDE a note get a compact strip at the FOOT of the card. Above the body would put a stranger's headline where the note's first line should be; the web learned that in M13. * Several stack. `LONE_URL` mirrors the web's `LONE_URL_RE` including the tolerated whitespace — if the two regexes disagree, one note reads as a card here and a paragraph there. Falling back to the URL is deliberate in all three of the cases that produce no preview: not a lone URL, not unfurled yet, or never unfurlable. A note written on the phone and not yet synced is permanently in the middle one, because the unfurl is server-side (`unfurl_queue.py`) and arrives on a later pull — so that state has to look deliberate, and showing the link does. No unfurl fetch was added here, and none should be: a phone fetching OG tags would be a second SSRF-hardened fetcher on the surface least able to afford the call. ## No image, and that is a question rather than an omission `LinkPreview.image_url` is a REMOTE third-party address — the web renders it straight from whatever host the link points at. Matching that here would have this app fetch images from arbitrary hosts, on a phone, on possibly metered data, and would make it the first image loading anywhere in this client: there is no loader, no cache, and not one `Image(` in the whole app today. That is a decision about privacy and data use, not a rendering detail, so the text card ships and the image is asked about rather than assumed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c	2026-09-01 18:51:51 -04:00
bvandeusenandClaude Opus 5	1a41373347	board: a note trashed from search results now leaves the results ... Search for something, long-press a hit, Move to trash: the snackbar said it happened and the card sat there until the query next ran. Reachable from the editor's overflow too — both go through `mutate`. `mutate` kept the existing list whenever a search was running, with the reasoning recorded in place: search results are the answer to a query, not a live view, and running the BOARD query underneath them would replace the hits with the whole board. That is right about the board query and wrong about the note. A hit that no longer matches has left the answer, not just moved within it — pinning one and watching it not re-sort is fine; trashing one and watching it stay is not. So the search is re-run instead of the destination loaded. The results are still the answer to the query, just a current one, and it costs one local SQLite query — the same argument the surrounding comment already makes for reloading the board. Creating a note while searching still leaves the list alone: a new note that does not match the query has no business appearing in its results. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c	2026-09-01 18:51:51 -04:00
bvandeusenandClaude Opus 5	c8318c323a	android: Share → ThoughtSync, and a "New note" entry in the selection toolbar ... Capture without opening the app first — the input half of #1899. Two ways in: the share sheet from anywhere, and the text-selection toolbar in any app's text field. ## The note is created, not pre-filled The obvious build is "open the editor on a draft holding the shared text". That silently loses it. `NoteEditorScreen`'s flush is guarded by `bodyText != note.body`, so a draft handed the text already has nothing to save — share a link, press back without typing, and it is gone. Which is exactly the shape of a share: the common case is walking away. So `captureShared` makes the row first and opens the editor on the real note. A share has already said "keep this"; creating it is what honours that, and back then leaves a saved note rather than a decision. ## launchMode="singleTop" The reminder notification adds FLAG_ACTIVITY_SINGLE_TOP to its own intent, which is why `onNewIntent` already worked there. A share intent is built by the OTHER app and nothing here can add a flag to it, so the activity has to declare it. Without that, every share while the app was running would stack a second MainActivity — a second view model, a second board, and a back press landing on a stale copy of the same app. ## Subject and text, both A browser sends EXTRA_SUBJECT as the page title and EXTRA_TEXT as the URL. Keeping both makes the note read as its title, because the core names a note by its first line — the difference between a board you can scan and a column of identical links. `distinct` because plenty of senders put the same string in both. The extras are removed on read, like the reminder's note id and for the same reason: the activity keeps its launch intent, so without consuming them a rotation would replay the share and mint the note again. ## Not included: images `image/*` is deliberately absent from the filter. Nothing in this app can create an attachment — the core has `delete_attachment` and no counterpart, and the FFI exposes neither. Declaring the mime type would put ThoughtSync in front of people in the share sheet for a job it cannot do, and fail after they had already chosen it. Adding it needs an attachment-creation path through the core, the FFI and sync, which is its own piece of work. The desktop half of #1899 — a global hotkey — is not in this commit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c	2026-09-01 08:53:38 -04:00
bvandeusenandClaude Opus 5	cc50812a86	ktlint: the Tags imports landed after SyncScreen, and SyncState sorts after that ... `standard:import-ordering`. The two new imports were inserted by anchoring on `com.fabledsword.thoughtsync.ui.SyncScreen`, which looked like the right neighbour and is not — `SyncState` and `SyncViewModel` both sort after it, so Tags* wedged into the middle of the Sync block. Moved below `SyncViewModel`. Every import block in the five files this branch touched is now confirmed sorted, not just the one ktlint happened to reach first — it reports one violation and stops, so a second would have cost another full Android lane. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c	2026-08-31 19:53:08 -04:00
bvandeusenandClaude Opus 5	1e54b80f15	android: a Tags screen, so the phone can do more than attach tags to a note ... Android could list tags and mint new ones. It could not rename, recolour, delete or merge one — and since the per-note colour picker was removed with 2949, tag colour is the ONLY colour control in the product, which meant an Android-only session had no way to change any colour anywhere. A destination reached from the drawer, not a modal. The web's LabelsModal is a modal because a desktop can float one over the board; on a phone this is a place you go to tidy up, and a full screen is what that is. The manage entry is an action ON the drawer's Tags header rather than a row in it, so it cannot be mistaken for a sixth lens. The header now renders even when there are no tags: this screen is where you make the first one, and hiding the way in until one exists is a door that only appears once you are already inside. ## The two calls this needed RENAME and MERGE deliberately do not follow the same rule, and the screen says so rather than hiding it. * A rename that lands on an existing name merges, older survives (3324). That path is accident-prone — it is a text field, and a typo reaches it — so it needs a rule that cannot depend on which way round it was typed. The screen catches the collision against the LIST, not from what the core returns: the survivor may be the tag being renamed, so an unchanged id afterwards proves nothing. Then it asks before merging. * An explicit merge keeps its direction. Here the person is choosing, and the direction IS the intent — folding #grocery into #groceries is a decision, and overriding it with age would refuse the thing they asked for. The price is that the direction has to be unmissable, so the body names the tag that stops existing and every row offered is the survivor. Delete quotes the note count, because "it is on 40 notes" is a different decision from "delete this tag?". The count comes from `list_labels`, the only call the core populates one on. It also says that a tag written as #tag in a body comes back on that note's next edit — deleting the row cannot un-write the word, and that is better said than discovered. ## The board had to learn something `Destination.WithLabel` holds an id, and deleting or merging a tag the board is currently LOOKING at would strand it on a lens that queries a row which no longer exists — permanently empty, escapable only via the drawer. So `loadLabels` became `refreshLabels`: public, and it drops back to Notes when the current lens is gone. A failed listing deliberately does NOT trigger that fallback — "I could not read the tags" is not evidence that this one went. Reused rather than rewritten: `ErrorBanner` (the board and editor already share it), `MenuItem` from Panel.kt (it closes the menu before acting so a dialog cannot open under a hanging menu), `PlainTextField`, and the `NOTE_TINTS` palette — the screen consumes it and does not fork a copy. `default` stays in the palette on purpose: a tag with that colour gets a hue derived from its name, so it means "let it pick", and removing it would leave no way back to that. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c	2026-08-31 19:44:54 -04:00
bvandeusenandClaude Opus 5	550a34d8e2	fmt: rustfmt budgets macro arguments at 60 chars, not the 100-char line ... Both new assertions fit well inside the 100-column limit and both were still rejected. The governing setting is `fn_call_width` (60), applied to a macro's argument list: `survivor.id, older.id, "the older row is the one that survives"` is 62 characters, so rustfmt breaks it and pairs the two values on one line with the message beneath. The neighbouring `assert_eq!(survivor.name, "Grocery", "spelled the way the caller asked")` was accepted at 59 characters of arguments, which is the same rule agreeing rather than a different one. rustfmt's own output, pasted back. Second time this lane has caught the same class of thing in one session — the other was a method chain, budgeted at 60 by `chain_width`. Recorded so the next person reaches for the 60, not the 100. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c	2026-08-31 16:52:00 -04:00
bvandeusenandClaude Opus 5	193dfb9e94	tags: renaming onto an existing tag merges them, and the older row survives ... The three surfaces did not agree on what renaming a tag onto a name another one already holds should do, and none of the three answers was good. I described this wrongly first time and the correction matters. The local store does NOT silently create a duplicate: `idx_labels_name` is unique on `lower(name)`, so the bare UPDATE in `rename_label` failed, and the user got a raw SQLite "UNIQUE constraint failed" as their error message. The server meanwhile answered 409 "a tag with that name already exists" — and only on an EXACT match, because its constraint is on the raw name while every client's index is on `lower(name)`. That last part is the sharper bug. The server would happily hold "Groceries" beside "groceries"; no synced client can store both. Creating that pair on the web armed a pull that fails later, on a phone, in a path with no UI. Operator's call: a rename onto an existing name means merge — typing an existing tag's name onto this one says they are the same thing. * `store::rename_label` and the server's PATCH now implement one rule. THE OLDER ROW SURVIVES and takes the new spelling. Age rather than "the one that already held the name", so that renaming A→B and B→A land on the same survivor; otherwise the outcome depends on which way round someone typed it, and two devices tidying the same pair disagree about which id still exists. Ties go to the incumbent, so it stays deterministic. * The core reuses `merge_labels` rather than reimplementing the move. That is the only place that knows to mark every affected NOTE dirty before the delete cascades the membership rows away, which is what makes a merge reach the server at all. * The server's rename and its `/merge` route now share one `_merge_into` helper, for the same reason. * Both server lookups became case-INSENSITIVE, matching every client. The create path is included: it was the one actually minting the unstorable pair, so fixing only the rename would have left the door open. * The web asks before merging, naming both note counts. A merge cannot be undone by repeating it and is now reachable by a typo in a text field — the same reasoning as the delete confirmation in #2116. The confirmation lives in the shared store, so the desktop gets it too; the FFI does not ask, because that belongs to the surface with a person in front of it. * The web store detects the merge from the LIST, not the response: the survivor may be the row we asked to rename, so an unchanged id proves nothing. Tests: three integration tests over a real database (both rename directions land on the older row; a case-varied create returns the existing tag) and two through the Android FFI, which is the binding the phone will use. Also fixes a straggler from 8c7553d — the delete confirmation still said "the label". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c	2026-08-31 16:46:15 -04:00
bvandeusenandClaude Opus 5	8c7553d619	copy: the product says "tags" now, and the schema keeps saying Label ... Two words for one concept cost real comprehension: over a single exchange the operator concluded that auto-tagging did not exist (it does, in `derive.rs`) and that a tag-management view did not exist (it does, `LabelsModal.vue`). The `#` is how most of these get made, so the `#` wins the noun. User-visible strings only, on all three surfaces plus the server's errors. `Label`, `NoteLabel`, `via_tag`, `label_id`, the tables, `/api/labels` and the FFI names are all untouched — renaming those touches migrations and the wire format to buy nothing a reader can see. Two of these were more than a find-and-replace: * Android's `label_from_tag` said "from #tag", sitting beside a chip that already renders as `#name`. Once every one of them IS a tag that hint is circular. What it actually tells you is that the note's BODY owns this one — which is why it alone has no remove cross — so it now says "from the text". * The web's empty state said "No labels yet — create one above" while Android's already mentioned the `#` route. The web now says it too. That is the exact fact the operator did not have. The paired `aria-label`s went with their `title`s; a screen reader saying "label" while the tooltip says "tag" is the same confusion with a smaller audience. Left alone deliberately: `json_error("invalid label")` and `"label_ids must be a list"` in `notes/__init__.py` name the `?label=` query parameter and the `label_ids` request field. Those are wire surface, not the word a person reads. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c	2026-08-31 15:53:28 -04:00
bvandeusenandClaude Opus 5	d838b27518	ffi: Kotlin could list and create a tag but never rename, recolour, delete or merge one ... `core/src/local/store.rs` implements all seven label operations. The uniffi object exposed three of them, so Android could attach tags to a note and mint new ones, and could do nothing else with them ever. The four additions are pure passthrough, because reading the store showed both of the things #2963 said to check rather than assume are already handled there: * The note count exists. `Label` carries `count: Option<i64>` and `list_labels` computes it per row, excluding trashed notes — which is the number a delete confirmation should show. The single-label returns all end in `load_label` and leave it `None` on purpose, so a screen must read counts from the LIST and never from an operation's result. * Sync is free. `rename_label` and `set_label_color` set `dirty = 1`; `remove_label` records a pending delete; `merge_labels` records one for the source AND marks every note that carried it dirty before the delete cascades the membership rows away, because push sends `label_ids` per note. So no store change, no sync change, no count plumbing — the binding only. One divergence found and documented rather than fixed: renaming a tag onto an existing name is a 409 on the server (`labels.py:94`) and a silent duplicate in the local store. The desktop has always had this, calling the same `store::rename_label`; Android now inherits it. Deciding which side is right belongs with the screen (#2964), not with the binding. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c	2026-08-31 15:52:00 -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
bvandeusenandClaude Opus 5	b7e0e5dbba	ffi: two items: lines left at the indent of the field above them ... `cargo fmt --check`. Deleting `color:` from these two NoteDraft literals left the line after it one level too deep — the sort of thing a formatter exists to catch and an eye does not. #3041 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 14:23:10 -04:00
bvandeusenandClaude Opus 5	e14d9d340a	core: the v9 test pinned v8, and a blank line ktlint counted ... Two CI failures from the colour removal, both mine. `a_fresh_database_reaches_v8` asserted the version the migration no longer stops at. Renamed to say what it actually guards — the LATEST version — so the next migration updates a number instead of a name that has quietly become wrong. While there, two tests the migration deserved and did not have. One asks SQLite whether `notes.color` is gone rather than reading a row back, because a SELECT that omits the column passes either way; it also asserts `labels.color` is still there, since getting that wrong would take every tag's colour with it. The other seeds three saved views and checks the sweep: one loses its colour key and keeps its query, one without the key is untouched, and one holding text that is not JSON at all comes out unchanged rather than NULL. Writing that third case is what found a real bug in the migration. The guard was `json_valid(params) AND json_extract(params, '$.color') IS NOT NULL`, which is the obvious way to write it and is a trap: SQLite does not promise to short-circuit AND, so `json_extract` can be evaluated against the very rows `json_valid` was there to exclude — and on malformed input it does not return NULL, it RAISES, which would have aborted the whole migration over one corrupt blob. It is a LIKE now, which is total over any text. The ktlint failure is a doubled blank line where `EditorAction.SetColor`'s branch used to be. #3041 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 14:15:33 -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
bvandeusenandClaude Opus 5	13a88179b8	tags: one ink, chip and inline, and the chip edge solved for 3:1 ... Step 1 left one card surface per theme, so the tag ink is no longer choosing a value that has to clear twenty backgrounds. Re-measured against the one it actually lands on, the two tables collapse into one. `-800` in light, `-300` in dark, for a `#tag` in the prose AND for a chip's text. Dark needed no decision at all — the two tables already held the same value for all ten hues, which is most of the argument on its own. Light collapses onto the INLINE column deliberately: since M311 a tag whose text is in the body is drawn where it was typed and not repeated as a chip, so inline is the common case and this leaves what is seen most exactly as it was. The chip is strictly better for the move: inline, on the card as a chip, on its own fill light `-800` 7.09 - 15.13 6.37 - 12.01 (was 4.52 - 8.23) dark `-300` 9.45 - 14.23 8.23 - 11.88 (unchanged) The chip edge goes 0.60 -> 0.65, and this is the first time that number could be solved rather than judged. 0.60 was picked against a chip sitting on a card of its own colour, a case that no longer exists; against a known fill the smallest alpha clearing the 3:1 of WCAG 1.4.11 for all ten hues is arithmetic. 0.60 gives 2.75-3.82 and misses for six of them, 0.65 gives 3.03-4.36 and misses for none. Dark runs 4.52-5.76. That edge is doing more work than it looks: a chip's fill measures 1.02-1.26 against the card in light and 1.02-1.73 in dark, and dark red at 1.02 is invisible. The ring is the pill; the fill only tints it. `LABEL_CHIP_CLASSES` becomes `LABEL_CHIP_SHELL` — fill and edge, no ink — and `labelChipClasses(label)` composes shell and ink in one place. The board and the editor each had their own copy of that composition, with a comment on one of them asking the other to stay in step. Now it is one call. Fixed on the way past: the web drew `default`'s chip ring at `black/10` (1.36 against its own fill) where Compose derived it from the ink (3.21) — the same chip, visibly different pills. Both are the ink at 65% now. `chipForeground` stays, narrowed to what it always actually was: the REMINDER pill's ink, transcribed from NoteCard.vue's literal red-700 / neutral-600. It is not a tag and must not move with one. Also gone: `NOTE_NODE_FILL`, a per-hue table of solid hexes for graph nodes with no consumer anywhere in the repo. Step 2 of M315. #3149 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 13:13:43 -04:00
bvandeusenandClaude Opus 5	b91091caca	cards: one neutral surface, and the generated fill deleted with it ... A card's fill stops being a function of the note. One neutral per theme on all three surfaces — white in light, neutral-900 in dark, which is what the palette's `default` always was and what both editors already used, so this is a collapse onto a surface everything already had rather than a colour anybody has to like. Measured, against "not the same color as their background but close to it": card vs board 1.04 light / 1.10 dark, edge vs card 1.98 / 1.73, body text 17.93 / 17.17, muted 10.37 / 14.23. The fill is deliberately the weakest number on the card — the edge and the shadow separate it from the board, so a fill that separated on its own would make it a panel. Deleted, since the card was their only consumer: `derivedFill` / `hslHex` and the level tables in colors.ts, `derivedFillArgb` / `hslToArgb` in DerivedTint.kt, `NOTE_CARD_CLASSES_STRONG`, `chosenNoteColor`, `noteCardClasses`, `noteTintVars`, the `.note-tint` rule in style.css, `chosenBackground` / `tintable` / `noteTintFor` / `noteCardColor` / `noteIsStrong` / `firstLabelColor` in NoteTint.kt, and `resolvedNoteColor` / `noteColorIsChosen`. `tintHash` and `derivedTint` STAY, against the plan: a label with no colour of its own still derives one from its name, and that path was never the one that failed. The mirrored pair and its fixture survive intact. The editor follows the card, and its Done button takes the brand — the board's compose FAB is the app's existing statement of "affirmative action here", where Material's default secondaryContainer is a baseline colour this theme never sets. The colour picker is left in place, doing nothing, for exactly one step: removing it here would leave `note.color` written by nothing and read by nothing, which is a worse intermediate than a control that visibly does nothing. #3041 takes the field and the picker together. Step 1 of M315. #3148 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 10:55:51 -04:00
bvandeusenandClaude Opus 5	f50204a98b	editor: detekt counts returns, so the promotion guards collapse into one ... `promotingTasks` had four returns against ReturnCount's limit of two — three of them the same `return this`. Collapsed into a null-or-task guard and a `changed` flag, which says the contract more plainly anyway: the list comes back untouched unless something was actually promoted. Mirrored in blocks.ts even though nothing lints it there. The two files are kept line-by-line alike on purpose, and letting them drift on shape is how the next person stops trusting that reading one tells you the other. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 12:59:15 -04:00
bvandeusenandClaude Opus 5	1a49ae7ea9	editor: a - [ ] typed by hand becomes a real item when you leave the line ... `splitBlocks` runs once, when the editor opens. After that the blocks ARE the state and nothing reads the body again — every edit travels the other way, through `joinBlocks`. So a marker typed by hand stayed literal text on screen until the note was closed and reopened, even though it was already a real item in storage and the card was already drawing a checkbox for it. The editor was the only place that disagreed with itself. (#3024) On BLUR, and only the block being left. There is no good moment to convert while someone is typing: re-splitting on a keystroke moves the caret out of the word being written, and converting the instant `- [ ]` is complete does it before the item has any text. Blur is the one moment the person has demonstrably finished with the block. `promotingTasks` / `promoteTasks` return the SAME list when there was nothing to promote, and both call sites compare by identity. Without that, every blur would re-key every field below it — including the blur that fires on first composition, before a field has ever held focus. Both surfaces in one commit, deliberately: blocks.ts is a line-by-line mirror of EditorBlock.kt, and the reason that mirror is worth keeping is that the two editors behave identically. Fixing one would spend its whole value. Non-canonical markers (`- [X]`, an odd bullet) come back canonical — the only case where this changes the body rather than just how it is drawn, and exactly what reopening the note already did. No unit test: `splitBlocks` reaches the core over uniffi for the grammar, so it needs the native library and cannot run in the JVM lane. No existing Android test touches the core for the same reason. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 12:50:43 -04:00