131 Commits

Include renames

Author	SHA1	Message	Date
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	09239ee3c7	web: the app's type-check leaves the unit tests out; CI checks them separately ... Run 8478 passed every test lane and then failed `Build & push image`. The Dockerfile's frontend stage copies only frontend/, and `npm run build` type-checks with tsconfig.json, which covered grammar.test.ts. Its import of ../core/testdata/grammar.json doesn't exist inside that stage. Nothing was published: the build is the publish and it stopped. tsconfig.json now excludes `*.test.ts`. The new tsconfig.test.json extends it with the tests included, and ci.yml's typecheck lane runs that one, so the tests are still type-checked before anything ships. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 23:34:14 -04:00
bvandeusenandClaude Opus 5.5	38da5160a0	grammar: a #tag starts after whitespace and with a letter, on every surface ... The shared fixture went red on the server (run 8468: 5 failed), because the three tag rules disagreed: - core and web: any non-tag character counts as a boundary, so `(#todo)` and `end.#tag` are tags, and so is the `/#section` of a pasted URL; - server: only whitespace counts, but `#1st` and `#_x` are tags. A note's labels could therefore change every time it synced. All three now share the strict rule: start of line or whitespace, then a letter, then letters, digits, `_` and `-`. Nothing becomes a tag that wasn't already one everywhere, and URL anchors stop becoming labels on desktop and Android. The server's existing `http://x/#nope` test already expected this. derive.rs's boundary, markdown.ts's lookbehind and tags.py's regex change together; `_is_tag` goes because the regex now requires the letter. The fixture flips `(#todo)`, `end.#tag` and its lift case, and adds the URL case. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 23:22:53 -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	af0389ed13	web: the command palette finds notes written since it was first opened ... The palette's note list loaded once per session behind a `loaded` flag, and the `reload()` that would have cleared it had no caller. So a note written after the first open couldn't be found by name until the page reloaded (#5165, audit B4). The list is now fetched again on every open, and the last list stays visible meanwhile. The input takes focus before the fetch, and a failed fetch keeps the old list instead of breaking the palette. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 22:51:36 -04:00
bvandeusenandClaude Opus 5.5	c5f93cf9f1	rename: the sign-in screen shows Inkwell's mark, and every tab says Inkwell ... The login and register screens still drew a hard-coded "TS" tile. They now use /icon.svg, the same mark the shell's header shows. Browser tabs took index.html's static <title> and never changed it, so every tab read the same, and some browsers showed the URL instead. usePageTitle, mounted once in App.vue, sets "<page> · <site name>". Routes outside the shell name themselves with meta.title. Board lenses use the lens name the header already shows, now in useLensName so the tab and the header read from one place. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 17:52:50 -04:00
bvandeusenandClaude Opus 5.5	6d082b2ad8	rename: the docs say Inkwell, and nothing else still says ThoughtSync by accident ... Step 6 of milestone 481. README, docs/*, ci-requirements.md, the desktop and Arch READMEs, alembic.ini, .gitignore, the frontend package name, the service worker's cache name (its activate handler deletes any cache by another name, so the old one is cleaned up), and the Android names in the release body. What still says thoughtsync does so on purpose (Scribe note 5071): - the desktop data crossover (crossover.rs) and its startup log - the old-export import marker - the "Upgrading from ThoughtSync" block in .env.example, and compose's pointer to it - the packages being retired: deb conflicts/replaces thought-sync, pacman thoughtsync and thoughtsync-desktop - the Android signing keyAlias, which names a key in the existing keystore - history: shipped alembic migrations, and the test-binary hashes that ci-requirements.md records from 2026-08-18 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 14:35: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	a706644455	rename: the server is Inkwell — package, env vars, image, compose, export marker ... Step 2 of milestone 481. The operator chose a full rename (Scribe note 5071), so this goes past the display strings into the identities: - src/thoughtsync → src/inkwell; every import, the Dockerfile and both compose commands, alembic env, pyproject - THOUGHTSYNC_* → INKWELL_* (database URL, secret key, log level, tag/port/bind) - container data dir /var/thoughtsync → /var/inkwell - image git.fabledsword.com/bvandeusen/inkwell; Postgres user/db default inkwell; CI's integration service follows - the files the image serves are inkwell.*. fetch-clients.sh still fetches the thoughtsync-named release assets, because the lanes that publish them are renamed in steps 3 and 4 - exports are written with app "inkwell" Two deliberate exceptions, both because data rides on them: - compose volumes are now named explicitly and overridable (INKWELL_DB_VOLUME, INKWELL_DATA_VOLUME), so a deployment installed as ThoughtSync points at the volumes and DB identity it already has. .env.example says exactly what to set - import still accepts app "thoughtsync", because exports written before the rename are backups. Tested both ways Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 14:18:49 -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	729d0dadf1	editor: collect the refund — the web editor autosaves on an idle pause ... #2971's engine work was already done and its benefit was never taken up here. Both engines coalesce revision snapshots to one per editing session — `src/thoughtsync/revisions.py::should_snapshot` and `store.rs`'s namesake, the server's applied on the PATCH path AND in `sync.py`, with four integration tests covering it. So a write has cost a write, not a write plus a revision, for some time. But this editor still wrote only on `close()`. That save-on-close existed BECAUSE writes were expensive; with the reason gone, all that was left was the cost — a tab closed mid-paragraph lost the paragraph, which is the one thing a notes app must not do. Android already debounces (`BoardViewModel`); the shared Vue editor did not, so web and desktop kept paying for a trade that had been cancelled. Now: a 1s idle pause writes. EDIT MODE ONLY, deliberately. In compose, `dismiss` discards a note that was never persisted so an accidental keystroke or a type-to-compose never litters the board. An autosave there would create the row and quietly take that behaviour away. Materialising a compose on first keystroke is a separate decision (#2967), not a side effect of this one. Three details that decide whether it is safe rather than merely present: * `flush` returns without writing while a save is in flight, so an autosave landing there would silently drop everything typed since that save began. It RE-ARMS instead of skipping. * Errors are swallowed and retried on the next pause. An autosave that interrupts typing with a message is worse than one that waits, and `close` still surfaces a real failure where the person is looking. * The timer is cancelled by `close`, by `dismiss` and on unmount, so nothing fires through a component during its leave animation or after it is gone. Checked and found harmless rather than assumed: `notes.reconcile` replaces the store's item but never touches `useNoteEditor`'s `editing` ref, so the `watch(() => props.note)` that calls `setBody` does not fire on a save. Were that not true, autosaving would have reset the field and the caret every second. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c	2026-09-01 18:26:05 -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	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	ef418a8c92	buttons: one definition of the shape, worn by a <button> and by an <a> ... The download links added in fd1e4ae carried their own copy of BaseButton's class list, because BaseButton is a <button> and cannot hold an href — and a download must be an anchor, so the browser's own download manager gets the 3-95 MB transfer instead of a blob this app would have to hold in memory. A copy is not a solution to that; it is two primary buttons that look alike until someone changes one. So the shape moves to `.btn` + `.btn-primary` / `.btn-ghost` in the components layer, where both elements can wear it, and neither owns it. The `disabled:` variants stay on BaseButton. An anchor has no :disabled, so they were never shared and pretending otherwise would put a rule in the shared definition that only one of its two users can ever match. Verified there is exactly one shape to unify and no third copy: `px-4 py-2.5` appears in three other files and all three are something else (a toast, a dashed quick-add affordance, a retention notice). The smaller brand buttons in AppShell and NoteEditor are a different size, which is a size-variant question and not this one. And exactly one call site passes a class to BaseButton — `shrink-0` — which cannot conflict with anything the shape declares. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c	2026-08-31 08:08:01 -04:00
bvandeusenandClaude Opus 5	fd1e4ae487	downloads: five clients, and the page leads with the one that fits you ... The Account page offered the APK and nothing else, because the APK was all the server held. Step 3 baked in four more, so the single card had to become a section — and five artifacts is exactly where a downloads page turns into a table of filenames and stops being a product. So it LEADS with what fits the machine asking, from the user agent, and keeps the rest quiet but visible. A wrong guess costs nothing: nothing is behind a disclosure and every other client is one click away. Linux gets all three at once, because the UA says "Linux" and nothing about dpkg or pacman — there is no better answer available. They are named for the distro rather than the package format, since a person knows which system they run and not necessarily which packaging it uses. The AppImage carries one clause of its own: it is 95 MB against 3, and it is also the only bundle that updates itself in place. Both facts belong to the same decision. macOS and iOS lead with nothing and say so. There is no build for either, and "There's no macOS build yet" is the difference between deliberate and broken. The version renders `unknown` rather than blank, and the download stays offered — not knowing which build it is, is not a reason to withhold it. Two things this did NOT do, both deliberate: The task asked for a Tauri case — do not offer the desktop app to someone already running it. That case cannot be reached: `/account` redirects to the board in the desktop app (requiresServer, router/index.ts), because device tokens are a server-side concept. A branch for it would be dead code. `.btn-link` mirrors BaseButton's declarations rather than replacing them. BaseButton is a <button> and cannot carry an href, and unifying the two would have put every button in the app into an operator pass that CI cannot check — for a cosmetic gain. The comment names the pair. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c	2026-08-31 07:58:17 -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	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
bvandeusenandClaude Opus 5	d9e5753dc2	board: a tag in the prose is coloured where it sits, not printed twice ... A tagged note was showing its tag twice — once where it was typed, once as a chip — and the duplicate was the loud copy. Now the chip row carries only what the body cannot say (a tag lifted off its own line, a label from the picker), and a `#tag` left mid-sentence is tinted in place. Which characters are a tag is asked of the CORE, the way the card already asks it which lines are checklist items: `extract_tag_spans` keeps the spans `extract_tags` throws away, and `body_tags` hands them to Kotlin. Offsets are UTF-16 code units, because `AnnotatedString` and JS both index that way and a char index lands mid-token the first time somebody writes an emoji. The web keeps its own matcher in markdown.ts, mirroring `line_tags` case for case. The inline ink is its own table, one Tailwind step deeper than the chip's. A chip brings its own -100 fill and reads against that alone; inline text sits on whatever the card is, including a gray-tagged card at neutral-200 — where the chip's -700 measured 3.98 (green), 4.11 (orange) and 4.34 (teal), under the 4.5 body text needs. At -800/-300 every hue lands 5.63-12.01 light and 7.20-10.84 dark across every palette and generated fill. Chips now carry the `#` on every surface. The via_tag branch that used to decide it is gone from the card, and Android's row said no hash at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 22:20:17 -04:00
bvandeusenandClaude Opus 5	23fd2da91e	The tag goes at the top of the card, where it gets looked at ... Label chips sat under the body, the checklist, the attachments and the link previews. On a tall note that puts the one thing saying what a note IS below the fold of a glance — and a board is scanned, not read. "Which of these is about the thing I am looking for" should be the first thing the eye lands on. Above the body rather than beside it: the body's first line is the note's NAME (M13 steps 3 and 4), and a chip floated next to it would compete with the thing that identifies the note. A row of its own costs one line, and only on notes that carry tags. Both surfaces, same order. Does not depend on tag lifting, which is a much larger change — see the task. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 17:17:32 -04:00
bvandeusenandClaude Opus 5	3d490bb6f3	HSL lightness is not luminance — the dark floor was too low ... The unit test I added with the generated fills failed on its first run, on exactly the claim it was written to check, so it earned its keep immediately. The floor was 0.090 — `neutral-900`'s own HSL lightness — reasoning that a ramp starting at the card surface and climbing could not end up below it. That confuses HSL lightness with luminance. At one fixed lightness the eye sees very different brightnesses by hue, because green carries 71% of the luminance formula and blue only 7%: at L=0.090 a yellow measures 0.0118 and a blue 0.0061. Every blue-ish untagged note was 1.41x DARKER than the card it was supposed to match, which on the board reads as a hole rather than as variety — the opposite of what the whole change is for. Solved rather than nudged: 0.113 is the lowest floor at which EVERY hue clears the card surface. The range now measures 1.11-1.71 against the board against the old 1.06-1.54, so the floor is back where the shipped ramp had it and the ceiling is higher. Body text 7.8 against the 4.5 it needs, meta 4.6 against 3.0. 338 distinct dark fills. Two things about the test are worth keeping. It asserts on LUMINANCE rather than on the lightness that was put in — a test of the input would have agreed with the bug and passed. And it now sweeps 40,000 ids rather than 500. The worst case is a HUE, not an id, and 500 ids reach only 459 of the 2160 hue/level combinations — it caught this one by luck. 40,000 covers all 2160. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 17:17:32 -04:00
bvandeusenandClaude Opus 5	1d3cc7bcd4	Nine tints that looked like three — generate the fill instead ... Measured, the nine dark subdued fills were separated from each other by at most a 1.03 contrast ratio. That is not "subtle", it is identical, and it is why a board of them reads as one card repeated: "I only see 3 colors ... it looks like a monolithic wall." Two causes, and the second one is mine. NINE IS TOO FEW. The palette exists to say WHICH TAG. An untagged note's fill says nothing at all — it only has to keep the board from repeating. Those are different jobs and tying them together capped the second at nine values for a board that will hold hundreds. ONE AXIS IS TOO FEW. The subdued ramp varied hue while pinning every fill to the same lightness — deliberately, so each would read as a card against the board. But the eye separates by lightness first, so nine hues at one lightness are one card nine times. Hue alone was never going to carry it at that darkness. So an untagged note's fill is now generated from its id rather than looked up: hue anywhere on the circle, one of six lightness levels, saturation fixed. 324 distinct fills in dark and 193 in light, against nine. Separation between fills goes from a 1.03 ceiling to 1.42. Varying lightness is only SAFE because the card has its own grey edge now. While the fill was the card's only boundary it could not afford to drift toward the board; the edge bought that freedom, one commit before it was needed. Saturation is the one dial the hash never touches — variety comes from hue and lightness, loudness would come from saturation. Dark starts a hair under `neutral-900` and climbs, so no note is ever darker than a plain card. Light runs from white down past the board. Body text measures 8.7 at worst against the 4.5 it needs; the meta row 5.1 against 3.0. DOUBLE, NOT FLOAT, on the Kotlin side. JavaScript has one number type and it is binary64; a Kotlin Float is binary32, so the two would round differently near a channel boundary and a note would be one byte off between the phone and the browser. Nobody would ever file that — they would see two colours that are "sort of the same" and never work out why. The web half cannot be executed here at all (no node on this machine), so the Kotlin fixture test is the only place the two implementations are ever compared. It now pins eight generated values as well as the hash, plus the properties that actually matter: that lightness varies, that nothing sinks below the card surface, and that body text stays clear of AA. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 16:55:50 -04:00
bvandeusenandClaude Opus 5	ae2053d2ed	Give the cards an edge again — one grey, not ten hues ... The border was never the problem; a border that carried COLOUR was. It said exactly what the fill already said, at 1.56-2.09 against that fill where the fill managed 1.03-1.05 against the board — the loudest element on every card was redundant with the quietest. A line that varies by colour is content and competes with the fill. A line that never varies is structure and does not. So the edge comes back, and it comes back as a constant in NoteCard rather than a column in the palette. Uniformity is the feature, and putting it where the palette cannot reach it is how that stays true. light #b8b8b8 1.57-1.98 against all twenty card fills dark #404040 1.58-1.73 Matched, not eyeballed: both land at ~1.6-1.7 against the card they edge, so the edge reads with the same authority in either theme. Dark is `neutral-700` — what the `default` card's border always was, one entry's value promoted to the rule for all of them. Light sits between `neutral-300` and `neutral-400` because neither lands in range: 300 fades to 1.18 on a gray-tagged card, 400 jumps to 2.52 and reads as a wireframe. Rejected on measurement: a translucent black/white edge, which is the tidier way to write it and self-adjusts per card. A border composites over the card's own fill, so `border-white/20` comes out #56396d on a purple card and #a3c9c1 on a teal one. Hue-coded edges are the thing being removed. The shadow steps back to what it was for — depth, not the boundary. Web returns to `shadow-sm`; Android's 2dp drops to 1dp, matching it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 15:00:22 -04:00
bvandeusenandClaude Opus 5	47f108c9c8	The border was the thing making every note look the same ... A note card carried a 1px tint border. Measured against its own fill, that line was a 1.56-2.09 contrast in dark mode while the fill managed only 1.03-1.05 against the board — so the loudest thing on every card was an identical line in an identical place, and a field of them read as a grid of outlined rectangles however different the colours inside were. Removed from the note card on both surfaces. `border` survives for panels, banners, the update card and the pickers: those are single elements, not a field of them. What replaces it differs by theme, because elevation does. Light leans on a shadow. An untagged card is `bg-red-50` on a `neutral-50` board — a 1.04 contrast that can only read as a card by sitting above one. The web goes `shadow-sm` -> `shadow`; Android had no shadow at all and gets 2dp. Dark cannot use one, black on near-black. So the subdued fills moved onto the card surface instead: `{hue}-950` composited at 0.18 over #171717 and baked, rather than the same hue at 0.25 over the near-black board. An untagged card now sits where the plain white card always sat (1.11-1.14 against the board, against `bg-neutral-900`'s 1.10) while carrying LESS hue than before — chroma 7-17 where the old ramp had 10-23. Subtler and more visible at once, which is only a contradiction if subtlety has to come from lightness. Here it comes from chroma, and lightness is left to say "this is a card". Which also reframes the two weights: in dark they now sit within a hair of each other (red: 1.11 vs 1.12) and differ threefold in colour (chroma 10 vs 41). The chosen ramp is untouched — the operator signed those colours off, and a ramp somebody likes is not something to redo while fixing something else. Light was already built this way: `-50` and `-100` are both white plus a different amount of hue. Body text still measures 14.3-16.4 against the 4.5 it needs, meta 6.9-7.1 against 3.0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 14:21:42 -04:00
bvandeusenandClaude Opus 5	fe18aaa956	The contrast pass, and the invisible chip it found ... Step 4 of milestone 309. All 40 combinations measured rather than eyeballed — 10 hues x 2 themes x 2 weights, dark ones composited over the board the way Compose and CSS both do, against the text actually drawn on a card (neutral-700/300 body, neutral-500/400 meta). Body text ranges 8.23:1 to 13.01:1 against a 4.5:1 requirement; meta text 4.33 to 7.11 against 3.0. Every combination passes AA with room to spare, so the two ramps step 3 introduced need no adjustment. That is the boring half. THE PASS FOUND A REAL REGRESSION. A tagged note takes its first tag's colour and is drawn at that hue's `-100` — which is exactly what the chip uses as its fill. Measured contrast between the chip and the card it had itself coloured: 1.00 in light mode. Perfectly invisible. Dark was 1.04-1.07, invisible in practice. On every tagged note the tag name had stopped reading as a chip and become loose text, and nothing about step 3 looked wrong while writing it. Fixed with an EDGE rather than a different fill. A fill can collide with any card colour and chasing that would need the chip to know what it is sitting on; a border in the chip's own foreground reads against any background and needs no plumbing. Alpha is 0.60, measured: 2.32:1 at worst, where the 0.30 I first wrote gave 1.49 and was no edge at all. It does not reach WCAG 1.4.11's 3:1, which needs 0.80 and draws a hard outline instead of a hairline. 1.4.11 governs boundaries carrying REQUIRED information, and a chip's information is its text — passing AA at 8:1 or better on every card here. The number and the reasoning are both in the source so the judgment can be overruled rather than rediscovered. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 13:37:51 -04:00
bvandeusenandClaude Opus 5	988e1d3f00	A note's colour is its first tag's colour, at a heavier weight ... Four #todo notes on the operator's board in four different colours, because the tint was derived per-note-id and ignored tags entirely. Now a tagged note wears its first tag's colour, so notes that share a tag share a look. TWO WEIGHTS, NOT ONE RAMP. The operator, seeing step 1: "the tints look the same as the chosen colors". They did — there was only one ramp. `strong` is not a second decision, it IS whether the colour was chosen: a tag (or, until step 5, the picker) means somebody said what this note is, while a derived tint only means the board should not be a wall of white. The two weights move in OPPOSITE directions per theme, because that is where each has headroom. The operator asked whether the tint could go lighter instead of the tagged end going darker; in dark mode that is the better half of the answer, so the derived end drops to a quarter opacity — closer to the board, which gives the light body text MORE contrast rather than less. Light mode has nowhere to go below `-50` without being white again, so there the gap opens by deepening the chosen end to `-100`. No hex was transcribed for any of it. `-100` is already in NoteTint.kt as every hue's `lightChipBackground`, and the dark weights are the existing `-950` fill re-alphaed, so the only two numbers that have to agree by hand are the alphas. Copying ten more Tailwind values from memory is exactly how this mirror would have drifted. `default` is marked not tintable — it is the ABSENCE of a colour, there is no emphatic version of it, and re-alphaing its opaque neutral fill would have made every draft card translucent. Borders untouched: the fill is the signal, moving both muddies the edge. Resolution order is explicit pick, then first tag, then the id hash. First tag because it is the one you control by typing; manual labels count the same as #tags because nobody can tell which kind they made by looking. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 13:15:47 -04:00
bvandeusenandClaude Opus 5	6fbee27f9c	A tag with no colour of its own derives one from its name ... Every #tag ever typed is `default`. `notes/tags.py` mints one as `Label(owner_id=…, name=name)` with no colour, so it takes the column default — which means tag-driven note colour, built on top, would have left the board exactly as grey as it was. Four #todo notes in the operator's screenshot, four different colours, because the tint is per-note-id and ignores tags entirely. DERIVED RATHER THAN PERSISTED AT MINT TIME, reversing the plan in 2965. That plan wanted a hashed colour written wherever a label is born, and named the risk in its own body: `find_or_create_label` is "easy to miss, and it is the common one", because most tags are born from typing `#grocery`, not from a management screen. Deriving has no mint points to miss, needs no backfill for the tags that already exist, and reuses the hash and the fixture the notes already have. The cost is that renaming a tag recolours it. That is defensible — the name IS the tag — and an explicitly picked colour is still stored and still wins, so tag colours stay editable exactly as asked. Lowercased before hashing: tags dedupe case-insensitively, so #Todo and #todo are one tag and must not be two colours. All five places a label's colour is drawn now resolve the same way — the card chip, the editor chip, the drawer's tag list, and the management modal's dot and swatch ring. The modal's ring follows the resolved colour rather than the stored one, so opening the picker highlights what you can already see instead of nothing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 12:57:59 -04:00
bvandeusenandClaude Opus 5	6f173b166b	Every note carries a tint, derived from its id ... The board was a wall of white rectangles: `default` is the colour nobody picks, so it was the colour of every note except the two the operator had coloured by hand. Reported twice — 2026-08-23 as "a wall of broken up text", and again today as "all the existing notes are the same dull color". The ask was "random subdued colors", but random is the one thing it must not be. A tint rolled at render time would differ between the phone and the browser and change on every reload. FNV-1a over the note's id is deterministic, identical on every surface, needs no column and no migration, and a note keeps its colour for life — which is what "random" meant here. Two implementations, deliberately mirrored, same discipline as the checklist grammar. The Kotlin half lives in a Compose-free file so a host-JVM test can pin the fixture; the TypeScript half carries the same four ids and hashes as a comment because the frontend has no test runner at all — its whole CI lane is `vue-tsc --noEmit`. That asymmetry is worth naming rather than papering over. A draft has no id yet (DRAFT_ID is ""), so it stays white until it is saved. Hashing the empty string would give every draft one shared tint and then change it on save anyway — two surprises where one will do. An explicitly-picked colour still wins. The picker is on its way out (milestone 309 step 5) but it has not gone yet, and a hand-coloured note changing under the operator would read as data loss. First of five steps toward colour coming from tags. This one stands alone: no storage change, nothing removed, and the board stops being white today. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 12:26:01 -04:00
bvandeusen	96a6f6e691	web: the editor draws the checklist too ... 2992's other half. The browser was the last surface still showing `- [ ] ` as markup: cards rendered and ticked checkboxes, the editor did not. Same shape as Android, deliberately. notes/blocks.ts mirrors EditorBlock.kt — splitBlocks, joinBlocks, afterEnter, withoutIndex, plusTask — because the two editors should behave alike and the cheapest way to keep them that way is for the code to read alike. `body` becomes a computed over the blocks, so every save, baseline check and draft still reads the one markdown string they always did. markdown.ts now exports parseTaskLine and renderTaskLine, and parseMarkdown uses the former. The read view and the editor's block split had been matching the same grammar through two separate copies of one regex; now they agree by construction. Two places the web can do better than Compose, and does: * Backspace at the start of an empty item removes it. A browser sends a real keydown for Backspace; an Android soft keyboard sends an IME delete that never surfaces as one, which is why that surface only has Enter-on-empty. * Prose fields size to their text — rows="1" plus a scrollHeight fit, which beats guessing a row count that is wrong the moment a line wraps. KNOWN, and the same on both surfaces: typing `- [ ] ` by hand into a prose block leaves it prose until the note is reopened. Blocks are split when the editor loads, not re-derived per keystroke — re-splitting mid-type would move the caret. The toolbar button is the intended path. Converting on blur would fix it and is worth doing to BOTH editors at once rather than letting them drift.	2026-08-26 07:53:13 -04:00
bvandeusen	3cab054684	web: task lines render as checkboxes where they sit in the note ... M304 step 5. The server already returns a derived `items` array, so the web kept working across the last two commits — but it was rendering every list TWICE: once as literal `- [ ] milk` bullets inside the body, and again as the separate NoteChecklist block underneath. This is the commit that makes the body the only place a checklist appears. markdown.ts gains a `task` block, matched BEFORE the plain bullet — which would otherwise swallow the marker and leave the brackets showing, the same ordering reason `code` is matched before emphasis in INLINE_RE. Each item carries its ordinal across the WHOLE document, because that is what an item's id means everywhere else now; counting per block would have made the second list's checkboxes toggle the first list's items. The card's preview clamp is why that ordinal is safe there: it only ever drops lines from the end, so a visible item's index is the same whether or not the body was truncated. MarkdownText emits a toggle rather than reaching for the store. Ticking a box rewrites a line of someone's note, and a renderer used in several places should not be the thing deciding that is allowed — the card passes `toggleable` and wires it, a read-only render does not and the boxes are inert. Not wrapped in a <label> either: on a card the text is the note's own words and clicking it opens the note, so only the box toggles. In the editor, the toolbar button stops revealing a section and inserts `- [ ] ` at the caret. That makes it the one toolbar action needing no persisted note to hang anything off — ensureDraft is gone from it, and it works on an empty compose box the moment it opens. Enter on a task line continues the list, and on an EMPTY one clears the marker; without that second half a list would be impossible to get out of. Indent and bullet are carried over rather than normalised, because continuing someone's `*` list with a `-` is an edit they did not ask for. NoteChecklist.vue is deleted (rule 22). The store's item methods stay: they are the repository seam the REST routes and Tauri commands both implement, not the old path. CI cannot check any of this beyond types — there are no frontend tests, only vue-tsc. It wants a real browser pass.	2026-08-24 08:10:20 -04:00
bvandeusen	09b5f874b6	Security values move into the Settings UI ... Operator: *"proxy hops defaults to 1 and should be in the settings UI not in the envs, we need the security values to be in the UI."* Overrules the call I made yesterday, and rule 25 is on your side — I argued deployment-topology, but the operator has to be able to SEE what protects them, and reading a container's environment is not seeing. Six new settings in a **Security** group: trusted proxy hops (default 1), the per-account and per-address sign-in limits with their shared window, and the sign-up limit with its own. `THOUGHTSYNC_TRUSTED_PROXY_HOPS` is gone; the rate limits are no longer hardcoded constants. **The hard part was keeping the throttle cheap.** It consults these BEFORE opening a database connection — deliberately, because a refused attempt is meant to cost nothing, and the hop count is needed to know who is even asking. A query per attempt would undo both. So there is a small cache seeded from the registry defaults (the app works with no database at all, which is what the DB-free unit lane relies on), loaded at boot, and refreshed on every settings save — the same live-update contract `session_ttl_days` already had. `SlidingWindow` now takes its limit and window as SUPPLIERS rather than values, so a saved number applies to the next attempt instead of the next deploy. **Bounds are rejected, not clamped.** A hop count of 99 would trust anything a caller sent; a sign-in limit of 0 would lock every account out permanently. Both now fail validation with a message naming the range, and the number input carries min/max so the browser objects first. Silently storing a different number than the one typed is how somebody ends up believing a protection is set to something it is not. `MAX_BUCKETS` stays a constant on purpose: it protects the limiter from itself rather than the app from a caller, and there is no operator judgment to apply. Two integration tests, because the whole point is the round trip: a dangerous value refused, a legitimate one reaching the cache the throttle reads and persisting; and every Security row reaching the admin payload with bounds and a description that explains itself.	2026-08-23 15:24:15 -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	de72d27bd4	URLs unfurl on their own, and a lone link becomes the note ... Operator: *"I'd like for URLs to unfurl. To be the whole note when the note is a single URL, and to be a compact slot on the bottom of the note when the URL is inline. We also need to support multiple URLs in a single note."* Less new machinery than it sounds: `unfurl.py` already fetched and parsed OG tags, SSRF-hardened, and `note_link_previews` was already `UNIQUE(note_id, url)` — so several URLs per note has worked at the storage layer all along. What was missing was that it needed a button, had one size, and drew that size in the wrong place. **Automatic, and never in the way.** New `unfurl_queue.py` detects a body's URLs and fetches them on a background task AFTER the note is committed. Capture speed is the product: an unfurl is a five-second timeout against a host nobody controls, and a note has to persist the instant someone stops typing. Scheduled from create, from a body edit, and from a synced push — so a linked desktop or Android client gets previews too, on its next pull. An unlinked one has no server to ask and simply has none, which is the honest consequence of being offline. Safe to call on every save: it re-reads what's cached and does nothing when nothing is new. Capped at five URLs per note, silent on every failure (a link that won't fetch isn't an error the person needs — the note is fine, the link is still there), and it re-checks before storing, so a slow fetch can't resurrect a preview for a URL that was deleted while it was in flight. **Two presentations.** A note whose body is nothing but a URL renders as its preview and nothing else — printing the raw URL under a card that already says where it goes is saying the same thing twice, badly. Until the fetch lands, or if it never does, the URL stands in, so the card is never blank. Anything else gets a compact strip. **And the strip moved.** Previews were rendered ABOVE the body, which put a stranger's headline where the note's own first line should be — worse now that the first line IS the note's name. They sit at the foot of the card now, under the note's own words. The editor's "Preview example.com" button is gone with the manual path; removing an unwanted preview stays, and stays editor-only. Nine tests: three on detection (order, dedupe, sentence-punctuation trimming, non-http rejection) in the unit lane, and three in the integration lane for what only a real database shows — the upsert landing on the right row, a second pass fetching nothing, and a preview NOT being stored for a URL that left the body.	2026-08-23 01:05:37 -04:00
bvandeusen	c99cbb3e14	cards: clamp the web note preview, as Android always has ... M13 step 4 asked for no bold first line, and step 3 already delivered that — removing `note.title` took the card's <h3> and the Android editor's bold field with it. What step 4 also asked for, and hadn't been done, was the other half: "be willing to spend something small on legibility that isn't weight on the first line." The web card rendered the entire body. Android has always clamped to eight lines (`MAX_PREVIEW_LINES`), so one long note produced a card taller than the screen on the web and pushed the rest of the board off it — a real asymmetry between two surfaces that are supposed to be peers. It matters more without a title. The first line used to be what your eye caught; with one weight throughout, an unbounded card is just a wall, and the note beside it is the one you were actually looking for. Clamped in the STRING, not with CSS `line-clamp` — that needs a `-webkit-box` and behaves unreliably around the block elements MarkdownText emits (lists, quotes, fenced code). Doing it before the parse is deterministic, matches Android's semantics exactly, and skips parsing a body the card was never going to show.	2026-08-23 01:00:39 -04:00
bvandeusen	924ddb20db	notes: saveEdit still asked for a title ... The one thing step 3 missed, and the typecheck lane caught it: `saveEdit`'s parameter type still declared `title`, so the editor's call — correctly no longer passing one — didn't match. I gated Rust locally and not the frontend. Both are now in ci-requirements, including WHY the frontend one has to be `npm run build` rather than `vue-tsc --noEmit`: the typecheck only reads the script block, so a malformed template sails past it and fails `vite build` in a different workflow, which is exactly how the stray `</div>` got two commits away from where it was written.	2026-08-22 21:38:13 -04:00
bvandeusen	95aa10c2c3	Remove the title field — a note is named by its first line ... Operator (note 2897): "notes shouldn't have a title field." The concept of a NAME stays — search results, export filenames and the command palette all need one — but nothing is typed into it any more. `display_title` is now the first non-empty line of the body, falling back to the first checklist item. That fallback is what step 2 bought, and the reason this could not go first: a checklist had no body to be named from, so the title was its only name. Now every note has a body, and a note that is only a checklist is named by its first item. Gone everywhere: the column and note_revisions.title (0026), the field on the core's Note/NoteCreateInput/NoteRevision and its SQLite columns (user_version 7), `normalize_title`, the wire field, the FFI record and `NoteEdit::Title` / `ClearTitle`, the web editor's "Title (optional)" input and the card's <h3>, and the Android title field in both the compose sheet and the editor. **The search vector had to be rebuilt, not just left alone.** `notes.search_vector` is a STORED GENERATED column whose expression names `title` — Postgres refuses to drop a column another generated column depends on. It is dropped and recreated over `display_title` at weight A, which keeps the original intent: a note's NAME ranks above the rest of its body. **An imported title becomes the note's first body line.** Keep notes carry one, and so does any ThoughtSync export taken before this. Dropping it would silently lose text someone wrote; folding it in puts it exactly where a name now lives, so the note arrives named as it was. Skipped when the body already opens with that line, so re-importing an export this code produced doesn't stack duplicates. Two smaller things fell out. The Android editor loses its bold first field — one weight throughout, because the first line is the note's name but not a different KIND of text, which is most of step 4 arriving early. And `ClearTitle`'s justification comment moved to `ClearRemindAt`, which is now the surviving example of why NoteEdit is a list rather than a struct of options. Protocol note corrected to say what actually shipped: v2 is "no kind, no title", one bump for the pair. Verified with the local Rust gate this time, not by CI: fmt, clippy and 116 tests all green before pushing. It caught four things — orphaned serde attributes where fields were removed, a `wire::Preview.title` I deleted by mistake (a link preview still has one), nine retention fixtures inserting a dropped column, and four rustfmt diffs.	2026-08-22 19:33:57 -04:00
bvandeusen	33e9278975	Fix three breaks the removals left behind ... **`snapshot_revision` was deleted with `create_titled`** (bc22f8e). I sliced the function out by scanning to the next `pub fn`, and the private `fn` sitting between them went too. Nothing in Python or TypeScript compiles Rust, so it sat undetected until the first lane that does. Restored verbatim. **An orphaned serde attribute** in push.rs: removing `pub kind: Option<String>` left its `#[serde(skip_serializing_if)]` behind, which then stacked onto the next field's. That failed the derive, which is why three follow-on errors all said `Change: Serialize is not satisfied` — one cause, four messages. **An unbalanced `</div>`** in NoteEditor.vue, orphaned when the "Links / Linked from" footer was cut. `vue-tsc --noEmit` type-checks the SCRIPT block and never parses the template, so the typecheck lane passed it and `vite build` caught it two workflows later. Worth remembering: a green typecheck says nothing about template structure. I also pushed step 2 without waiting for ad21eac to go terminal, which is what let the Rust break travel a commit further than it should have. Each fix comes with the check that would have caught it: a scan for stacked serde attributes and called-but-undefined fns across every .rs, and a tag balance pass over every .vue. Both are clean.	2026-08-22 13:25:26 -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
bvandeusen	ad21eac5bc	editor: drop the adapter import that went with backlinks ... `repo` reached the editor for exactly two calls — `repo.notes.backlinks` and `repo.notes.linkSearch` — and both left with the linking system. vue-tsc runs with noUnusedLocals, so one stale import failed the whole shared-frontend build and took both desktop lanes down with it (TS6133). My local sweep checked for dangling *references*; it never checked the inverse, that every import still has one. It does now, across all fifteen files that removal touched — `repo` was the only one.	2026-08-22 12:44:33 -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
bvandeusen	982d24c83b	links: bind a [[link]] to a note, not to a string ... A wiki-link was stored only as normalized TEXT, so a note's NAME was the edge. Renaming it broke every inbound link — and the fix that shipped for that (task 1848, option b) was `_rename_inbound_links`: rewrite the `[[Old Name]]` text inside the body of every note that linked to the renamed one. That works while an explicit title exists to hold still. It stops being defensible the moment a note's name is just its first body line, which is where M13 is going: fixing a typo in your opening sentence would silently edit other notes' words, with nothing to opt out to. So this lands first, before the title comes out, and that window never ships. `note_links` gains `target_id`, bound when the link is written. `target_norm` stays and is what an UNRESOLVED link carries — linking to a note that doesn't exist yet is a supported way to create one, so a link has to be able to name a target that isn't there. Resolution reads the id, falling back to the name only where nothing was bound, which is what lets a forward link connect the moment its target appears. `_claim_unresolved_links` then binds it, so the fallback is a transitional state rather than a permanent one. `_rename_inbound_links` and `rewrite_link_title` are gone. What replaced them touches link rows only: a note's text is never modified by something happening to a different note. The client can no longer resolve links for itself, and that is the point. It used to look `[[text]]` up in a client-side name index, which only held together BECAUSE renaming rewrote the text everywhere. Now the written text can name something the target is no longer called, and only the server holds the binding — so each note serializes its resolved links (`norm`, `id`, and the target's name as it stands NOW). A renamed note reads correctly everywhere it is linked from, without a single body having been edited. Unresolved links are simply absent and fall through to the create-on-click affordance that already existed; so does the offline desktop store, which derives links at query time and has no binding to send. The name-fallback join is owner-scoped everywhere it appears. Bound ids were resolved owner-scoped when written, but matching on display_title alone would have let two users who each have a note called "Groceries" see the other's id and name through an unresolved link (rule 47). The new behaviour is all SQL and this suite runs without a database, so the dead helpers' tests are removed rather than replaced. This repo has no integration lane to hold that ground — noted, not papered over.	2026-08-22 11:02:39 -04:00
bvandeusen	16f86bef93	web: make the board usable on a phone, not just reachable ... The controls a card carries were always-visible overlays on a touch device — correct as far as it went (task 2697: a finger cannot hover, and the pill is the only way to pin or archive), but they were still absolutely positioned, so they sat ON the note's own title. A card reading "thought sync tauri app" rendered as "ught sync tauri app" with the grip parked over the first three characters, and the four-icon pill covering the right half of the first line. Placement is now CSS's decision. One element each, two placements: where a pointer can hover they lift out of flow into the floating top-corner pills they have always been; where nothing can hover they stay in flow as a footer row, which cannot overlap anything by construction. Keyed on hover rather than width, for the same reason `.hover-reveal` already is — a narrow window on a laptop still hovers, a wide tablet still doesn't. The colour popover moved inside the action set so it follows it, and opens into the card from either end. The header was sharing one phone-width row between a menu button, the logo, the lens name, a search field and four icons; everything in it was truncated, the lens down to "N…" and the search box to an empty pill. It wraps now, so search takes its own line below sm, and account / settings / sign-out move into the drawer where there is room to name them rather than guess at a glyph. One input, moved by CSS — duplicating it would have meant two `searchInput` refs and a `/` shortcut that focuses the wrong one. Also closes the other half of task 2706, which was waiting on a device to look at: `viewport-fit=cover` together with the `env(safe-area-inset-*)` padding that makes it safe (sides on body, top on the sticky header, bottom on the board and the drawer), and `100dvh` behind an @supports so the app box follows the visual viewport when the keyboard opens instead of the layout viewport. Both halves in one change, as that task insisted. And the composer no longer tells a phone to "Press Enter".	2026-08-21 21:55:46 -04:00