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>
Schema v12 adds notes.state_at: a recipient's own pin, archive and order are
stamped there instead of on updated_at, which stays the text's time. Push sends
them only to a server advertising `shared_state` (push::Accepts), a view share
included; the first pull at that level starts the feed over once so held copies
drop their owner's pins. The client speaks protocol 7 and lists `shares` and
`shared_state` among the features a server may lack.
The web card and editor offer pin, archive and drag on shared notes; share and
trash stay the owner's, and the board's trash key skips notes you don't own.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A note_user_state row per (note, recipient) holds what used to be the owner's
columns as far as anyone else could tell. The board filters and orders through
the viewer's own state; PATCH and reorder write it for a note shared at any
level; the feed's revision for a shared note is the later of the note's and the
caller's row, so a recipient's pin reaches their devices and no one else's.
Push takes the three with their own `state_at` stamp (protocol 7,
`shared_state`), so pinning a copy whose text is behind never makes that text
win over the owner's edit. A body is only stamped as an edit when it changed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
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>
The change feed answers `?shares=1` with every note the caller can see, each
saying how it is held, plus a `revoked` list of notes that left them. Granting
a share moves the note past the recipient's cursor; ending one, or the owner
deleting the note, leaves a revocation on the same cursor. A recipient at edit
may push the note's text, and nothing else. Protocol 6, feature `shares`;
opt-in, so the floor stays at 3.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The operator asked for self-service reset over SMTP. It reuses #5173's
password_resets table, /reset-password page, one-hour single-use token and
sign-out-everywhere.
- Settings (rule 25, not env): a new Email group (SMTP server, port,
encryption as a choice, username, password, from), General → Public
address, and Security → Reset emails per account. The registry gains
`choices`, `secret` (the value is never sent back, `is_set` says one is
saved, an empty save keeps it) and `url` (http(s), trailing slash
stripped).
- mailer.py: stdlib smtplib on a worker thread, 20 s timeout,
starttls | tls | none. mail_settings() is None until a server, a sender
and the public address are set. Links are built from the public address
because the Host header can be forged.
- POST /api/auth/forgot-password: the same answer at the same speed for
any address. The link is made and mailed off the request (send_later).
It is throttled like a sign-in per visitor address, and capped per typed
email by reset_emails_per_account; past the cap it answers the same and
sends nothing.
- POST /api/settings/test-email: mails the admin with the saved settings
and shows the server's error if it fails.
- Public config `password_reset_by_email`. Sign-in shows "Forgot
password?" only then, linking to a new /forgot-password page.
- docs/public-hosting.md: an "Email and forgotten passwords" section.
Tests: the secret stays server-side; emailed link → reset; the same
answer for unknown addresses; the cap; test email success and failure;
validation units. #5266.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The ACL has gated every read since M0, but nothing could write a share.
Server:
- shares_api: GET /api/users/directory (everyone but you, signed-in only),
GET/POST /api/notes/<id>/shares and DELETE …/shares/<share_id>, owner
only. Sharing again with the same person changes the permission
(ON CONFLICT on the new unique index).
- acl.visible_to_user takes permission=; granted_to and shared_ids feed
the serializer.
- Edit covers body and checklist (_get_editable). Everything else stays
_get_owned. A view share's write is a 404 like a stranger's (#1984). An
editor's PATCH naming anything but body is a 403.
- Serialized notes carry permission, shared and shared_by. A recipient
never gets the owner's labels, and a #tag an editor types files under
the owner's (it always went to note.owner_id).
- ?shared=with_me, also allowed in saved views. Trash and reminders are the
owner's. purge_note drops the note's shares.
- Migration 0034: one share per note and person (and per group), permission
limited to view and edit, an index for "shared with me".
Web:
- ShareDialog (one, mounted by the shell): pick a member, Can view or Can
edit, change or remove existing shares, with loading, error and empty
states.
- Card: "Shared by X" or "Shared" chip; owner-only actions and reminder
buttons hidden for recipients; checkboxes inert at view.
- Editor: read-only at view; text and checklist only at edit; Share button
for the owner.
- FilterBar: Shared with me. Repo seam gains `shares`; the offline desktop
shows none of it (#5175 brings sharing there).
Tests: owner, recipient and stranger across reads, every write at view and
edit, tag filing, unshare, trash, delete and validation; web unit tests for
the facet and permission helpers. #5174.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
test_devices signed a fake account into a session and relied on
login_required answering without the database. Since 3dd0b44 the session
path reads the account's epoch, so the fake account hit an unreachable
database and 500ed. The routing property (the static /devices/self rule beats
/devices/<device_id>) is now asserted on the URL map, and the view's 400 for a
web session is an integration test with a real account. #5173.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There is no mail path, so a forgotten password needed a hand on the database
(#2939 §2). Settings → People lists the accounts; Reset password makes a link
that works once within an hour, shown once for the admin to hand over. Making
another link for the same account closes the earlier one.
Using it (/reset-password) sets the password, deletes the account's device
tokens, and moves users.session_epoch on. Sessions are signed cookies the
server can't delete, so each now carries the epoch it signed in under and
login_required reads the account's epoch by primary key. A cookie from before
this has no epoch and reads as 0, the starting value, so the upgrade signs
nobody out. A deleted account's session now stops working too.
The one-time link reveal moves out of InviteList into OneTimeLink, and the
link-building into router/links.ts, shared by invites and resets.
Migration 0033. #5173.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Until now adding a second person meant re-opening registration to the
whole internet while they signed up (#2939 §1). An admin now makes an
invite in Settings: a link that works once, expires (7 days by default,
1 to 30), and can be pinned to one email address. Only the token's hash
is stored, so the link is shown once.
POST /api/auth/register takes `invite`. Redemption is one conditional
UPDATE inside the transaction that creates the account, so two people
racing one link can't both get in, and a taken email leaves the invite
unused. Every refusal says "invalid or expired invite". The register
page reads ?invite= and opens even while registration is closed.
Refs #5172
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A Rust worker reads due reminders from the local store every 15 s and
announces each occurrence once: always to the main window as a toast, and
as a system notification (tauri-plugin-notification) when that window
isn't focused. The page no longer polls on the desktop; its Notification
went nowhere in WebKitGTK and its timer stopped with the window. The
Reminders page says what each surface actually does.
Core gains store::due_reminders, compared by instant, not by string.
Refs #5171
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Export and Import were a link to the server and a reject("needs a server") on the
desktop. Both now run in the core with no server:
- core/src/local/portable.rs builds the same zip the server writes (notes.json,
a Markdown file per note, each attachment this device holds) and reads either
export marker or a Google Keep Takeout zip, with the server's decompression
budget and an all-or-nothing transaction. Export saves to Downloads (no new
plugin) and the sidebar says where; Import takes the archive as raw IPC bytes.
- core/testdata/portable.json pins the format for both copies: the server runs
its Keep and native readers against it (test_portable_fixture.py) and checks
its real export's keys (test_integration.py); the core runs the same cases.
- Found on the way: both importers skipped a Keep note that is only a photo as
"empty". It now imports, on the server and in the core.
- New dependency, approved: `zip` (deflate only) plus `flate2` on its pure-Rust
backend, both already in the lockfile.
The AppImage applications-menu toggle moves from Account, which the desktop
never shows, to the Sync page; the first-run prompt now says so.
errorMessage (#5236) replaces the hand-rolled `.error ?? …` / `.message ?? e`
reads at the remaining catch sites, so a desktop failure shows its real reason.
Task #5170.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
A literal list went stale the moment attachment_sync was added (run 8513), the
same way pinned version numbers did at v2 — for a reason unrelated to what the
test checks.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
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>
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>
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>
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>
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>
A body edit is a sequence: keep a revision, rename the note, lift #tags,
commit, queue link previews. It was written out in PATCH, the item routes,
restore and sync push, and the copies had drifted. Now they all call
`notes/body.py: write_body`, which says how the old text is kept ("session",
"always" for restore, "never" for a new note) and returns whether the text
changed. The routes commit through `_commit_note`, which queues previews after
the commit.
Fixes, both red on 1a2f71e (run 8441):
- restoring a revision queues previews for its links (#5164, audit B5);
- a pushed note keeps the client's edit time when a standalone #tag is lifted.
The lift's extra flush used to let `onupdate` stamp the server clock over it.
Sync push also queues its previews after the batch commits, not mid-batch,
where a fast fetch could look for a note that wasn't committed yet.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Run 8437 failed `verify` on purpose, and the Linux build, the Windows
installer and the update manifest all reported skipped. This removes the red
step, so this push is the other direction: a green verify still publishes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Integration tests for the edit sequence at each door: create, PATCH, ticking an
item, restoring a revision and sync push. Two fail on today's code, on purpose:
- restoring a revision never queues link previews, so a restored link stays a
bare URL (#5164, audit B5);
- a pushed note whose standalone #tag gets lifted stores the server's clock as
its edit time instead of the client's, because the lift's second flush lets
the column's onupdate overwrite it.
The fix follows in the next commit.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Clippy, the workspace tests and rustfmt move out of the Linux `build` job
into their own `verify` job, and both publishing jobs need it. Before this,
`windows` needed only `decide`, so on run 8411 a red clippy stopped the Linux
lane while the Windows installer built and published to dev-rolling (#5184,
rule 177).
This commit also carries a deliberately failing step at the end of `verify`.
It is the red half of the proof: both publishers must report `skipped`. The
next commit removes it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Both bugs were caught red by the tests in 732fd7a (run 8418: 5 failed, 147
passed) before this fix.
- load_note reads columns by NAME. Dropping `color` (fa89da1) shifted every
column after it and the two timestamps were missed, so created_at showed the
last edit and updated_at showed the trash time — null on any live note. Only
the read was wrong; nothing stored is, so no data needs repairing.
- The board's text facet binds its pattern once for its one placeholder. It
pushed it twice after the title column went (95aa10c), and rusqlite refused
every query with InvalidParameterCount — every desktop search failed.
Android searches through store::search and was never affected.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
7bc8e04 never got as far as running them: clippy's cloned_ref_to_slice_refs
rejected four `&[x.clone()]` slices, and the file wasn't rustfmt-formatted.
Still tests only — the expected RED is the two timestamp tests and the
text-search tests, ahead of the fix.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
store.rs had none, which is how two bugs reached desktop and Android unseen.
These exercise every board facet, the timestamps, tags, revisions, items,
trash, reminders and label merges against a real migrated schema.
Two are expected RED on this commit, on purpose, so CI shows they catch what
they were written for:
- each_timestamp_comes_from_its_own_column / a_new_note_carries_both_timestamps:
load_note reads created_at and updated_at one column too far right since
fa89da1 dropped `color`.
- text_search_*: the text facet binds its LIKE pattern twice for one `?`,
left over from title+body (95aa10c).
The fix follows in the next commit.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
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>
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>
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>
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>
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>
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>
7296889 lengthened `/dev/latest.json` to `/dev-rolling/latest.json` in
each_channel_has_its_own_fixed_feed, which pushed the assert past the
line width. `cargo fmt --all --check` failed the Linux desktop job (run
6358) after Clippy and the tests had passed, so that build, its publish
and the manifest job never ran. Layout taken verbatim from the diff
rustfmt printed; no behaviour change.
Scribe #2184.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DwoKYuw3qJmUUYsJeNherB
The rolling dev release lived on a tag named `dev`, beside the branch
named `dev`. Once a clone had fetched tags, `git push origin dev` failed
with "src refspec dev matches more than one" (Scribe #2184, note #3042),
and every session had to know to spell out refs/heads/dev.
The channel is still `dev` everywhere a person sees it: the app's
setting, `install.sh --channel dev`, the stored pref. Only the release
tag moves, to `dev-rolling`, matching roundtable-android. `stable` has no
branch to collide with and keeps its name.
- packaging/channel-tag.sh is the one channel -> tag mapping CI reads:
the publish steps in android.yml and desktop.yml, the manifest job,
fetch-clients.sh and guard-forward.sh. guard-forward exits 2 on an
unmapped channel instead of fetching an empty URL and passing.
- update.rs and install.sh carry their own copy because neither can run
it; update.rs gains a test that no channel feed is named like a branch.
- tests/test_channel_tag.py runs the script: no tag is a branch name,
dev is exactly dev-rolling, an unknown channel fails with no output.
- publish-release.sh titles the release "ThoughtSync dev (rolling)", so
the tag name does not leak into what people read.
TEMPORARY bridge: desktop apps installed before this have
.../download/dev/latest.json compiled in. The dev manifest job sets
BRIDGE_TAG=dev, and write-manifest.sh writes the same latest.json to
the old `dev` release. Its URLs name dev-rolling assets, so those apps
update once into a build that reads the new tag. The bridge, and the old
release and tag, are removed once installed apps have crossed over.
Until then the push still needs the explicit refspec, as
ci-requirements.md now says.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DwoKYuw3qJmUUYsJeNherB
The Android APK upload and both desktop bundle uploads (Linux and
Windows) went through the bvandeusen fork mirror, with comments saying
stock upload-artifact throws GHESNotSupportedError on this hostname. That
stopped being true when the runner moved to gitea/runner 3.x, which
edits the refusal out of the action bundle; stock upload v4-v7 and
download v4-v8 were proven on 2026-09-10 (Scribe spike #3843) and the
same swap is verified on four other repos.
Artifact names, paths, if-no-files-found: error and the no
continue-on-error stance are unchanged. ci-requirements.md now says
stock v7 and keeps what is still true: @v3 uploads are invisible.
Scribe snippet #2271, milestone 395.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DwoKYuw3qJmUUYsJeNherB
`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
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
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
#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
`-D warnings` failed the Linux lane on `constant SUGGESTED is never used`, and
it was right — the suggestion is implemented in `bridge.ts` as
SUGGESTED_CAPTURE_SHORTCUT, and nothing in Rust ever read the copy here.
Deleted rather than exposed through a command. This side accepts any
combination the OS will take; picking one to put in front of someone as a
starting point is a UI decision, and a constant here would only be a second
copy of a string one layer reads and the other does not.
Worth noting what this run DID prove, since the previous one proved nothing:
the lockfile gate passed and the Windows job built the NSIS installer end to
end. So `tauri-plugin-global-shortcut`'s handler signature — the thing I could
not verify without a toolchain — is correct, and the feature compiles.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c
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
`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
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
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
`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
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
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
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
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
`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
`cargo fmt --all --check` failed the desktop lane on one hunk in the new
`client_headers_identify_app_and_protocol` test. Clippy and every test
passed; only the formatter objected.
rustfmt splits `client_headers()[0].1.starts_with(..)` across lines because
an index followed by a tuple field followed by a call is a three-element
chain, and it will not keep one on a single line inside a macro argument
regardless of width. This is rustfmt's own output, pasted back.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c
`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
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
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
`fetch-clients.sh` wrote `"version_code": %s` unquoted, which was right when the
only ordering key in sight was Android's integer. The desktop's is Tauri's
`1.0.<minutes>`, and unquoted that is not valid JSON at all — so `json.loads`
raised on all four generated sidecars and the server advertised nothing. A silent
zero, not an error: `_read` treats a malformed sidecar as "no client here", which
is right for a corrupt drop-in and indistinguishable from this.
Caught by running the real fetch against the live dev channel and feeding the
result to the real resolver, rather than by reading the printf.
Also makes `_resolve` wrap BOTH candidate roots in Path(). Only the first was, and
the asymmetry fails the same quiet way: a str `/` str raises TypeError, `_read`
catches it, and a perfectly good directory reads as empty.
The whole pipeline now resolves end to end against the live channel — five of five
platforms, every sidecar valid JSON, one human-readable version across all of them
with each artifact keeping its own comparator type:
android 2026.08.30.1711 code=3504552 57.6 MB
linux-appimage 2026.08.30.1711 code='1.0.3504551' 95.3 MB signed
linux-deb 2026.08.30.1711 code='1.0.3504551' 3.3 MB
linux-pacman 2026.08.30.1711 code='1.0.3504551' 2.7 MB
windows 2026.08.30.1711 code='1.0.3504551' 2.6 MB
The precedence test wrote `version_code=300` for all five platforms and compared
the desktop's against the int it wrote. It comes back as `"300"`, because the
module preserves each platform's own comparator type instead of flattening both
to int — which is the behaviour the change it was testing had just introduced.
A `coded()` helper now says which shape to expect and why, and the assertion runs
over every non-Android platform rather than spot-checking `linux-deb`. The test
caught a real inconsistency in itself precisely because it compared against a
concrete value rather than round-tripping what it wrote.
~104 MB on top of ~85 MB, almost all of it the AppImage. That is what the product
being complete costs (rule 23): a self-hoster gets a working app for their machine
from the server holding their notes, with no account on a forge that is private.
The AppImage is not optional within that — it is the only bundle that can replace
itself in place, so a server without one cannot serve in-app updates to anybody.
`packaging/fetch-clients.sh` replaces the inline fetch and writes the fixed names
and sidecars `client_dist.py` reads. It never fails: a platform with nothing
published means the server advertises nothing for it and the UI hides that
download, and eight fetches must not become eight ways to redden a green lane.
THE VERSION IS FETCHED, NOT DERIVED, and this is the part that would have been
wrong the easy way. The obvious shortcut is `version.sh display desktop` in the
image job — it has the checkout. But this commit may not be the commit the channel
is serving: a push touching only `src/` does not rebuild the desktop, so the
channel still holds an older build and a locally-derived version would describe
those bytes with this commit's number. `client_dist.py`'s size check could not
catch it, because size IS measured from the real file — it would sail through and
lie about the version alone. So `write-manifest.sh` now publishes
`thoughtsync-desktop.json` beside `latest.json`, from the same two values in the
same breath, and only size/sha256 are measured at bake time.
Which needed the prune's keep-list, or the sidecar would have been uploaded and
deleted again in the same run — a fixed name is self-limiting, which is exactly
why that list exists.
`version_code` is NOT uniformly an integer, and coercing it was a leftover from
the days when Android was the only platform. Android's must stay a JSON number:
`ClientRelease` in core declares it `i64` and a string fails to deserialize on
every phone in the field. The desktop's is Tauri's semver key `1.0.<minutes>` —
the value its updater actually compares — and `int()` would have rejected every
desktop sidecar CI writes. The table now says which is which, and tests pin both
directions.
Also retires the comment above the fetch step, which claimed the APK came from
"always the rolling dev release" and mentioned `:<version>` images. M314 step 3
made the channel conditional in the code directly below it, and step 6 removed
version-shaped image tags entirely.
Verified against the live dev channel before pushing: the Android half resolves
and exits 0, the desktop half degrades with a warning because the sidecar does not
exist yet, and all five constructed bundle filenames return 200.
`client_dist.py` was written for one platform and everything structural in it was
already right — drop-in beats baked, the pair must describe one build, absence is
an ordinary answer, metadata public and bytes authenticated. This widens it to a
table rather than building beside it. Its own docstring made the argument years
before there was a second platform: a self-hoster should not need an account on
someone else's forge to get the app for their own notes.
Server side only. CI bakes nothing new until step 3 and the UI reads nothing new
until step 4, so this lands green and inert.
Five rows — android, linux-deb, linux-pacman, linux-appimage, windows — each
naming its artifact, sidecar and mimetype. Fixed filenames, version only in the
sidecar: a version-stamped name would force a glob, and a glob over a directory an
operator drops files into is how you serve the older of two builds, which is the
failure write-manifest.sh already carries a comment about.
THE ANDROID NAMES AND ROUTE DO NOT MOVE. The lane publishes those exact filenames,
clients in the field poll /api/client/android, and `android_client` stays on
/api/config beside the new `clients` map. Renaming them to match the pattern would
buy tidiness and strand every installed phone; retiring the key belongs to a later
change made when nothing polls it, not to the change introducing its replacement.
Fields were added, not moved — `ClientRelease` in core is a plain serde struct and
ignores what it does not know.
PRECEDENCE IS PER PLATFORM, which is the trap the table introduces. "First
directory holding anything wins" would mean dropping in an APK silently retracts
the four desktop downloads. Pinned by a test.
The AppImage needs a third file. It is the only bundle that replaces itself in
place, so the updater verifies a minisign signature before it does — and a bundle
that cannot be verified cannot be offered. A missing or empty `.sig` therefore
makes it absent rather than merely unsigned, and the signature travels WITH the
version so an updater can never pair one build's version with another's signature.
The tests parametrize over the table instead of testing Android and trusting the
rest. The bugs this module can have are not platform-specific, and a suite that
only exercised one platform is how the other four would ship untested.
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.
It existed for one window: `stable` was a manifest-only pointer at whatever `v*`
tag had last been cut, and `stable` is the DEFAULT channel, so without the
fallback `curl … | sh` was broken for everyone between step 3 landing and the
first merge to `main`. That merge happened (`b6673c6`), and `stable` now holds
its own signed bundles at 1.0.3503145 — AppImage, deb and pacman, all resolving
by the one lookup both channels share.
Kept as a fallback it stops being a safety net and becomes a mask: the branch
only runs when `stable` has no bundles, which from here on means something is
broken, and chasing a `v*` release instead of saying so is the wrong answer.
The header now says the transition is finished and that neither channel should
be special-cased again, because the shape of that code invites re-adding it.
The first merge to `main` took the Android lane down (run 4857): the decide
job exited 1 in 0.16 seconds with no output at all, and the image build
skipped behind it because a failing lane must not publish.
`stable` had never published an APK, which the guard treats as a pass — there
is nothing to go backwards from, and `[ -z "$published" ]` says so in a branch
of its own. That branch was unreachable. `published="$(published_for ...)"`
under `set -e` dies on the substitution before it, and everything the pipeline
would have printed goes into the capture rather than the log.
What decided which lookups had the bug is the last command in the pipeline.
`sed` on empty input exits 0; `grep` exits 1. Three of the four end in `sed`.
Android's version_code ends in `grep -oE '[0-9]+$'`, so it was the only one —
and only on a channel with nothing on it, which is why a week of dev pushes
never saw it.
The tests now reach the half of the guard that talks to a feed, with `curl`
shadowed on PATH so they stay hermetic: an empty channel passes and builds, a
lower published version passes, a higher one fails the lane, and an equal
Android code is refused because Android will not install it.
Step 7 of M314, the last one. Rule 22 — the old path comes out completely.
## A release stops building
`desktop.yml` no longer triggers on `v*`, and its two `Publish release` steps
are gone. `ci.yml` lost its tag trigger in step 6. So a tag now reaches exactly
one lane: the new `release.yml`, which builds nothing.
That is not a simplification for its own sake. The merge to `main` already
published everything a user can receive — `:latest` + `:<sha>`, both channel
feeds, the updater manifest. A tag rebuilding that source produces identical
artifacts under identical names and re-pushes `:<sha>` with different bytes,
which rule 145 forbids even when they match.
## So what a release is FOR
The changelog (note 3127 §5). Two halves to "what am I running", and the
version answers only the first: which build is this (the footer, /api/config,
the APK's versionName) and what is in it that was not in the one I ran last
month (nothing, until now).
`packaging/release-notes.sh` derives it from git rather than a hand-maintained
CHANGELOG, which drifts into recording what someone MEANT to ship. Capped at 60
entries with the omitted count stated — the first dated release spans 181
commits since `v0.1.0`, and a truncated list that does not say it is truncated
is a lie.
It publishes through `publish-release.sh` rather than making its own API calls,
for the create-or-PATCH-on-409 path: a fixed-tag release that only ever POSTs
keeps whatever body its first run wrote, which is #2182, and reimplementing that
correctly in a second place is how it comes back.
## Retired
`MANIFEST_TAG` and the whole branch behind it. It let the manifest live on a
`stable` pointer release while the bundles sat on a versioned one — a split step
3 removed when `stable` started holding its own bundles. Nothing had passed it
since; a parameter that can only ever receive its own default is a branch nobody
exercises and a comment that goes stale, and its stale text was still telling
readers the installable builds live on the versioned releases.
`desktop/src-tauri/Cargo.toml`'s version and `thoughtsync/__init__.py`'s both
now say out loud that they are not shipped values. The Cargo one carries the
history worth keeping: the old scheme took its base from that line, so `0.2.<run>`
on dev outranked a bare `0.2.0` on main, and the remedy was "remember to bump the
minor before tagging" — documented in a comment, enforced nowhere. #2183 is what
that looked like in the field. **That ritual is now formally dead**, and this is
the deliberate act of killing it rather than a side effect.
## Still there on purpose
`install.sh`'s transitional stable fallback. It cannot go until `main` has
published to `stable` at least once, and that is gated on an operator request.
Removing it now would break the DEFAULT install channel.
#3147
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Rule 145 promises every push to `main` publishes a `:<sha>`, so any production
commit is addressable without a release ceremony. `ci.yml`'s `paths:` filter
quietly broke that: a commit touching only docs never triggered the lane, so
that commit had no image and no sha tag.
Pre-existing — the filter has always been there — but it is rule 145's guarantee
and step 6 is where the tag set is being made to match the rule, so it is this
step's to close.
Confirmed live on a0c789b: a docs-only push produced two runs, both client lanes
skipping correctly, and NO image at all.
The server image now always builds. It is the cheap one — ~15 seconds against 6
and 9 minutes for the clients, which is exactly why they skip and it does not —
and always building is what keeps `python:3.12-slim` fresh on something that can
face the internet. That is also why §4's base-image tension does not bite this
project: the artifact it would apply to is the one that never skips.
#3146
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`:<git-sha>` is on `main` only now — a sha tag per dev push was a rollback
target nobody had ever pulled — and `:<version>` never existed as an image tag
after rule 145 was narrowed. Both were still documented.
`docs/android-distribution.md` also said `:dev`, `:latest` and `:<version>` all
ship a client, which is now two-thirds true and misses the more useful fact: the
channel IS the image you run, so a stable server serves a stable client. Worth
saying because until step 3 it was hard-wired to the dev release on every branch
and did the opposite.
This push is also the skip-if-exists verification. It touches neither client's
file set, so both `decide` jobs should report the channel already serving the
current version and skip a 6- and a 9-minute build — while the guard still runs
on that path (§6.3).
#3146
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Step 6 of M314. Two changes that only make sense together.
## The image tag set rule 145 mandates
dev push -> :dev
main push -> :latest + :<sha>
a v* tag -> nothing; the trigger is gone
`:<sha>` was going out on EVERY branch — a rollback target nobody has ever
pulled, accumulating forever, for a channel whose entire contract is that it
moves. It is on main only now, where rollback matters and where gated merges
(rule 2) make it dozens per year rather than one per push.
No version-shaped image tag in any lane. Verified the way rule 145 asks — by
looking for a CONSUMER, not for whether one is imaginable: `docker-compose.yml`
is parameterised for a pin and the docs describe the option, but no compose
file, deploy script or CI job reads one.
## Skip-if-exists, adapted, because §4 assumes a registry §5 removed
Note 3127 §4 says to ask the registry whether that exact version exists. There
is no `:<version>` tag to ask about any more. What there IS, for both clients,
is a channel that publishes the version it serves — and that answers the same
question: if the channel already serves what this source derives, the artifact
would be byte-identical.
So the `paths:` filters are gone from the desktop and Android lanes, replaced
by a `decide` job reading the real file set. That duplication is not
theoretical: `packaging/` was added to the sets and not to the filters, so the
commit that fixed a derivation bug never ran on the two lanes it fixed
(85ead4d). One definition, one reader.
The cost is that both workflows now start on every push rather than a matching
one — a ~15s container for a decision, against a lane that cannot silently fail
to run.
## The server always builds, deliberately
Its image is ~15 seconds against 6 and 9 minutes for the clients, so there is
little to save. And always building is strictly BETTER for something that can
face the internet: it picks up `python:3.12-slim` base updates on every push.
That also dissolves §4's base-image tension for this project rather than
deciding it — the artifact most exposed to base staleness is the one that never
skips. Resolving a base digest at derive time was the alternative and it is
forbidden: §7's corollary bars an external lookup, because two lanes would then
derive different values for one source.
## The guard runs on the skip path
It moved into `decide`, ahead of the decision. §6.3 is explicit that skipping
because "this version already exists" is indistinguishable from "we derived a
stale value that happens to match" unless something checks. It also now runs
once per lane instead of once per job.
## Two defects found while wiring this
`ci.yml`'s gate greps a path list that MUST match Android's file set, and
`packaging/` was missing from it. A packaging-only push would have had the
Android lane build and dispatch while the gate ALSO let the image through —
two images for one commit, and on main a second push of the same `:<sha>` with
different bytes. Rule 145's exact prohibition.
`guard-forward.sh` ends every fetch in `|| true`, so a runner image without
curl would have read as "nothing published yet" and passed without checking
anything. Missing curl is now fatal.
#3146
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Step 5 of M314, note 3127 §6.3. Everything else in this milestone derives a
number and trusts it; this compares the derived value against what the channel
is actually serving and fails the lane if it went down.
Too-low is the unrecoverable direction: every installed client reports "up to
date" forever, and no later build fixes it until one climbs back above the bad
number. #2183 and #2993 are both that symptom.
## Two hazards, two mechanisms
A shallow clone is now tested DIRECTLY, in `version.sh`, via
`--is-shallow-repository`. The empty-result guard only caught the case where
nothing matched — and run 4796 showed the worse one, where a partial match
returned a real six-days-stale answer. Asking the question outright costs no
network and covers artifacts with nothing published to compare against.
`guard-forward.sh` handles the rest: a squash or rebase merge rewriting the
committer date, a rebuild of an older commit, and clock skew between runners.
## The comparison is per artifact, and the operator differs
desktop derived >= published commit time, so equality is the ORDINARY
no-change case and `<=` would fail every
build that changed nothing
android derived > published build time, so equality means two builds in
one minute — and Android refuses to install
an APK whose versionCode does not RISE
The server is deliberately unguarded: nothing compares its version, `:latest`
moves regardless, and rule 145 removed the version tags that would be the
published list. A too-low value there is a wrong date in a footer, not a
stranded client. It still gets the shallow-clone check.
## Proved to fire, not assumed
Cloned the repo, checked out a commit eight back, ran the guard against the
LIVE dev feed:
at the tip derived 1.0.3502151, published 1.0.3502151 -> pass
eight back derived 1.0.3501535, published 1.0.3502151 -> FAILS
android tip derived 3502171, published 3502152 -> pass
stable derived 1.0.3502151, published 0.2.0 -> pass
That last row is worth keeping: stable still advertises the bare `0.2.0` from
the old Cargo.toml scheme, so the transition orders upward on BOTH channels,
not just the one being exercised.
A channel with nothing published passes rather than failing — otherwise the
first publish to a new channel could never happen.
The guard runs BEFORE the build in all three lanes, so a bad derivation costs
seconds rather than a five-minute compile and a publish to undo.
`compare` is exposed as an explicit mode so the ordering is testable without a
network and inspectable without a push — 16 cases including `1.0.9 < 1.0.10`,
which a string compare gets exactly backwards.
#3145
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`85ead4d` changed `packaging/version.sh` — the script that decides what every
artifact claims to be — and the desktop and Android lanes did not run at all.
Only CI & Build fired, and only because it happens to watch `tests/**`.
So the fix in that commit is unverified on exactly the two lanes whose bug it
was fixing.
`version.sh` lists `packaging` in all three file sets; the workflows' `paths:`
filters did not. Two places holding one decision, with one of them updated —
the failure this subsystem keeps producing (#2181-2183, and again in step 3
where `install.sh` still expected stable's bundles on a versioned release).
The script's own header already warned about this: "a change here that is not
mirrored there means a lane that does not fire — check both." Written, then
not followed, in the same commit.
Step 6 removes the duplication for real by replacing these filters with
skip-if-exists. This is the stopgap until then, and it says so at each site.
#3144
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three failures on c504433, two root causes, and the interesting one is that
`git log -- <paths>` resolves pathspecs against the CURRENT DIRECTORY.
Callers run from wherever suits them: the desktop build from
`desktop/src-tauri`, the Android build from `android`, the manifest job from
the root. So one push produced THREE versions:
desktop build 1.0.3494522 <- six days stale
pacman packager 1.0.3502131
manifest job 1.0.3502131
The build's pathspec had matched `desktop/src-tauri/Cargo.toml` — a real file
— so git answered with the newest commit touching THAT. Non-empty, so the
shallow-clone guard could not fire; the manifest then found no bundle matching
its own answer and the lane went red two steps from the cause. The Android job
failed loudly in the same run only because ITS pathspec happened to match
nothing from `android/`. Same bug, luckier symptom.
The script `cd`s to `git rev-parse --show-toplevel` before doing anything now,
and the test asserts every artifact answers identically from four directories.
## And a third instance of the trap that bit yesterday
The unit test caught it: `version.sh display nope` printed "unknown artifact"
to stderr and then answered `2026.08.28.0900` with exit 0. `paths_for` is
reached through `$(paths_for "$1")`, so its `exit 2` ended the subshell,
returned an EMPTY pathspec — and an empty pathspec matches everything.
That is now three occurrences of one mistake in one file: the shallow-clone
guard on `key` (emitted `1.0.-26297280`, exit 0), the same guard on `display`
(which failed only because `date` then choked on the empty string), and this.
Each was found by a different mechanism and none by reading the code. The
artifact is validated in the parent shell now, and the file says so where the
next guard would be written.
Both tests assert on STDOUT as well as the exit code. The exit code alone
passed for `display nope` while stdout carried a lie.
#3144
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Step 4 of M314. `desktop/packaging/build-version.sh` was one generator feeding
the desktop bundles AND the Android APK off `GITHUB_RUN_NUMBER`, so a
Kotlin-only commit re-versioned the desktop and a Rust-only commit
re-versioned the phone. Note 3127 §3 cites this repo as its example of that
failure. It is replaced by `packaging/version.sh` — one definition of HOW to
derive, three file sets, and the sets in one place.
Lives at the repo root rather than under desktop/, because it serves three
artifacts now and a shared thing filed under one consumer ends up owned by it.
## Two values, and the clock chosen per value (§2)
desktop key 1.0.<minutes since 2020-01-01> commit time
desktop display 2026.08.28.0900 commit time (#3181 shows it)
android versionName commit time
android versionCode <minutes since 2020> BUILD time
server version 2026.08.28.0900 commit time, no ordering key
Every human-readable version in the repo is now one shape. The two exceptions
are not version names at all — they are bare monotonic integers a comparator
reads and nobody quotes.
The desktop needs a separate key because Tauri parses `latest.json` with the
semver crate and `2026.08.28.0900` fails it twice (four segments, and `08` is a
leading zero). `1.0.` and not `0.0.`: the minor has to clear the installed
`0.2.466` line or every dev user is stranded on "up to date" permanently.
Android's code comes from BUILD time while the desktop's key comes from COMMIT
time, deliberately. Android hard-fails a downgrade with
INSTALL_FAILED_VERSION_DOWNGRADE and leaves a channel you cannot get out of, so
its key must be monotonic by construction; the desktop merely declines to offer
an update, which a guard can catch.
## The bug this found in itself
The shallow-clone guard `exit 1`-ed inside a function called as `$(...)` —
which ends the SUBSHELL, not the script. `display` still failed, but only
because `date` then choked on the empty string. `key` printed the error to
stderr, emitted `1.0.-26297280`, and exited ZERO.
That is precisely the failure the guard exists to prevent: a too-low version on
a green lane, and too-low is the direction you cannot recover from. It resolves
into a global in the parent shell now. The test is parametrized over both
requests, because one path was covered and the other was broken in exactly the
way the covered one was meant to rule out.
## Also
`fetch-depth: 0` on every job that derives — four of them, and only ci.yml's
gate had it. Depth-1 is silently wrong rather than loudly broken (§6.1).
The file sets include each artifact's BUILD RECIPE (its workflow, and
`packaging/`). A workflow file is not shipped, but change a Gradle flag and the
bytes change while the source does not — and once step 6 skips a build whose
version already exists, that serves the OLD artifact on a green run.
The base images are deliberately NOT resolved at derive time: that is an
external lookup, which §7's corollary forbids. `Dockerfile` is already in the
server's set, so pinning `FROM` by digest in step 6 puts the base inside the set
for free.
`build-version.sh` is deleted, its last consumer (the pacman packager) moved
over, and the one finding worth keeping out of its header — why not a `-dev.N`
prerelease — is preserved in the successor.
#3144
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Step 3 of M314. Note 3127 §0's diagnostic is "is `main` publishing
sufficient for a user to receive the build" — and here it was not. The
desktop and Android lanes BUILT on main and published nothing: `Publish
release` was gated on `refs/tags/v*`, the channel publishes on
`refs/heads/dev`, the manifest job on dev-or-tag. So the stable channel
moved only when somebody cut a tag, which made a `v*` tag load-bearing
rather than the optional bookmark the model wants.
Both channels are rolling fixed-tag releases now. `dev` from dev, `stable`
from main, same machinery — `publish-release.sh` already took RELEASE_TAG,
`write-manifest.sh` already pruned, and both already PATCHed a stale
description on 409 (#2182). This is wiring, not new mechanism.
## The defect this carried
`ci.yml`'s "Fetch the Android client to bake in" read
`releases/download/dev` UNCONDITIONALLY, on every branch. Every image baked
in the dev APK — `:latest` included — so a stable server served a
dev-channel client to anyone who downloaded it from there. That has nothing
to do with versioning; it is fixed here because this is the step that
finally gives `stable` an APK to point at.
It also means Android needs no channel machinery of its own. The APK is
served FROM the image, so the channel is already a property of which image
you run — note 3127 §7's "nothing to hand off" shape, arrived at here by
accident. One branch-conditional line, not a second channel in
`client_dist.py` as this milestone first assumed.
## The break this nearly shipped
`install.sh --channel stable` read the version out of `stable/latest.json`
and then fetched `releases/tags/v<version>` for the bundles — correct while
stable was a manifest-only pointer, and broken the moment stable holds its
own. Stable is the DEFAULT channel, so `curl … | sh` would have failed for
everyone between this commit and the first merge to main.
Both channels are one lookup now: fetch the fixed-tag release, install what
is on it. A transitional fallback covers the window where `stable` still
has no bundles, marked for deletion in step 7 — without it the default
channel is broken for however long it takes to merge, and that window is
gated on an operator request rather than on this lane.
## The two writers problem
`stable`'s manifest was written by tag builds. It is written by main now,
and the tag path stops writing it — two writers for one channel is a race
with no winner worth having. A `v*` tag still writes its own versioned
manifest; its build consequence goes entirely in step 7.
Also corrected: `update.rs`'s header still described stable as following
`v*` tags. Nothing in that file moved — it only ever read
`<channel>/latest.json` — but the comment was a lie, and it is the file
somebody reads to understand the feed.
#3143
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`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>
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>
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>
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>
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>
`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>
`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>
Found by the Scaffold audit #2951 asked for. Three Scaffolds exist; the editor
and the sync screen both consume the IME inset, and the board consumed nothing.
`enableEdgeToEdge()` makes the manifest's `adjustResize` a no-op on API 30+, so
nothing resizes for the keyboard unless the app asks — and
`ScaffoldDefaults.contentWindowInsets` is systemBars, which the IME is not part
of. The Scaffold positions the FAB and the snackbar host from that value, so
with the search field focused both sat under the keyboard.
Not theoretical, and newly load-bearing: `3f0eef1` put an UNDO on the trash
snackbar, so the one control you could not reach was the one that takes back a
note you did not mean to throw away — reachable by searching, long-pressing a
hit and trashing it.
`union` rather than `add`: the navigation bar and the IME are the same edge,
not two stacked ones, and adding them would inset twice under a keyboard that
already covers the nav bar. Set once on the Scaffold rather than per-slot, so
the content column shrinks with it and the board's cards stay above the
keyboard instead of scrolling under it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two failures on `3f0eef1`, both ktlint, both mine.
`chain-method-continuation`: a multiline element in a Modifier chain wants the
next `.` glued to its closing paren — `).background(…)`. Every other multiline
chain element in this codebase happens to be LAST in its chain, so nothing had
exercised the rule before. `combinedClickable` is now a named `opening`
modifier applied with `.then(…)`, which keeps the chain single-line per element
and reads better than the shape ktlint was asking for.
`no-unused-imports`: lifting the delete-forever dialog into Panel.kt took the
last use of `Text`, `stringResource` and `R` out of NoteEditorScreen.kt with
it. I had checked AlertDialog and TextButton and stopped there.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Trash existed on Android and was three interactions deep — open the note,
tap the overflow, Move to trash — with nothing at all on the board itself.
The operator's read of that was not "the actions are in the editor"; it was
"there are no long hold context menus in the app I have no way to delete
notes." (#2946)
The card now takes `combinedClickable` and raises a DropdownMenu holding the
same items as the editor's overflow, in the same words, from the same string
resources, dispatching the same `EditorAction`s through the same
`BoardViewModel.onEditorAction`. A note has one vocabulary of things you can
do to it, and reusing the exhaustive dispatcher means the board cannot grow a
parallel one that drifts.
Gated on `note.trashed` rather than on the board's destination — the same
reading the editor uses for read-only, and the only one that survives
Reminders and search, which both mix piles.
Trash gets an UNDO snackbar rather than a confirmation. A long press is a
gesture you can make by accident, so the mistake worth designing for is the
one nobody meant to make, and a dialog only helps someone paying attention in
the moment they were not. Delete forever keeps its dialog; that one does not
undo.
`MenuItem` and the delete-forever dialog move to Panel.kt now that two
surfaces raise them, so there is one place for the close-before-acting order
and one wording of the consequences.
Colour is deliberately not in this menu, though #2946 suggested it:
`note.color` and its picker come out in #3041, so a swatch row here would be
building the one control already known to be leaving.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`cargo fmt --all --check`, the only failing gate on d9e5753 — clippy, all 148
tests and every other lane were green. The line was 96 characters, under the
100 max_width, but a chain is held to `chain_width` (60% of it).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Step 2 rewrote the notes already on disk and, because the sync_revision
trigger fires, every client pulls them. So this is not about existing notes.
It is about the ones typed from now on.
Without it: you type `#todo` on its own line, the core stores it as written,
and a second later the push comes back and the text disappears under you.
Offline it never lifts at all until you reconnect. Two surfaces disagreeing
about what a note says is the thing this codebase mirrors rules to avoid.
`lift_standalone_tags` in derive.rs is the mirror of `split_body_tags`, case
for case, with the same two guards — a fenced line is code and is never
touched, and a note that is nothing but tags keeps its text.
ONE SCANNER, not two. `extract_tags` is rewritten over the same `line_tags`
the lift uses, so the two cannot disagree about what a tag is. Line-by-line
changes nothing, since a line start and a `\n` are both boundaries, and the
existing tag tests still pin it.
Char indices rather than byte offsets for the spans, because they are used to
cut the tags back out of the line and a byte offset can land mid-codepoint.
`sync_tags` becomes `lift_and_sync_tags` and is named for the mutation: it
now rewrites notes.body, and all three callers write the body immediately
before calling, so it overwrites what they wrote on purpose. The graduation
case is handled the same way as on the server — flip the row before the
delete pass, or the same row is dropped for no longer being in the body and
the tag is silently lost.
One thing the server needed and this does not: display_title. The core
derives it on READ rather than storing it, so there is no persisted copy to
go stale.
The rename was done with a lookbehind rather than a plain substitution, after
the same operation an hour ago turned the function it had just written into
`_lift_and_lift_and_reconcile_tags`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Step 1 made new saves lift; this does the ones already on disk, so a note
stops showing its tag twice without having to be opened.
Same rule, and a FROZEN copy of it — `split_body_tags` is deliberately not
imported, on 0027's principle that a migration has to keep producing what it
produced the day it ran. If the app's rule is ever loosened, this file must
not loosen with it and start eating prose it previously left alone.
`_display_title` is inlined for the same reason, and recomputed only for a
note whose body actually moved: a note named after its `#todo` line needs a
new name.
The label rows graduate in the same transaction, and that is not cosmetic. A
`via_tag` row claims "backed by text still in the body", and reconcile
detaches any row it cannot find a `#tag` for — so leaving them true would
lose every lifted tag on the note's next save. Flipping them to false is also
what makes the chip's × appear, which is now the only way to remove a tag
whose text is gone.
`updated_at` is left alone so a client holding an unpushed edit still wins
under LWW. The `sync_revision` trigger does fire, which is wanted here: unlike
0027 the clients do NOT yet apply this rule locally, so the server's copy is
the only correct one until step 3.
The downgrade is empty and says why. It cannot restore the deleted lines —
nothing distinguishes one this migration removed from one that was never
there — and flipping the rows back would be actively harmful, since the text
that flag claims backs them is gone and the next save would then detach the
label for real.
Tested on the ten cases that matter, three of which are prose that must come
back byte-identical. The test pins the frozen copy against fixed expectations
rather than against the app's rule — they are allowed to diverge later, which
is the whole point of freezing one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`sed s/_reconcile_tags/_lift_and_reconcile_tags/` ran over tags.py after the
new function was already written with the new name, so the definition became
`_lift_and_lift_and_reconcile_tags` while all 15 call sites were correct.
Twelve test modules failed to import.
The check that should have caught it is the reason it got through: the
verification grep piped output through `sed 's/:.*_lift/: _lift/'`, which
trims to the LAST `_lift` and therefore prints a doubled name identically to
a correct one. A filter that can only make wrong output look right is worse
than no filter.
Same sed also clobbered the docstring's historical reference — it read "it
used to be `_lift_and_reconcile_tags`", naming the function after itself.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A tag was shown twice: once as the `#todo` you typed and once as a chip. The
chip moved to the top of the card in 23fd2da; now the text goes — but only
when the tag was the whole line.
THE RULE: a line containing nothing but tags and whitespace is removed.
Anything else is untouched.
That is the conservative reading of "standalone" and it is the operator's:
"only lift standalone tags, leave mid-sentence ones alone". The looser
reading, also stripping a trailing tag off a prose line, is rejected because
the text does not say which kind it is — `buy milk #grocery` is filing,
`remember to call #mom` is the sentence's object, and lifting the second
leaves "remember to call". Mangling a sentence to save a duplicate chip is a
bad trade.
Two guards. A line inside a ``` fence is never touched: a `#tag` there is a
shell comment in somebody's snippet, and deleting it would eat a line of
their example. And a note that is NOTHING but tags keeps its text rather than
being blanked — a duplicated chip beats an empty card.
WHY THIS IS NOT JUST A TEXT EDIT. `via_tag` labels are DERIVED from the body:
reconcile detaches any row no longer backed by a `#tag`, and the picker only
manages `via_tag=False` rows. So a naive lift deletes every tag on the next
save, and leaves them unremovable until then.
Resolved by giving `via_tag` a sharper meaning — backed by text still in the
body — rather than deleting it:
standalone lifted, attached as an ORDINARY label. Nothing derives it any
more because nothing is left to derive it from.
inline left in place, still derived, still detached when its text goes.
Which costs nothing elsewhere, because both editors already gate their remove
button on `!via_tag` (NoteEditor.vue:618, EditorChrome.kt:349). A lifted tag
gets its × for free — and needs it, since deleting the text is no longer a
way to remove one. No wire change, no column drop, no UI change.
A tag that GRADUATES from inline to standalone is the sharp edge: its row has
to be flipped before the detach pass, or the same row is dropped for no longer
being in the body. That is the bug, and there is a test on it.
The lift and the display_title re-derivation both live inside the function,
which is renamed to admit it mutates the body. All seven call sites derive
display_title BEFORE calling, so anywhere else and every note would be named
after a line that had just been deleted. Spreading a derived-value update
across seven write paths is the failure #2965 named: "easy to miss, and it is
the common one".
Existing notes lift lazily, on their next save. The migration that does the
rest is step 2, and the core's own copy of the rule is step 3.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
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>
MagicNumber's ignore list is -1/0/1/2, so the `3 ->` and `4 ->` branch
labels were findings. A lookup table has no literals to flag, and it is the
form colors.ts already uses — the two now read as the same function rather
than as two people's idea of it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
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>
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>
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>
`noteIsStrong` had a single-line body expression wrapped onto the next line;
ktlint's function-signature rule wants it on the signature line when it fits.
`firstLabelColor` wrapped a call chain after `note.labels.firstOrNull()`, and
chain-method-continuation wants a newline before EVERY link once one is wrapped.
It reads better as two statements than as a chain, so it is two statements.
Third ktlint round trip on this milestone. I pre-flighted the rules I already
knew and these were not among them — and when I then wrote greps for the two new
rules, they flagged sixteen files that have been passing for months, because my
heuristics do not match what the rules actually check. There is no local ktlint
(rule 10), so CI is the first and only reader; more elaborate greps are not the
fix, and pretending they are would just add false confidence.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
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>
`resolvedNoteColor` and `noteTintFor` are the first non-composable functions
here to take more than one parameter, and ktlint_official's function-signature
rule requires each parameter on its own line once there are two or more. Four
findings on one and four on the other, all the same rule.
Nothing had type-checked: ktlint is step 6 and the unit tests are step 8, so the
fixture pinning the derived-tint mirror never ran.
I checked line width, trailing whitespace and KDoc adjacency before pushing —
the three that have bitten before — and not this one. The list of rules learned
by failing CI is not the list of rules.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
`dev` went red on 1e2b42a and nobody was watching — the CI wait was killed with the
session, so the push was never confirmed. Checked on the way back in.
Both findings are ReturnCount: four exits against a limit of two. The same rule
caught continueChecklist earlier the same day, which is the annoying part — I had
the lesson and wrote two more guard-clause ladders anyway.
checkInBackground becomes a `when`, which it wanted to be regardless: it is four
mutually exclusive situations and one action, and the ladder made that read like a
sequence of unrelated escapes.
onWifi folds its three null checks into one nullable chain. Same behaviour, and the
`caps != null &&` reads as what it is — an uncertain answer being treated as no.
Both corrections to what I built, and the second changes the first.
NAG ONLY WHEN READY. The banner is now gated on the bytes being on disk. I had it
appearing as soon as a build was FOUND, with Install downloading on demand — which
turns one tap into an unplanned download, and is exactly the surprise the wifi gate
was meant to avoid. Off wifi the app now stays quiet and picks it up later.
ONLY ON WIFI, and both halves of that. `isActiveNetworkMetered` alone would download
over an unmetered cellular plan, which is not what "on wifi" means. TRANSPORT_WIFI
alone would download over a tethered hotspot, which is mobile data wearing a
different hat and the precise bill this avoids. It now requires both.
Found while making the first change: gating the nag on `ready` broke the nag. The
background path returns early once a build is fetched, so `nagDismissed` would never
be cleared again and a single "Later" would have silenced the update permanently —
the exact "lost" this whole path exists to prevent. Coming forward with a fetched
build now clears the dismissal instead of returning.
Also: a build found off wifi retries its FETCH on the next foreground rather than
waiting out the six-hour check interval. Found on the train, downloaded at home.
The banner loses its two-state text with the change, and BoardUpdate loses `ready` —
it is implied now. It stays visible while installing, deliberately: that is the one
moment it has something to report, and hiding it would look like the tap did nothing.
Anchoring the new function on `fun downloadTarget` put it between that function
and its own KDoc — so downloadTarget lost its doc and onUnmeteredNetwork gained a
second one describing something else entirely. ktlint caught both halves.
Anchor on a declaration and you land inside its documentation. Swept the rest of
the tree for the same shape; nothing else.
`check()` had exactly one caller: a button on the sync screen. So a new build was
found only by someone who went looking for one — and having to remember to go
looking is the same as not being told. The operator has been doing that by hand
every time.
Three parts.
FIND. The app checks when it comes forward, which is the moment the person is
present. Rate-limited to six hours in the view model, so flicking between two apps
is not a re-check, and skipped entirely on an unlinked device — updates come from a
linked server and there is nothing to ask. Same ForegroundTransitions shape as
AutomaticSync, for the same reason.
FETCH. Finding one downloads it, so the nag is a one-tap install rather than the
start of a wait. NOT over mobile data: fifty-odd megabytes is a bill nobody agreed
to, so this is gated on an unmetered connection (new ACCESS_NETWORK_STATE
permission — normal, no prompt). On a metered link the update is still found and
still nags; Install downloads it then, which is a choice rather than a surprise.
NAG. A banner on the board, under the error banners — an update is worth saying and
never worth saying before a note failed to save. "Later" clears it for this sitting
only: the next time the app comes forward the check finds the same build and says so
again. That is the difference between a reminder and a notice you can lose.
downloadAndInstall now skips the download when the background fetch already did it,
so the sync screen's button and the banner's are the same action with the same
name — whether the bytes are already there is this class's problem, not the
person's.
Second pass on the same report. Taking the field's own padding off got rows from
57dp to 48dp and the operator said it was still too big — correctly, because 48dp
was never the field's, it is Material's minimum touch target and every interactive
component gets it.
On a checklist that minimum IS the row height. It is the right floor for a control
somebody has to find on a screen; it is the wrong one for a box that sits in a
predictable column with an identical box directly above and below it, where a near
miss ticks the neighbouring item — visible, and undone by tapping again.
36dp, provided to the row rather than hardcoded into the controls, so the checkbox
and the delete × move together and nothing else in the app is affected.
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.
Two things, one of which I got wrong in a place that outlives the session.
**The claim.** Migration 0027's docstring said "The Google Keep import is genuine
content on this instance, not fixtures." That is not true and I had no basis for it.
Note 2916's headline is the opposite — "there is no work that anyone has done that
isn't test data" — and its clause about imports is CONDITIONAL: text arriving from
another app would be real, and any import path has to treat it that way. I read a
rule about how import code must behave as a fact about what is in the database, then
repeated it in a migration that will be read long after anyone remembers this week.
The operator has never run the importer. They did not know it existed.
Nothing about the migration changes. Content-preserving was cheap and is right for
anything that rewrites somebody's text — and it is what the rule will demand the day
an import does happen. Only the reason recorded in the file was wrong, and a wrong
reason in a migration is how a later decision gets made on a false premise.
**The delete.** Removing the FIRST checklist row asked to focus `index - 1`, which is
-1, so nothing took focus and the keyboard stayed up over a list with no cursor in
it. It now focuses whichever row takes the deleted one's place, which also does the
right thing when the deleted row was the only one — `withoutIndex` leaves a fresh
empty block behind, and that block is what gets the caret.
Found by reading the path the operator said they were about to test, rather than by
waiting for them to find it.
detekt's TooManyFunctions, at exactly the threshold. Worth taking as the signal it
is rather than suppressing: the file held the block MODEL — split a body, join it
back, add an item, drop one — and the COMPOSABLES that draw it, which are two jobs
that happen to share a data class.
EditorBlock.kt keeps the model and is pure: no Compose imports beyond the types it
stores, and testable on its own if it ever earns tests. BlockBody.kt keeps the four
composables.
afterEnter, withoutIndex and nextId become internal, since the UI half calls them
across the file boundary now. That is the one cost of the split and it is small —
same module, same package, and each says why in its doc.
Reported from the device with a screenshot: six items took up most of a phone
screen. The rows measured ~57dp apart, which is Material's TextField content
padding almost exactly — 16dp above the text, 16dp below, around a 24dp line.
That padding is right for a form field, where it is the difference between a
comfortable target and a fiddly one. On a checklist it IS the row height, so every
item was paying for a hit area the checkbox beside it already provides.
The editor's blocks drop to BasicTextField. Nothing about the "no box" treatment is
lost — PlainTextField exists to strip a container and an indicator, and
BasicTextField never had either, so there is nothing here to drift back into
existence. What it does not supply and BlockField now does: the text colour, which
defaults to Color.Unspecified and draws BLACK (the same default that made the
toolbar invisible in dark mode), the cursor brush for the same reason, and the
placeholder, which becomes a plain Text behind the field.
PlainTextField keeps serving the search box, the label picker and the sync-pairing
form — fields where Material's padding is what you want. Its TextFieldValue
overload went with the change: the editor was its only caller, and every remaining
one passes a String.
Rows are now bound by the 48dp checkbox rather than by the field. If that is still
looser than it should be, the next lever is the touch targets themselves, which
trades against how easy the box is to hit — worth looking at on a device before
spending it.
`toggle_at` existed to map a tap on `[ ]` inside a plain text field to an item, and
`continuation` to make Return start the next one. The block editor needs neither: a
checkbox is a real Checkbox, so it is tapped rather than located, and Return is the
field's own IME action rather than a shape recognised in a string.
Removed rather than kept for later (rule 22). Both were exported over the FFI with
no Kotlin caller, which is API surface promising something nothing does — and their
tests were weight on code nothing runs.
The section comment above them described the tap-in-a-text-field problem, which is
no longer the problem this pair solves. Rewritten to say what is actually there:
one function to read a body apart, one to put a line back together, and between them
Kotlin renders checkboxes without owning the grammar.
detekt's MatchingDeclarationName: a file whose only top-level type is EditorBlock
has to be EditorBlock.kt. The plural read better as 'the blocks and the machinery
around them', but the rule is about the type, and the convention here already works
that way — NoteCard.kt holds NoteCard plus its helpers.
Removing MIN_BODY_LINES took its declaration but left the newline in front of it,
so the file ended with a blank line. My pre-push sweep only looked for consecutive
blanks INSIDE a file and could not see one at the end — checked across the whole
Kotlin tree this time, not just the files I touched.
2992. A checklist item is a real Checkbox with its text beside it, so a box can be
ticked while looking at the note — which is what M304 left undone. It changed where
a checklist is STORED and never changed what the editor draws.
The body is split into blocks and joined back on every edit, so the note underneath
is the same markdown string it was this morning. Nothing below the editor can tell
this exists: no migration, no protocol change, no new shape on the wire.
A run of prose lines is ONE block, not one per line. Typing a paragraph has to feel
like typing a paragraph, and a separate field under every sentence would break the
caret mid-sentence. Only a checklist item earns a block, because only a checklist
item needs a widget.
Two things that look like detail and are not:
* A block carries its own TextFieldValue, and an ID that survives insertion.
Compose keys fields by position unless told otherwise, so adding an item would
otherwise move every caret below it up a row. Content cannot be that key —
two empty items are identical and neither is the other.
* Focus is hoisted to the screen rather than kept inside BlockBody, because the
toolbar's checklist button also asks for one. Two owners of one cursor is one
too many.
Return on an item makes the next item and puts the caret in it; on an EMPTY item
the block becomes prose, which is how a list ends and how you get a paragraph after
one — the same rule the plain text field used, now with somewhere to land. It
appends rather than splitting at the caret: splitting an item in two is a rarity,
and the caret is at the end for every ordinary use of that key.
The core gains `render_item` and `DerivedItem.line`; `item_lines` and
`checklist_lines` are gone, subsumed. Every renderer that walks a body line by line
needs the text, the state and the position TOGETHER — asking for them separately is
how two calls come to disagree about a body that changed between them. The card now
reads its items from the body for the same reason, instead of from note.items,
which is the same list by a longer route and one save behind.
WANTS A DEVICE PASS, and the focus behaviours are what to look at: return making a
row and landing in it, return twice at the end of a list getting you a paragraph,
and rotation restoring the right field. CI can only prove this compiles.
Reported from the device: tapping a checkbox on the board checks it AND opens the
note. The "and" is the tell — both things happened, so this was never a tap landing
on the wrong target.
`mutate` ends with `editing = updated ?: state.editing`. That is right for an editor
action, where the reloaded note refreshes a screen already on display. But
`editing != null` IS "the editor is up" — it is what MainActivity's `when` selects
on — so calling `mutate` from the BOARD, where editing is null, wrote the mutated
note into it and opened the editor as a side effect of saving.
Fixed at `mutate` rather than at the caller, because the caller was not wrong: any
board-initiated mutation would have done this, and toggleItem is simply the first
one to exist. It now refreshes an open editor and cannot open a closed one.
The comment claimed the narrower behaviour all along — "so an open editor shows its
own change" — which is what the code should have been doing and wasn't.
Not a style finding. `onToggleItem` was added to BoardScreen's signature and read
inside NoteBoard — which is a separate top-level composable, not a nested one, so
the two were never connected. detekt reported it as an unused parameter; the
compiler would have called it an unresolved reference. Neither had run: Kotlin is
compiled at the "Unit tests" step, which is gated behind detekt, so nothing in this
lane had type-checked the Android changes yet.
Threaded properly now, which is what makes ticking a box from the board actually
work rather than merely appear to.
Two more from reading it again with that in mind:
* `when { item != null -> … onToggleItem(index, …) }` would not have compiled.
Kotlin does not infer that a non-null item implies a non-null index, so the
index stayed `Int?` against an `Int` parameter. Both are in the condition now.
* continueChecklist had six returns against detekt's limit of two. Collapsed to
one `when`, with the two intermediate values guarded on `typedNewline` —
`caret - 1` is only a real index once it is known to be the newline just typed.
M304 step 7. The code change landed with the server half — _note_markdown's
`if items:` branch went, and the export payload stopped carrying an items array —
but neither had a test, and the failure mode is quiet: every list appears twice in
an export, then twice again when that export is imported back.
Three cases, and the third is the one worth having. An export taken BEFORE this
milestone has a body with no task lines and a separate items array, so importing
one still has to fold the checklist in. That is the same fold the Keep importer
does, and the reason _insert_note still accepts items at all — asymmetric on
purpose: the export stopped writing them, the import did not stop reading them.
Inserting the checklistLines import after Note split Note from NoteLabel, and
removing the checklistOpen state left two blank lines behind it. Both are the
formatter only — the bindings built and the Rust lanes were already green.
M304 step 6, and the surface with the least room to hide: Android has no markdown
renderer at all, so the card was about to show every list twice — once as literal
`- [ ] milk` in the body preview, and again as the glyph rows underneath. Same bug
the web had, one commit later.
The card now renders the body LINE BY LINE and draws a checkbox where one belongs,
which is what puts a list between two paragraphs instead of always after them. The
glyphs became tappable while they were being rewritten: ticking something off from
the board without opening the note is the common gesture, and the web just gained
it. The tap target is the glyph, not the row — tapping the TEXT still opens the
note, the way tapping anywhere else on a card does.
Kotlin gets no parser. Three implementations of the grammar is the price already
paid; a fourth in Compose would be a fourth place for a checklist to change shape
when it syncs. So the core exposes three pure functions instead —
`checklist_lines`, `checklist_continuation`, `checklist_toggle_at` — and Kotlin
does the caret arithmetic around them.
Those are FREE functions, not methods, and that is the interesting constraint. The
editor's body field is LOCAL state on an idle-debounced autosave, so anything that
edits a checklist there has to rewrite the text the field is holding, not a row the
store would hand back a moment later. Going through the store would overwrite
whatever was being typed. The BOARD has no such problem — nothing there is holding
a half-typed body — so the card's toggle goes through the store as usual.
`toggle_at` addresses an item by LINE and COLUMN rather than a text offset, because
the two sides do not count the same way: Compose measures in UTF-16 units and Rust
in bytes, so the same number means different places in a note with an emoji in it. A
line number is identical in every encoding, and so is a column inside the marker,
which is ASCII at the start of its line.
In the editor: the toolbar button inserts `- [ ] ` at the caret — the only toolbar
action needing no saved note, so it works on an empty compose box the moment it
opens — and Enter continues the list, or ends it on an empty item. Continuation is
recognised by SHAPE inside onValueChange (exactly one more character, and it is a
newline) rather than by a key event, so a paste or an autocorrect falls through
untouched.
EditorChecklist.kt and the four item actions are gone (rule 22). Adding, renaming,
ticking or deleting an item is editing text now, and the editor already does that —
through SaveText, with the same autosave and the same revision window as any other
edit.
KNOWN GAP, not an oversight: tapping a checkbox inside the EDITOR does nothing yet.
Material3's TextField does not expose onTextLayout, so mapping a tap to a character
offset means either moving the body to BasicTextField or intercepting pointer events
ahead of the field — both real changes to the surface this operator uses most, and
neither verifiable without a device. `checklist_toggle_at` lands here, tested, so
that task is pure UI. Ticking from the board works today.
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.
Three of them called derive_display_title(body, first_item). I updated the call
sites in src/ and not these — the integration lane and the linter both passed,
because a stale keyword argument is only a TypeError at the moment it runs.
Rewritten rather than deleted. The property the fallback existed to protect is
still real — a note that is only a checklist has to have a name — it is just
reached differently now: an item IS a body line, so the first one is simply the
first line with its marker stripped. The new cases pin the two edges that rule
introduces: an empty item must not name a note "", and a list of nothing but empty
items still has no name.
M304 steps 3 and the server half of 4. The client half landed in 668f7fa; these
belong in one deploy, and the protocol floor below is what enforces that.
notes/checklist.py is the Python half of a grammar that now exists three times —
here, core/src/local/derive.rs, and (next) frontend/src/notes/markdown.ts. That
triplication is the deliberate cost: the alternative is a round trip to the server
before a phone can draw a checkbox. Each copy names the other two, and each is
tested against the same table of cases, including the near-misses that must stay
prose: `-[ ] x`, `- []`, `- [ ]x`, a `[ ]` mid-sentence.
Routes: add/update/delete items stop touching rows and rewrite note.body, all
through one _rewrite_body that runs the same sequence the PATCH route runs for a
body change — because it IS a body change. Revisions, #tag reconciliation, the
name, and link unfurls therefore happen in one place rather than three routes each
remembering to.
The reorder route is gone (rule 22). Reordering a checklist is moving a line, and
no client ever called it — the only reference in the tree was a test asserting the
route existed.
The API still returns `items`, DERIVED from the body on the way out. That is not a
second source of truth and it cannot disagree with the body it came from; it keeps
the web client working across the rest of this milestone and saves any consumer
that only wants to draw checkboxes from carrying a parser.
Export drops its separate items block, in both formats. The body already ends with
those exact lines, so writing them again would double every checklist in an export
and then double it again on re-import. Import still ACCEPTS items, because a Keep
takeout has a list and not a blob; it folds them in before the Note is built, so
display_title and _reconcile_tags both see the finished text.
Protocol 3 on both sides now. A v2 client is refused rather than half-served —
which matters more than I first said: _apply_note_items returned early on an absent
`items` key, so an un-bumped v3 client against a v2 server would not have LOST the
rows, it would have kept them and then had the migration fold them a second time.
Duplicated lists rather than missing ones. The floor prevents both.
Migration 0027 folds every existing row into its note's body and drops the table.
It inlines its own copy of the fold on purpose — a migration has to keep producing
what it produced the day it ran — and a test pins that copy against the app's until
they are allowed to diverge. updated_at is deliberately untouched: a client holding
an unpushed edit keeps the newer timestamp, so last-write-wins keeps its work
instead of the migration silently winning.
The downgrade is honest rather than faithful. It recreates an empty note_items and
leaves the bodies alone, because once items are lines nothing distinguishes one this
migration wrote from one somebody typed, and a downgrade that guessed would eat
hand-written lists. Recreating the table is still necessary: 0015's downgrade drops
a trigger ON note_items, and IF EXISTS covers the trigger, not the table.
Three from the checker's own diff. Two are the rule I had guessed at: when a
call overflows and its last argument is a closure, rustfmt keeps the earlier
arguments on the line and expands the closure into a block, rather than putting
every argument on its own line.
The third is a stray double blank line before the test module.
M304 steps 2 and the client half of 4, together — they cannot be separated. A
commit where the store writes items into the body while push.rs still reads them
from a table is one that silently pushes the wrong list, and dev publishes to the
dev channel on every green build.
Store:
* load_items becomes items_of(body) — a parse, not a query. An item's id is its
ORDINAL, which is all it ever amounted to: push.rs sent text and checked and
never an id, and both sides replaced the whole list on every sync.
* add_item / update_item / delete_item route through update_note, so they get
revision snapshotting, #tag re-derivation and the dirty/updated_at bookkeeping
without any of it being written a second time.
* create_note folds its items: input into the body, and syncs tags from the
FOLDED body — an item can carry a #tag too.
* display_title no longer takes items, because items ARE body lines now. It
strips the task marker instead: a list-only note is still named by its first
item, and calling that note "- [ ] milk" would show someone the storage.
Wire: items leave it. A second copy of data already in the body field of the same
message is how the two come to disagree. CLIENT_PROTOCOL_VERSION and
MIN_SERVER_PROTOCOL_VERSION go to 3, which is what makes this safe to land before
the server: a v3 client refuses a v2 server outright rather than pushing a body
whose list the old _apply_note_items would then delete.
Schema v8 folds every existing row into its note's body before dropping the
table. Written in Rust, not SQL: the fold has to produce exactly what
derive::append_item produces, and group_concat only gained a guaranteed ORDER BY
in SQLite 3.44 — a checklist that quietly reordered itself during a migration
would be a poor way to learn that. updated_at and dirty are deliberately left
alone, because the server's migration folds the same rows the same way and both
sides land on identical bodies; marking every note dirty would push a body the
server already has, from every device at once.
NOT deployable yet. The server still speaks v2 and still has note_items, so a
client built from this will refuse to sync until the server half lands.
Three assertions I had collapsed to one line because they fit inside
max_width=100. rustfmt's fn_call_width is 60 and applies to the ARGUMENT list,
so a call can sit well under the line limit and still be split vertically.
Clippy and the tests were already green; this is the formatter only.
First step of M304. Additive on its own — nothing calls this yet — so it can be
read and tested before anything depends on it.
A checklist is currently a TABLE, and a table can only ever render after the
body, because a row has no idea where in the note it belongs. That is why
"inline with the note" is not a styling problem: prose, three checkboxes, then
more prose is not expressible at all today.
derive.rs already owns "structure derived from body text" for #tags and says so
in its module doc. Task lines join it rather than opening a second home for the
same idea. The difference between the two is worth stating and now is: tags
MATERIALISE into label rows because the board queries by label; items
materialise into nothing, because nothing queries them. Their only readers are
the card, the editor, and display_title.
The grammar is fixed here because three languages will implement it —
derive.rs, notes/checklist.py, notes/markdown.ts — and any difference between
two of them is a checklist that changes shape when it syncs. `*` is accepted
since markdown.ts already takes it for a plain bullet, and a rule that allowed
`* item` but not `* [ ] item` would be one nobody could guess. `- [ ]` with
nothing after it parses as an empty item: that is what pressing Enter on a list
leaves behind, and refusing it would make a half-typed list stop being a list.
`- [X]` parses and normalises to lowercase on the first rewrite, so round trips
are stable.
append_item spaces its output exactly as import_export.py:_note_markdown does.
That is not cosmetic — the server migration will fold existing rows into bodies
with the same layout, so an export taken before it and one taken after have to
agree byte for byte.
A stale index is inert rather than fatal: the index comes from a UI that may be
a moment behind the store, and a late tap should do nothing rather than panic.
Two reports from the same device pass.
**The exit is a checkmark.** It shipped as the word "Done" one commit ago, on the
argument that a tick in a NOTES app reads as a checklist item to anyone who has
used one. Overruled by the operator, and the filled treatment is what settles the
objection anyway: a tonal button in the note's own colour is plainly a control,
where a bare glyph beside a checklist would not be. It carries "Done" as its
content description, so the argument survives where it actually mattered — read
aloud.
**Starting a checklist wrote an empty item**, purely so the section would have
something to render. That left a blank row with the always-present add-row beneath
it — two empty fields, and the caret in the lower one. Whether a checklist is
SHOWING is view state, not a row in the store: the toolbar reveals the section and
focuses the add row, and nothing reaches SQLite until an item has words in it.
EditorAction.AddChecklist is gone rather than repurposed (rule 22), which makes the
first real item the action that can create a body-less note — a note named from its
first item, which the core already does.
Moving the toolbar to the top took the back arrow with it, and left the only
exit from a full-screen editor in the top-left corner — the furthest point on
the display from a right-handed thumb, reached over the whole note to get to.
Reported on the first device pass, and correctly.
So the footer carries a Done as well as the timestamp. With the keyboard up it
sits directly above the thumb, which is where a hand already is for every other
part of writing a note.
The top-left arrow stays. Two affordances for one action is usually clutter,
but this is the case that earns it: the arrow is what habit, the system back
gesture and TalkBack all expect of a full-screen surface, and removing it would
strand the reflex to strike a duplicate costing one icon slot.
A word rather than a checkmark, on the same argument the overflow menu makes: a
tick in a notes app is a checklist item to anyone who has used one, and "Done"
cannot be misread, including aloud.
EditorSavedLine is now EditorFooter, since it is no longer only a line.
The capture sheet's drag handle cost a strip of screen and did nothing a back
gesture does not already do. The toolbar takes that strip instead, which is
where it belonged once one surface served both writing and editing: the
keyboard owns the bottom of the display for most of a note's life, so a bar
down there spends its time riding on the IME.
The bottom is now the answer to "did that land". There is no save button —
writes are continuous, so a button offering to do what already happened would
be a lie with a tap attached — but that left nothing on screen saying the work
was safe. Not saved yet → Saving… → Edited just now is the whole lifecycle in
the corner, and someone who watches it once never has to be told that closing
a note keeps it. DateUtils formats the relative part, so plurals and
"yesterday" are not this app's problem to solve twice.
Shape: the screen keeps the sheet's rounded top and its gap below the status
bar, so opening a note still reads as something rising over the board. Full
height rather than a real ModalBottomSheet — a sheet spends a writing session
negotiating with the IME for the bottom half of the display, and the
swipe-down it buys is a gesture back already does.
Both content colours on the card are spelled out. Surface and Scaffold each
default theirs to contentColorFor(their container), which returns Unspecified
for anything that is not a colour-scheme role; a note tint never is. That is
the same default that made the last toolbar invisible in dark mode, latent in
two more places.
Also: the running LinearProgressIndicator is gone, since the corner line now
says the same thing without moving the text; and the SaveText comment in
BoardViewModel still claimed saves happened on close.
The + button raised a capture sheet with a single text field. The editor is
a screen with a toolbar. So a note being WRITTEN could not be given a
colour, a reminder or a checklist — those live on the toolbar, and the sheet
had none. To make a checklist you wrote a note, saved it, reopened it, and
found a control you had never seen.
ComposeSheet is deleted. + opens the editor on an unsaved draft.
A draft is a real Note carrying DRAFT_ID (the empty string) rather than a
null. Note has eighteen fields and the editor reads eight of them; threading
nullability through all of that to express "not saved yet" would spread the
concept across a screen that should not have to know about it. A real id is
a uuid, so the sentinel cannot collide.
It becomes a row on its first save, and the first save is now an autosave:
the editor writes a second after typing stops. That is affordable because
2707054 made a body write stop costing a revision — before it, saving this
often would have meant a revision per second.
Autosave is also what makes materialisation work at all. Creating the note
on a toolbar tap instead races: the typed text lives in the field's own
state and only reaches the view model on flush, so the tap would create an
EMPTY note and lose what was written. With a one-second debounce the note
already exists by the time any button is reachable.
Three consequences worth naming:
- editingSession, bumped only when the editor opens on a DIFFERENT note.
The text field keys on it instead of note.id, because a draft's id changes
the moment it is first saved and re-keying on that would reset the field
to whatever the store just returned — discarding everything typed during
the write.
- The field is rememberSaveable now. A new note has nothing to fall back on,
and the old sheet used rememberSaveable for exactly this reason; the
editor inherits the requirement along with the job.
- draftDismissed, so a create still in flight cannot reopen an editor the
user has already closed.
Starting a checklist may create an empty note — a note named from its first
item is one this app already has. Colour and reminder are attributes OF a
note and need words first.
editor_body_hint becomes "Take a note…". It read "Note", which is a label on
a blank screen where the sheet's was an invitation.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Every body change snapshotted into history — core/src/local/store.rs and
notes/__init__.py both — so a write was expensive, and the clients
compensated by writing as rarely as they could. BoardViewModel says it
outright: "Saved on close rather than per keystroke, so a session of typing
costs one write and one revision snapshot."
That is durability paying for version history. An app kill mid-session lost
everything typed, so that the revision list would stay tidy. The safety
property is worth more than the feature it was subsidising, and no
comparable product makes this trade: Keep and Apple Notes write
continuously with no history, Docs and Notion write continuously and
coalesce history behind the scenes, Obsidian debounces and snapshots on an
interval. Save-on-close is the outlier, and this coupling is why we had it.
A body change now earns a snapshot only if it is the first of an editing
session — the body actually differs, and the note carries no revision from
the last ten minutes.
Session granularity falls out of the window rather than being declared. A
snapshot stores the body as it was BEFORE the edit, so the first write of a
sitting captures the note as you found it and every write after it inside
the window adds nothing. One revision per sitting, with no commit flag for
a client to send and no wire surface to carry it.
That is why it is a time rule and not a protocol one. sync.py applies pushed
bodies through the same check, so a client autosaving every second cannot
make the server snapshot every second either — which a client-declared
commit point could not have guaranteed without a protocol bump.
Restoring a revision still snapshots unconditionally: a considered act, not
a keystroke, and it stays undoable.
Unblocks idle-debounced autosave, an honest updated_at, and the "Edited just
now" line the editor is getting.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Opening a note put no cursor anywhere, so carrying on cost a tap into the
body and usually a second one to drag the caret past the existing text.
The compose sheet has always focused its field on open; the editor never
did, and continuing a note is the more common act of the two.
Focus the body on open, caret at the end. Not for a trashed note — that
renders read-only and a keyboard over a record you cannot edit is noise.
Keyed on note.id so the reused editor re-requests when pointed at a
different note.
The caret position is why the body state moves from String to
TextFieldValue: a String field always starts its selection at offset zero,
so focusing one lands the cursor before the first character — the wrong
end of a note you meant to continue. PlainTextField gains a TextFieldValue
overload for it, and the two overloads share one colours definition rather
than growing a second copy of the "no box" treatment this file exists to
keep in one place.
I recorded this backwards in Scribe 2947 — as the keyboard opening
unwanted, when the report was the opposite. The source having no
FocusRequester was the tell, and I read it as a mystery instead of as
evidence I had the direction wrong.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Reported as "I'm unable to see a toolbar in the editor on android, is
there one?" — and it was rendering the whole time.
EditorBottomBar passed containerColor but no contentColor, so Material3
defaulted it to contentColorFor(containerColor). That maps a colour-SCHEME
ROLE to its `on-` pair and returns Color.Unspecified for anything else. A
note tint is never a role: the default note is 0xFF171717 while the dark
scheme's surface is 0xFF0A0A0A. So contentColor resolved to Unspecified,
Surface published it as LocalContentColor, Icon took it as its tint, and an
unspecified tint applies no colour filter — leaving the icons-core vectors
their intrinsic black, on a near-black bar.
Every note colour, both themes, only visible in dark. The top bar escaped
it because topAppBarColors(containerColor = …) overrides the container and
leaves the icon colours at their scheme defaults.
Also inset the bar for the keyboard. enableEdgeToEdge makes the manifest's
adjustResize a no-op and Scaffold does not inset its bottomBar slot, so the
bar would sit under the IME the moment anyone typed — a second way to not
see it. imePadding moves to the bar; the content Column drops its own, since
Scaffold now measures the bar at its lifted height and the inset reaches the
content through innerPadding.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
build gated on lint + typecheck only, so run 4293 failed its test lane and
pushed :dev and :09b5f87 regardless — the deployed server was running a
build whose tests were red.
The comment justified this by saying DB-backed testing happened manually
against the dev image rather than on every push. That was true when it was
written and stopped being true at 6f21db8, which added the integration
lane. The reason went away; the exception didn't.
Gate on test and integration too. A :<sha> image is the rollback unit for
its commit (family rule 46) — one publishable from a failing run is not
something you can roll back to.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
09b5f87 moved trusted_proxy_hops out of the environment and into the
settings registry, but tests/test_proxy.py kept asserting against
Config.trusted_proxy_hops() — which no longer exists. The unit lane has
been red since that commit.
Assert through live() instead. That is what proxy.py actually calls, and
it is seeded from the defaults at import time, so the test covers the
case that matters: a boot that has not reached the database yet still
counts one hop rather than zero.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The operator asked why `THOUGHTSYNC_BIND` isn't just defaulted to the safe value.
Fair question, and the answer exposed that my own advice was incomplete: I told
them to set it to 127.0.0.1 without asking where their proxy runs, and for a
proxy inside Docker that is the wrong fix.
There are three shapes, not two:
1. **LAN, no proxy** — the default. Binds every interface so a phone and a desktop
can reach the server. This is why the default is NOT the locked-down value: a
server reachable only from the machine it runs on isn't hardened, it's broken,
and that is the primary documented use of this app.
2. **Proxy in Docker** — delete the `ports:` block entirely. The proxy reaches the
app over the compose network; publishing a host port is a second,
unauthenticated way in that bypasses whatever the proxy does about TLS. Safer
than 127.0.0.1, because there is no host port to reach even from the host.
3. **Proxy on the host** — `THOUGHTSYNC_BIND=127.0.0.1`.
The compose file now spells out all three where the decision is made, and
`docs/public-hosting.md` item 4 asks where your proxy runs before telling you what
to do, plus how to check: `curl http://<lan-ip>:5000/api/health` from another
machine should NOT answer once you're proxied.
No default changed. Changing it would silently break every LAN install on the next
`docker compose pull` — the phone would just stop syncing, with nothing saying why.
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.
Operator, before exposing the instance: *"I'd expect that we should have a proxy
hops setting for how many proxy hops we should trust a shared real-ip at… and is
there any session logging."* Neither existed, and the first one was a real hole.
**The address was forgeable.** `client_address()` read the LEFTMOST
`X-Forwarded-For` entry — nominally "the original client", and precisely the one a
caller controls, because anything they send arrives before what proxies append. So
`curl -H "X-Forwarded-For: 1.2.3.4"`, rotated per request, minted a fresh
rate-limit bucket every time.
Concretely: stuffing ONE account stayed limited (the account key is unforgeable
and that is why it exists), but spraying MANY accounts from one source was not —
each account got its own budget, and the per-address cap meant to bound the total
was defeated by a header. On a LAN that is nothing. It is not nothing on a public
host.
Now it counts in from the RIGHT by `THOUGHTSYNC_TRUSTED_PROXY_HOPS`, default 1.
Each hop appends what it saw, so the rightmost entries are the ones our own
infrastructure wrote and a forged prefix lands to the left of them where it can
never be selected — proven for the honest, forged, padded, CDN and
shorter-than-configured cases. 0 ignores the header entirely; 2 is Cloudflare in
front of a proxy. Too high is the dangerous direction, so a header shorter than
configured falls back to the socket address rather than reaching further left.
`X-Forwarded-Proto` had the same bug and now shares the same rule. Both live in a
new `proxy.py` rather than being written twice — two places holding one decision
is how issue 2183 happened, and this is the same decision.
Env rather than the Settings UI, against rule 25's usual pull: it is deployment
topology rather than preference, and the limiter consults it BEFORE opening a
database connection, which is the entire point of checking a throttle before doing
expensive work. Easy to move if that reads wrong.
**And there was no logging at all** — `auth.py` had no logger, and the only record
of anything was `device_tokens.last_used_at`. Sign-ins, failures, throttle trips,
new accounts and device-token issuance now all log, with the attempted email and
the trusted address. Deliberately including the email: it is the operator's own
server, and "somebody failed a login" without saying against which account is not
actionable.
`basicConfig` at INFO in `create_app`, because hypercorn configures its own loggers
and leaves the root at WARNING — without it every line above would have gone
nowhere, which is a worse failure than not writing them.
This is the app log, not an audit table. Not queryable, not retained past log
rotation. The table is task 2939; this is what makes the next few days observable.
Operator: *"registration should be open only for the first user and they get
granted admin privileges. then registration is closed."*
The old shape had a window in it. The first account was always allowed and became
admin; every account after that was gated by `allow_registration` — which
defaulted to ON. So the door stayed open between "my account exists" and "I
remembered to turn it off in Settings", and on a public host that gap is the
entire exposure: it starts the moment DNS resolves and lasts until someone
remembers.
Now the door shuts as a CONSEQUENCE of the admin account existing, in the same
transaction that creates it. Not "defaults closed" — that would still need the
first person to get in somehow. There is no window to remember, because there is
no window.
Re-opening it is a deliberate act in Settings → Access: turn it on, have the
person register, turn it off. Crude, and it is the only mechanism there is —
**there is no invite system**, not even a stub. That is real work (a token table,
admin create/revoke, a redemption flow, expiry) and is filed as later work rather
than smuggled into a release.
An integration test covers it, because it is the interaction between two writes
in one transaction: first register → 201 and `is_admin: true`; the setting is
then false; a second register → 403; re-open deliberately and a third → 201, not
admin.
**This does not retroactively close an instance that already has users.** The
close fires on first-account creation, so a server whose admin predates this
keeps whatever the setting was — which was on. `docs/public-hosting.md` now says
so explicitly, and step 1 of the checklist is "check" rather than "do" for
exactly that reason.
Found while preparing the release, and it would have quietly defeated the point
of cutting one.
The version does NOT come from the tag. `desktop/packaging/build-version.sh`
reads `desktop/src-tauri/Cargo.toml`, and on `dev` it appends the CI run number
(`0.1.269`) while on a tag or `main` it ships the file's value verbatim — which
was still `0.1.0`.
So tagging today would have published a "release" numbered BELOW every dev build
already out there, and below the 0.1.227 on the operator's phone. The desktop
updater compares semver: an installed build would have read the stable manifest,
seen a version older than its own, and correctly concluded it was already
current. The APK would have installed (versionCode is the run number and keeps
rising) while displaying a version that reads as going backwards.
build-version.sh predicted this in its own comment: "Bumping the minor in
Cargo.toml still wins over any dev build on the old line, which is the ordering
you want: 0.2.0 > 0.1.2932."
Bumped in four places, which is every one that can be read by something:
- `desktop/src-tauri/Cargo.toml` — the actual source; everything else derives
- `tauri.conf.json` — overridden at build time by `--config`, but a checked-in
value that lies is exactly how issue 2183 happened
- `pyproject.toml` + `__init__.py` — the server's APP_VERSION fallback when no
BUILD_VERSION is injected
`core` and `android/ffi` stay at 0.1.0 deliberately: internal library crates whose
version reaches no surface, and versioning workspace libs independently of the
app is normal.
Cargo.lock regenerated with `cargo fetch` per ci-requirements — one line, the
version itself. Verified: a tag build now yields 0.2.0 and a dev build 0.2.270,
so stable is an upgrade for every existing install and dev stays ahead of stable.
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.
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.
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.
26 Alembic revisions and none had ever been executed by CI. `alembic upgrade
head` ran for the first time when the operator's container started, and the
schema the migrations build had never been checked against the models that read
it. M13 dropped three columns and rebuilt a STORED GENERATED column with nothing
watching but a server boot.
Copied from FabledScribe's `integration` job, which had already solved the parts
that are easy to get wrong — and which are family rules precisely because they
were: a separator-free job key with no `name:` (act_runner derives the service
container name from the truncated display name, and the discovery step filters
`docker ps` by it), bridge-IP resolution because service hostnames aren't
routable on this runner, and a Python readiness wait because `run:` is busybox
sh with no `/dev/tcp`.
`postgres:16-alpine` to match the production compose. The schema is built by
real migrations, never metadata.create_all — that step IS the migration test.
Six tests, each pinning something that has only ever been checked by hand:
- an ORM insert against the migrated schema, which is the model/migration
agreement nothing has verified until now;
- `notes.title`, `notes.kind` and `note_revisions.title` are actually gone, and
`note_links` with them — a silently no-op migration shows up here;
- the rebuilt `search_vector` indexes both the name and the body, which matters
because 0026 had to DROP and recreate a generated column rather than alter it;
- a note keeps its body AND its items, the shape step 2 made normal;
- `_apply_note_items` leaves items alone when a change doesn't mention them —
the data-loss path step 2 removed, pinned so its return would be caught;
- a note with no body is still named by its first item, the hole that made
removing the title unsafe until checklists stopped being their own kind.
Runs for visibility; does not gate the build, matching `test` and Scribe.
No local equivalent: running it means standing up Postgres on the workstation,
which rule 12 reserves for an explicit request. Documented in ci-requirements
alongside the Rust, Kotlin and frontend gates.
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.
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.
Two more from the step-2 removals:
**Two unused Kotlin imports** — `FilterChip` (the Note/List switch) and
`Icons.Filled.Create` (the "switch to a note" icon), both orphaned when their
callers went. ktlint treats them as errors.
**`server_info_tolerates_unknown_and_absent_fields`** pinned
`sync_protocol_version: 1` as a literal, so bumping the protocol to v2 made it
fail for a reason that has nothing to do with what it tests. It is about unknown
FIELDS; the versions now come from `CLIENT_PROTOCOL_VERSION`, like every other
test in that file already did.
The bigger fix is the habit. `ci-requirements.md` has documented since
2026-08-18 that the operator authorised running fmt/clippy/test against the CI
image locally, and I had not been doing it. All three now pass here — 116 tests,
clippy clean, fmt clean — and every Rust failure in this milestone so far would
have been caught by them in under a minute instead of by CI, several commits
downstream. Noted in ci-requirements so the next session doesn't relearn it: a
removal is exactly the change that looks too safe to check.
**`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.
`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.
`_apply_note_items` didn't ignore items on a non-list note — it deleted them.
That was survivable only because nothing in the product could produce a note
holding both a body and items.
M13 makes exactly that the normal shape: a checklist is something a note HAS,
not something a note IS. Against that shape this guard is a data-loss path — the
first sync after adding a checklist to a note would wipe it.
Landing it before the UI that can create the state, so there is never a window
where the two disagree. `kind` itself, and the rest of the merge, follow.
`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.
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.
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.
The three route tests stamped their pre-loaded hits at t=0..9 through the
injected clock, then called a route that reads `time.monotonic()`. Against a
trailing window those hits are fifteen minutes stale on arrival, so they were
pruned before they could refuse anything, the request carried on to the database
that this suite doesn't have, and the assertion read `500 == 429`.
The window's own tests keep the injected clock — they pass the same one to both
sides, which is what makes them deterministic and instant. Only the tests that
hand off to a route need the real one.
On a LAN the login form is reachable by people you already trust. Exposed, it is
reachable by everyone, and nothing in front of it was counting.
Three credential routes — /login, /register and /device-login — now throttle.
Every attempt is counted against BOTH the account and the calling address, and
either can refuse it. The account key is the one that matters and the one that
cannot be forged: it stops stuffing against a known email no matter how many
addresses the attempts arrive from. The address key bounds one source spraying
many accounts, and is best-effort by nature — behind a proxy it comes from
X-Forwarded-For, which a caller can set to anything if the app is exposed
directly. That is exactly why it isn't the only key.
The check runs BEFORE the password is verified, which is the other half of what
this protects. bcrypt is deliberately slow; an unauthenticated caller who can
trigger it without limit has a CPU exhaustion primitive as well as a guessing
one. Sliding rather than fixed windows, because a fixed one lets twice the limit
through across a boundary. Bucket count is capped so a rotating forged header
can't turn the limiter into the exhaustion it prevents.
A sign-in against an email with no account now spends a real bcrypt against a
throwaway hash first. Without it "no such account" returned in microseconds
while a wrong password took ~100ms, which is a reliable oracle for which emails
are registered here.
Every response carries a CSP with script-src 'self', object-src 'none' and
frame-ancestors 'none', plus nosniff, a referrer policy and a permissions
policy. The app has no inline and no third-party scripts, so this concedes
nothing; the exceptions are honest — inline STYLE (Vue writes it itself for
v-show and the FLIP), and remote images (a link preview renders the og:image of
an arbitrary host, over either scheme, since a LAN install is served over http).
HSTS only where the request already arrived over TLS, and scoped to the one
host: no includeSubDomains, no preload, neither of which is this app's to
commit.
X-Forwarded-Proto detection moved into one `_is_https()` — the session cookie's
Secure flag and HSTS are the same question, and answering it twice is how the
two drift apart.
docs/public-hosting.md is the rest of it: the four things only the operator can
do (close registration, terminate TLS and forward the scheme, stop publishing
the app port, back up the attachment volume as well as the database), and an
honest list of what the app does NOT have — no email verification, no password
reset, no second factor, no per-user quota, no audit log. Those aren't blockers
for an instance whose accounts are people you know. They're the reason not to
leave signups open to strangers.
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".
Closes M12. The phone can now notice that its server has a newer build and
install it, instead of the operator copying an APK to a device by hand.
**A PackageInstaller session, not an install intent.** The obvious route —
ACTION_VIEW on the APK — is exactly what on-device install heuristics are tuned
against, and it is what produced the "bypassing Android security" warning on
Minstrel (Scribe note 2437). It also never tells the OS that this app is the
legitimate updater of its own package, and it returns nothing: a failed install
is indistinguishable from someone dismissing the dialog.
The session says who is doing what, and on Android 12+ declares no user action
required — which, with UPDATE_PACKAGES_WITHOUT_USER_ACTION, removes the
confirmation entirely on the UPDATE path. Only there: Android will not let an app
quietly put a NEW package on a device, which is right. It also only applies when
the new build carries the same signing key as the installed one, which is why
signing had to land first.
Two things from that research deliberately NOT done: `setRequestUpdateOwnership`
was chased and turned out to be a red herring, and REQUEST_INSTALL_PACKAGES is
not the differentiator either — Mihon declares it too. The mechanism was the
whole difference.
**The outcome comes back.** `commit` takes an IntentSender and the result lands
at `UpdateReceiver`, so a failure can be shown rather than guessed at, and
STATUS_PENDING_USER_ACTION is handled — that is the ordinary path below API 31
and still possible above it, since the OS is entitled to ask anyway. Someone
declining is reported as no error at all: calling a deliberate choice a failure
is how an app sounds broken when it is not.
**The network work stays in Rust.** Two FFI additions — `clientUpdate` and
`downloadClientUpdate` — because the device token lives in the core, and pulling
it into Kotlin to make an HTTP call would spread the one secret this app holds
across two languages for nothing. The core also owns the comparison, so the rule
"version CODE decides, never the name" lives in the layer that has to get it
right for every surface.
The download is streamed to disk, not buffered: 55 MiB in memory on a phone is
how an update gets killed halfway through. It lands in `update.apk.part` and is
renamed only once size and sha256 both match, so an interrupted download can
never be mistaken for a finished one. The digest is not a trust anchor — the
signature is, and Android checks it — but it catches a truncated transfer before
the installer is bothered with it. The advertised path is joined to the base URL
this device is LINKED to rather than followed as given, so a server cannot point
the download at a host nobody agreed to.
**Updates are linked-only, and it says so.** An unlinked install has no update
path, so it gets one sentence explaining where updates come from rather than a
Check button that silently finds nothing — the same lesson as the desktop's
unlink copy (issue 2110). And the "install unknown apps" grant is asked for
BEFORE downloading, so nobody spends 55 MiB to be told no.
Every Android API here was read out of `android-36/android.jar` with javap
first, and the two new FFI methods out of freshly generated bindings, rather
than recalled: `suspend fun clientUpdate(installedVersionCode: Long):
ClientUpdate?` and `downloadClientUpdate(destPath: String)`.
Also fixes `check-symbols.py`, which reported four false positives on
`UpdateOutcome.Result` — its object-member index collected functions and
properties but not nested TYPES, and a data class inside an object is an
ordinary member.
Baking the newest client into every image left two holes, both raised by the
operator.
**An Android-only push never rebuilt the image.** `ci.yml` does not trigger on
`android/**`, so a new APK could be published and no image would ever pick it up
until some unrelated server change came along.
**A push touching both raced.** Both workflows start at once; the image build
would fetch the PREVIOUS client and there would be no second build to correct it
— `:<sha>` is the immutable rollback unit (rule 46), so rebuilding it with
different content would make it neither immutable nor a rollback unit.
Ordering now runs the other way: the Android lane finishes, then calls the image
build. `ci.yml` gains a `gate` job that stands down on any push touching the
Android app, and `android.yml` dispatches `ci.yml` when it is done. One image per
commit, containing the client from that commit.
Cases:
- **server only** — ci builds immediately; the newest published client is already
the right one.
- **Android only** — ci does not trigger at all; the Android lane dispatches it
afterwards.
- **both** — ci's push run stands down, the Android lane dispatches it. Exactly
one image.
- **tag** — always builds. The Android lane does not run on tags, so waiting for
a call that never comes would mean a release tag with no image.
The dispatch is `always()`, so a FAILED Android build still lets the server image
through with the previous client. The alternative is a broken Android lane
silently blocking server delivery, which is a worse failure than a slightly old
APK.
Two details that would each have made this quietly wrong:
The gate diffs the whole PUSHED RANGE (`event.before..HEAD`, full fetch), not
`HEAD^..HEAD`. A three-commit push whose Android change sat in the first would
otherwise have looked Android-free and raced anyway — silently, which is the
worst version of this bug.
The dispatch is `curl -fsS`, not `|| true`. If that call ever stops working the
symptom is server images silently never being built for Android pushes, which
nobody would notice until wondering why the app stopped updating.
The gate's path list has to match android.yml's trigger, and two places holding
one decision is the recurring failure in this repo (issues 2181-2183). It is a
`git diff` rather than a config precisely so the decision is visible in the log,
and both sides carry a comment pointing at the other.
Reverses the placement decision made an hour ago. That one put the APK only on
the data volume, reasoning that ~55 MiB should not be charged to installs that
never touch Android. The operator's call is that ending the manual copy is worth
the megabytes, and it is their deployment.
CI now fetches the newest published client into the build context immediately
before the image build, so `:dev`, `:latest` and `:<version>` all ship one and a
`docker compose pull` delivers a new server and a new client together.
**Always the rolling `dev` release — the newest build there is.** A versioned
image therefore carries the newest client rather than one pinned to that
version. Deliberate: the two negotiate a sync protocol version before linking, so
a mismatch is caught by the handshake, and pinning would buy nothing the
handshake does not already provide.
**Fetched by the JOB, never by the Dockerfile.** The release is private, and a
token used inside a build ends up in the context or a layer.
**It cannot fail the image build.** No release yet, a network blip, a first-ever
build — all of them log a warning and produce an image with no client, which is a
state the server already supports. Half a pair is cleaned up rather than shipped:
a sidecar without its APK is worse than neither, because the server would be
describing something it cannot serve.
**The volume still wins.** `DATA_DIR/client/` is checked first and the baked copy
second, so an operator who deliberately drops a build in gets that build — and a
BROKEN drop-in falls through to the image's copy rather than taking the feature
offline, which is what makes the copy-order advice survivable instead of
load-bearing. Three tests cover the precedence, including that last case.
The baked copy lives inside the package, not under DATA_DIR: that path is a
volume mount, and anything the image wrote there would disappear behind it the
moment one is attached.
`client/.keep` is tracked so `COPY client/` cannot fail on a tree where the CI
step never ran; the artifacts themselves are gitignored, since a 55 MiB binary
does not belong in git history and is re-fetched on every build anyway.
Run 4092 published `thoughtsync.apk` to the `dev` release. Run 4098 removed it,
four minutes later, and both runs were green.
`write-manifest.sh` prunes the rolling channel to stop ~100 MB AppImages
accumulating forever, keeping `latest.json` and anything whose name contains the
current `$APP_VERSION`. The Android assets deliberately have no version in their
names — a fixed name is the only addressable URL on a tag that never moves,
which is the entire reason the `dev` release exists — so they matched neither
rule and were swept.
They would have been swept even if they HAD carried a version: Android is a
different workflow with its own run number, so its version never equals the
desktop's `$APP_VERSION` in this script.
The keep-list is now about fixed names rather than about `latest.json`
specifically, which is what the rule always meant. A fixed-name asset is
self-limiting — each publish replaces the same name — so the accumulation this
prune exists to prevent cannot happen to one.
Worth noting how this presented: two green runs and a missing file. Nothing
failed, and the only way to see it was to ask the release what it actually held
rather than trusting that a step named "Publish" had published.
`d77a798` added the Android client to publish-release.sh's asset list and broke
the desktop lane's publish, which had been working (run 4094, curl exit 26 —
"couldn't read local file"). The Android lane published fine, which is what made
the shape of the mistake clear.
`shopt -s nullglob` drops PATTERNS that match nothing. The two entries I added —
`android/dist/thoughtsync.apk` and its sidecar — contain no wildcard, so they are
not patterns at all: globbing leaves them in the array verbatim and curl is handed
a path to a file that does not exist. In the Android job those files are there, so
it worked; in the desktop job they never are, so it did not.
Every entry is now filtered on existence, which is what the array has always
meant. That covers the literal paths and the globs alike, rather than relying on
each future entry containing a `*` to be safe — the trap that just cost a run.
Verified both ways before pushing: a literal missing path survives nullglob and is
removed by the filter, and an all-empty result still exits cleanly under `set -u`.
A self-hoster should not need an account on someone else's forge to get the app
for their own notes. The Fabled-Git instance is private — which is why
`install.sh` already cannot fetch for anyone but the operator — so a release page
is no use as a distribution point. The server holding the notes is something the
person already trusts and already reaches.
It also keeps the pair in step by construction. Client and server negotiate a
sync protocol version before linking, so a server that also serves the client
cannot hand out a phone it is unable to talk to.
**Two files, and both must be present**: `thoughtsync.apk` and a
`thoughtsync-android.json` sidecar carrying `{version_name, version_code, size,
sha256}`. The sidecar exists because an APK keeps its version in a binary AXML
manifest, which Python cannot read and which is not worth putting `aapt` on a
Quart server to reach. CI writes it beside the APK, where the values are already
known — including the digest, computed over the same bytes it uploads, so a
phone can tell a truncated download from a complete one before handing it to the
installer. Not a trust anchor; the signature is that.
**Under DATA_DIR, not baked into the image.** Baking charges ~55 MiB to every
self-hoster including everyone who never touches Android. `/var/thoughtsync` is
already the mounted volume that holds attachments, so a build dropped there
survives container recreation.
**Absence is an ordinary state, not an error.** No APK means the key is absent
from `/api/config` — absent rather than null, so a client testing for it cannot
confuse "this server has no client" with "this server predates the field" — the
web UI hides the card instead of offering a button that 404s, and the metadata
route answers 404. A server whose owner does not use Android is not misconfigured.
**A mismatched pair also counts as no client.** If the sidecar's recorded size
does not match the file on disk, the two did not arrive together; serving one
build while advertising another is worse than serving none, because the phone
would compare versions against a promise the bytes do not keep. That makes the
copy order in docs/android-distribution.md load-bearing, and it is written down
there: APK first, sidecar last.
**The version is public, the bytes are not.** An updater has to be able to ask
"is there something newer?" cheaply and before it has done anything; 55 MiB is
not for anyone who can reach the port. `login_required` already accepts either a
session cookie or a device bearer token, so the browser and a linked phone both
work with no second auth path.
The Android lane now publishes both files to the same rolling `dev` release the
desktop bundles use, reusing `publish-release.sh` — its nullglob asset list was
already built for several jobs in separate workspaces publishing to one release,
which is exactly this. Signed builds only: publishing an unsigned APK would offer
people something they cannot install over what they already have.
Nine tests, DB-free like the rest of the suite — this lane runs no Postgres, so
the advertisement is asserted through `advertisement()` rather than through
`/api/config`, whose other half needs a database. Both routes ARE exercised,
because neither opens a session.
Run 4082: `Task 'testReleaseUnitTest' not found`. AGP creates unit-test tasks
only for `testBuildType`, which is debug — so pairing the test task with the
packaged variant was wrong from the start.
It was only paired to stop two Gradle invocations asking for different Cargo
profiles and paying the four-minute cross-compile twice. With the profile pinned
to debug (#2810) that reason is gone, so the step goes back to `testDebugUnitTest`
unconditionally. Costs one extra Kotlin compile and buys the type-check on the
variant an emulator build would actually use.
Also: the artifact was named from the Cargo profile, which is now always "debug"
— so a signed release APK would have been uploaded as
`thoughtsync-android-debug-<sha>`. Same word, two different things. It is named
from the APK's variant now, and the two outputs are kept separate so they cannot
be confused again.
`d0a9c73` switched the lane to a release Cargo profile alongside the release
variant. The variant was the point; the profile was mine, and it broke the build
(run 4077): `generateUniffiBindings` fails with "No UniFFI metadata found" on
the release `.so`.
The workspace release profile sets `strip = true`, and uniffi's `--library` mode
finds its interface metadata through symbols. That is the obvious suspect and it
is recorded as a suspect, not a finding — `lto = true` dropping the metadata
statics would print the identical message and the two have not been told apart.
Backed out to the debug profile rather than guessing at a fix, because the two
halves of that commit are not equally important. Signing and a rising
versionCode are what make an install replace the last one instead of wiping the
notes; the Rust profile only makes the result faster. The APK this produces is
no worse than every previous build, all of which shipped a debug-profile `.so`.
Recorded as Scribe #2810 with the four candidate fixes and, more usefully, the
instruction to establish the cause on a host build before spending another
four-minute cold cross-compile on a guess.
Two separate reasons updates were impossible, both fixed here.
**Every CI build was signed with a different key** (issue #2803, measured with
`apksigner --print-certs` across two runs). No signing config meant AGP's debug
keystore, which AGP GENERATES when absent — and every job starts from a fresh
container. So no build could ever be installed over another: the only way
through was uninstall-then-install, which deletes the app's database and every
local note with it.
**versionCode was hardcoded to 1.** `build.gradle.kts` has read a
`THOUGHTSYNC_VERSION_CODE` property since the skeleton landed; nothing ever
passed it. Even with signing fixed, every APK would have claimed to be the same
version and nothing could tell a newer one existed. It now comes from
`GITHUB_RUN_NUMBER` — the same monotonic counter the desktop's version scheme
already uses, needing no state between runs and immune to the shallow checkout
that makes a commit count useless here. The version NAME comes from the
desktop's `build-version.sh`, so both surfaces report one product version rather
than two that can disagree.
**The alias is hardcoded, not a secret.** It is fixed for the life of the app and
already written into the certificate every install carries; hiding it would buy
nothing and stop this file describing its own signing. Two secrets, not three —
and PKCS12 cannot hold a key password distinct from the store password anyway,
so `keyPassword` is the same value by necessity rather than by shortcut.
**The lane now builds RELEASE when it can sign, debug when it cannot.** That is
not cosmetic. A debug APK is `debuggable`, which on a phone holding personal
notes and a device sync token means anyone with adb can read both.
Which meant confronting something the release path would have shipped quietly:
`cargoNdkDebug` was hardcoded to the debug Cargo profile and every variant took
its `.so` from it, so `assembleRelease` would have packaged an UNOPTIMISED store
and sync engine. Now one `cargoNdk` task takes its profile from a property, and
the whole run uses one profile. A debug/release task pair would have been the
tidier shape and would have made a run that both type-checks and packages pay
the four-minute cross-compile twice — this runner has no working Gradle or Cargo
cache, so that cost is real on every push.
The run prints the signing certificate after assembling, so the fingerprint can
be compared against the one recorded at generation. Signing with the wrong key
produces a perfectly valid APK that simply refuses to install — a failure that
otherwise surfaces on the device, long after the run is green.
`.gitignore` learns `*.jks`, `*.keystore`, `*.p12`, `*.b64` first, so generating
a keystore anywhere near this tree cannot go wrong.
Also corrects the record: the comment this replaces cited "Scribe task 2136" as
though it were a standing rule. It is not one — none of the 46 always-on rules
mentions signing keys. 2136 is a desktop-updater task whose REASONING got
repeated until it sounded like policy. The reasoning holds, and holds harder on
Android where a key cannot be rotated without the original, so the practice is
unchanged; the citation is now honest about what it is.
`complete_reminder` cleared `remind_at` and said so in its own comment —
"(Recurrence advancement is a later refinement.)". So Done on a daily reminder
was quietly the last time it ever fired. Reminder notifications made that much
easier to hit, because Done is now a button in the notification shade.
**The server already had this.** `src/thoughtsync/notes/recurrence.py` has done
it correctly all along, which means the web behaved one way and the desktop and
Android the other, on the same note, in the same account. This is a port of that
file rather than a fresh implementation, kept behaviourally identical rather than
merely similar: the same reminder can be completed from a browser or a client,
and a disagreement would move it depending on which one you happened to use.
The seven new tests in `core/src/local/recur.rs` mirror the Python suite case for
case, including the one that matters most in practice — 31 January plus a month
is 28 February, and the step after that is 28 March rather than back to the 31st.
That clamp is sticky, and it is now asserted on both sides so a future "fix" to
either has to change both.
Advancement is measured from the reminder's own time, never from now, which is
what keeps a 09:00 daily reminder at 09:00 when it is dealt with at 09:47. A
phone left in a drawer for a fortnight rolls forward to tomorrow rather than
arriving at fourteen pending occurrences of the same thing.
Also matched from the server, and a latent bug of its own: the non-recurring
branch now clears `recurrence` as well as `remind_at`. Before, completing a note
that carried a rule left the rule behind with no reminder attached — invisible in
every UI, since they only render recurrence when there is a reminder to recur
from, and waiting to surprise whoever next set a time on that note.
Documented rather than hidden, and shared with the server: the arithmetic is in
UTC and a note carries no timezone, so a daily reminder crossing a DST boundary
keeps its UTC time and shifts by an hour locally. Fixing that means a zone per
note, which is a wire-format change.
Verified in the CI image before pushing: fmt, clippy --all-targets -D warnings,
and the full suite — core 89 to 96, ffi 11 to 12. The new FFI test walks the path
the notification's Done button actually takes.
`785ebdb` failed at compileDebugKotlin with two `Unresolved reference 'dismiss'`.
Splitting the reminder notification code into its own object, I removed
`dismiss` from `Reminders` and never pasted it into `ReminderNotification`. The
call sites were correctly qualified; the function simply was not there.
All four local gates passed it, and `check-symbols.py` passed it for a reason it
documented about itself: it only resolved the LEADING segment of a dotted
expression, because that is the part a regex can resolve. `ReminderNotification`
existed, so `ReminderNotification.dismiss(...)` looked fine.
That was a real gap rather than an inherent one, so the checker now indexes the
members of every `object` declared in the package and verifies `Foo.bar` against
them. Brace-counted, not regex-matched — an object body is full of nested braces
from lambdas and apply blocks, and no regex closes correctly over them.
Verified by deleting `dismiss` from a copy of the tree again: it reports the
same two call sites the Kotlin compiler did. What it still cannot see is
narrowed and written down rather than left implied — members of anything
declared outside this package, members reached through a variable rather than a
type name, and every question about types.
Reminders have been settable since the editor landed and have never once gone
off. The board showed them overdue in red, which tells you what you already know
by the time you are looking at the board.
**AlarmManager, not WorkManager.** The background sync is right to be on
WorkManager — nobody minds whether it runs at 3:05 or 3:19. A reminder minds
very much. WorkManager's periodic floor is fifteen minutes and it batches into
maintenance windows, so "remind me at 09:00" would routinely arrive at 09:14,
which is not a reminder, it is a rebuke.
**One alarm, not one per reminder.** Only the earliest future reminder is ever
scheduled; when it fires, everything due is announced and the next is scheduled.
A hundred reminders cost one alarm, and there is no incremental bookkeeping to
drift — `Reminders.refresh` recomputes the whole picture from the store, and is
called from everywhere anything could have changed: an edit, a foreground, a
background sync, boot, and an app update.
Boot and MY_PACKAGE_REPLACED both matter and both are easy to forget. Pending
alarms survive neither, and this app updates by APK from its own server, so
without that receiver a phone would silently stop reminding anyone of anything
after a restart — the worst kind of failure, because nothing appears wrong.
**Neither permission is treated as a prerequisite.**
SCHEDULE_EXACT_ALARM, not USE_EXACT_ALARM: the latter is granted at install with
no prompt and is reserved for apps whose whole purpose is an alarm clock or a
calendar, which this is not. Refusing the former costs precision, not the
feature — it falls back to an inexact alarm, because a reminder a few minutes
late beats no reminder.
POST_NOTIFICATIONS is asked for on the first launch where a reminder actually
exists, never at launch on an empty board. Android gives an app essentially one
chance at that dialog, and spending it before the person has any idea what this
app would send them is spending it on nothing. For anyone who refuses, or who
turns notifications off later in system settings, the Reminders view carries a
standing notice with a button to the right screen — a feature that silently does
nothing is worse than one that is plainly absent.
**A first run adopts overdue reminders silently.** The storm case is linking a
server and pulling months of history; a hundred notifications the moment someone
signs in is a good way to have the feature turned off before it is ever useful.
After that, a missed reminder is announced up to a day late — the web uses
fifteen minutes because an open tab has been polling every forty-five seconds,
but a phone can be switched off all night.
Done and Snooze act from the shade without opening the app. The dedupe key is
note id plus remind_at, the same one the web store uses, so snoozing produces a
new occurrence rather than one already dealt with.
Tapping a notification opens that note. The extra is CONSUMED when read: the
Activity keeps the intent it was launched with, so without that, rotating the
phone would replay it and reopen a note the person had already closed.
`Reminders` split into scheduling policy and `ReminderNotification` rendering
after detekt counted fourteen functions in one object — it was right, they answer
different questions and change for different reasons. `ForegroundTransitions`
moves to the ui package; the reminder notice needs it to re-read a permission the
person may have just changed in a system screen this app cannot observe.
Known gap, pre-existing and shared with every surface: `complete_reminder` in the
core clears a reminder without advancing recurrence — its own comment says so.
So tapping Done on a daily reminder ends it rather than moving it to tomorrow.
Not changed here because it is core behaviour the desktop and web also have, but
notifications make it much easier to hit, and it should be next.
Two things the operator hit on a real device.
**Capture threw work away.** Every exit from the compose sheet except Save
discarded it — tapping the board behind, swiping down, back, backgrounding the
app, and rotating the phone. That is the wrong default anywhere and the worst
possible one here: a sheet that loses a typed thought because you touched
outside it teaches people not to trust the app with a thought, and capture is
the one place this product cannot afford that.
Now every way out saves, which is the shape the editor already settled on. The
difference is that capture also has to be abandonable — tapping + and changing
your mind is normal — so Discard exists and is the only path that loses
anything. It is called Discard rather than Cancel because "cancel" means "undo
what I am doing", which is precisely what leaving no longer does; the word would
have described the one button it is not attached to. An empty draft needs
neither and is simply dropped: a blank note nobody asked for is worse than none.
Backgrounding persists but does NOT close an empty sheet. Someone who tapped +
and got distracted should find the composer where they left it.
Rotation was losing it twice over: the draft was `remember`, and so was the flag
saying the sheet is open. Both are `rememberSaveable` now, along with the sync
screen's — the editor never had the bug because the note it sits on lives in a
view model, and these were the only screen state that did not.
`FlushOnStop` moves out of NoteEditorScreen into its own file; the editor and
the capture sheet want the identical thing for the identical reason, and it was
about to be copied.
**The board had a centimetre of nothing above the search field.** `SearchBar`
applied `statusBarsPadding()` inside a `Scaffold` whose content padding already
carries the system-bar insets — `ScaffoldDefaults.contentWindowInsets` is
`systemBarsForVisualComponents`, checked in the material3 sources rather than
assumed. So the status bar height was reserved twice on the first screen anyone
sees. Insets get consumed once, by whichever component owns the edge.
The note added with the previous commit said RECEIVE_BOOT_COMPLETED arrives in
the merged manifest via WorkManager. True, and incomplete — it brings four:
RECEIVE_BOOT_COMPLETED, ACCESS_NETWORK_STATE, WAKE_LOCK and FOREGROUND_SERVICE.
A comment whose whole job is "here is why the permission list has entries this
file does not declare" fails at that job if it accounts for one of them. Each
now says what it is for, checked against the built APK's merged manifest rather
than the library's — which is the version a person actually sees.
Until now every sync was a button press. Pull-to-refresh made asking cheaper; it
did not stop the app needing to be asked, which on a phone means a note written
on the bus reaches the desktop whenever you next happen to open the app.
Three moments, and they are deliberately not the same job:
* **Coming to the front**, if the last sync is over five minutes old or there
is unsent work. Not on every foreground: stepping out to copy a link and
stepping back is not a request for fresh notes, and syncing on every app
switch spends someone's mobile data telling them what they are looking at.
* **Going away with unsent work** — handed to WorkManager rather than run
inline, because the process is about to stop being a priority and a sync
started there would be killed halfway. This is the one that matters most: it
is what gets a note off a phone that then goes into a pocket for the night.
* **Every fifteen minutes**, network-constrained. Fifteen is not a preference,
it is WorkManager's floor for periodic work; asking for less gets fifteen.
**An automatic sync must not raise an error banner.** Someone who pulled the
board down is owed an answer; someone who merely opened the app did not ask a
question, and answering it with a red banner about an unreachable server makes
their own notes look broken when nothing of theirs is. So `syncNow` and
`syncQuietly` differ in exactly one thing — whether failure is announced. The
quiet channel for a persistent problem is the drawer badge, from `has_pending`,
which does not care how the attempt was made.
**There is a switch, defaulting to on.** Linking a server IS the consent; a
person who paired a device and then had to find a second toggle before anything
moved would reasonably call that broken. It lives in SharedPreferences rather
than the store: everything else in sync state describes the PAIRING and must
survive a reinstall, while this describes how one handset behaves, and someone
turning it off on their phone is not asking their laptop to stop. The copy says
what "automatically" means in minutes and says that off is not off — a switch
next to a Disconnect button invites exactly that misreading.
The schedule is DECLARED as a function of (linked, switch) in a LaunchedEffect
rather than toggled from the places that change them. There are four routes to
"should not be syncing on its own" and a call at each is four chances to leave a
phone quietly syncing after it was told to stop.
`ON_START`/`ON_STOP`, not resume/pause — the same choice the editor's save-on-
leave makes, because pause fires for anything covering the window and a sync per
notification-shade pull is not automatic sync, it is a stutter.
RECEIVE_BOOT_COMPLETED now appears in the merged manifest. WorkManager
contributes it so the schedule survives a restart; commented in AndroidManifest
because it shows in the app's permission list and nothing else in that file
would explain it.
Two things read from artifacts rather than recalled, both of which memory would
have got wrong: `work-runtime-ktx` is an empty 6 KB stub as of 2.11 with
`CoroutineWorker` and `PeriodicWorkRequestBuilder` moved into `work-runtime`, so
the dependency is on the latter alone; and `Switch` is not experimental in
material3 1.4.0, so no `@OptIn` — an unnecessary one is itself a warning.
Also adds `android/tools/check-strings.py`, after this change added three
strings: `R` is generated, so `R.string.typo` type-checks whether or not the
string exists. It catches a missing name, `stringResource` on a plural or the
reverse, and a format taking more arguments than the call passes. Verified
against a tree with one of each fault — its first version counted Kotlin's
trailing commas as arguments and called three correct sites broken, which is the
failure that teaches you to ignore a tool.
Two comments in this change were wrong when written and are corrected here
rather than left: the flag check in SyncWorker does NOT avoid opening the store,
because Application.onCreate has already run by the time any Worker starts.
Every sync so far has been a button press on a screen you have to navigate to.
On a phone the gesture for "check if there's anything new" is a pull, and not
having it is the kind of absence people read as the app not syncing at all.
**The gesture is INERT when this device has no server.** `Modifier.pullToRefresh`
takes an `enabled`, which is why the modifier and the indicator are wired by hand
instead of using `PullToRefreshBox` — that wrapper is less code and offers no way
to turn the gesture off. An unlinked device has nowhere to pull from, and a
gesture that always comes back empty is how people learn a control is broken.
Same reasoning as the drawer badge staying silent when unlinked: local-only is
this app's resting state, not a fault.
**A failed refresh reaches the board.** Otherwise the spinner retracts and
nothing happens, which is indistinguishable from "you were already up to date" —
the one outcome it must not be confused with. It renders as a second banner
rather than replacing the store-error one: those are different facts about
different halves of the app, and hiding either behind the other reports the
wrong problem. Dismissing is honest — the note is still pending, `hasPending`
still says so, and the next cycle reports the same fault if it persists.
**The empty board is now a `LazyColumn` holding one centred item.** Pull-to-
refresh works through nested scroll, and a layout that never scrolls never
dispatches any, so on the old plain `Column` the gesture would have been dead on
exactly the screen where it matters most: linked, board empty, notes still on the
server. Looks identical.
The five sync facts the board needs arrive as one `BoardSync` rather than five
parameters, for the reason `EditorAction` exists: `summary` and `error` are both
`String?` and both about sync, so positionally they could be swapped with nothing
to catch it.
Still no automatic sync — no background cycle, no sync-on-resume. This is a
faster way to ask, not a decision to stop asking. TalkBack users cannot perform
a pull; the drawer's Sync → Sync now remains the accessible path, unchanged.
Verified against the real artifact rather than from memory, since `material3`
resolves through the BOM: 1.4.0's sources confirm `pullToRefresh` has `enabled`,
and that none of `pullToRefresh`, `rememberPullToRefreshState`, `Indicator` or
`PullToRefreshBox` is `@ExperimentalMaterial3Api` there — only two deprecated
members are. So no `@OptIn`, which is what keeps the build at zero warnings.
`750d11d` failed CI at `compileDebugKotlin` with `Unresolved reference 'Build'`.
`defaultDeviceName()` reads `android.os.Build`, and the import was lost when
`SyncPairing.kt` was split out of `SyncScreen.kt`. One line to fix.
The interesting part is that ktlint and detekt had both passed it, locally and
in CI. Neither resolves symbols — they parse — so a file that cannot compile is
indistinguishable to them from one that can. A clean analyzer run is not
evidence the code builds, and on this repo `compileDebugKotlin` is the only
gate that type-checks at all, since there is no Android SDK on the workstation.
So: `android/tools/check-symbols.py`, covering that one blind spot. It flags any
capitalised identifier that is neither imported, declared in the same package, a
type parameter, nor implicitly available. Not a type checker and not pretending
to be — a pre-push filter for the single mistake that survives every other local
gate, erring toward false positives.
Verified against a known-bad tree rather than trusted on a green: deleting the
`Build` import from a copy makes it fail with the same two references the Kotlin
compiler reported. That step is not ceremony. An earlier attempt at this check
stripped line comments with `re.S`, where `//.*` eats each file from its first
comment to EOF — it examined almost nothing and reported everything clean.
ci-requirements.md now documents all three Kotlin checks, and its claim that no
workflow consumes the Android image yet is gone; the lane has been running since
step 5.
The plumbing has been bound since step 4 — probe, link by password or token,
unlink, sync — with nothing on top of it. Until this commit the phone was a
good standalone notes app that could not be the SAME notes as the desktop,
which is the point of the project.
Structurally a port of the desktop's SyncView.vue: same probe-then-link order,
same copy wherever the copy was already right. The two surfaces pair with the
same servers, and a difference in wording here would read as a difference in
behaviour.
BEING UNLINKED IS NOT A PROBLEM, and the screen is written around that. It
leads with "Working offline on this device" and says what connecting would
ADD. A local-first app that frames its resting state as unfinished setup is
lying about what it is. The drawer badge follows the same rule: it says
nothing at all when unlinked, rather than "Off".
Probe before credentials. A typo that reaches a stranger's server should cost
a round trip, not a password — so the address is checked first, what answered
is shown (name, version, compatibility), and only then does a sign-in form
appear. An incompatible server never gets one; the core would refuse the link
anyway, and collecting a password to throw away is worse than not asking.
CLEARTEXT IS NOW PERMITTED, deliberately and not silently. Android blocks
plain http from API 28, and the core explicitly supports a self-hosted server
on a LAN — `http://192.168.1.10:8000` is a case it has a test for. The
platform default would make this app unusable for exactly the people it is
built for, with a transport error they could do nothing about. A
network-security-config would be tighter in principle but matches domains and
IP literals, not CIDR ranges, so it cannot express "my own network". The other
half of the trade is a warning that appears the moment a probed address starts
with http:// and BEFORE any credential field: anyone on the same network can
read your password and your notes.
Credentials never enter the view model. The address, email and device name are
`rememberSaveable` so a rotation doesn't cost a retype; the password and the
token are plain `remember` on purpose — rememberSaveable persists into the
instance-state bundle, and a secret has no business being written there to
save four seconds of typing. They reach the core as a `Credentials` sealed
type and die with the composable.
That sealed type also fixed a bug detekt surfaced by complaining about a
six-parameter function: `link_with_token` takes NO device name (the token was
already minted against a named device in the web app), so the flat argument
list meant the form collected one in token mode and silently dropped it. The
field now exists only on the password path.
Threading, which differs by call and is easy to get wrong in one direction:
probe / linkWithPassword / linkWithToken / unlink / syncNow are Rust async
through uniffi, so Kotlin sees suspend functions already driven by tokio and
awaits them directly — wrapping them in Dispatchers.IO would park a thread to
wait on something that never blocks one. syncStatus and hasPending are
ordinary blocking FFI into SQLite and do need it.
A sync that changed anything tells the board to reload, because a pull can
have rewritten every note it is holding. Wired explicitly at the one place
that owns both view models rather than through a shared event bus. A no-op
sync deliberately does not, so the board never flashes its loading state for
nothing.
Sync results are kept RAW in state and turned into sentences in the UI, where
stringResource is in scope — the same split Time.kt draws for timestamps. The
summary counts what MOVED; batches, pages, noop and cursor are all real
numbers and none of them answer "are my notes in step". Rejections are
surfaced rather than swallowed: only a person can resolve them. So is a revoke
that didn't land — someone disconnecting to retire a phone has to be told a
live credential is still out there, and has to still find it when they come
back to check, so it is a persistent notice and not a toast.
Also here: `Panel`/`Notice` extracted as shared tinted chrome, drawn from the
same note palette the cards use rather than Material's errorContainer, so a
warning is the same yellow a note can be. `PlainTextField` gained a visual
transformation for the password field. `formatReminder` became `formatInstant`
now that "last synced" reads it too.
Verified locally per ci-requirements.md: ktlint and detekt clean in
ci-rust-android:1.97, uniffi bindings generated from a host build and read to
confirm ULong on the summary counters, `Compatibility.Ok`/`RevokeOutcome.
Unsupported` being objects, and all five sync calls being suspend. Every
R.string/R.plurals reference cross-checked for existence, kind and format
arity. A symbol-resolution pass over the whole package caught a composable a
bad edit had deleted — ktlint and detekt both parse without resolving, so
neither could see it.
Not done: no automatic sync. The desktop is manual-only too, so this is parity
rather than a gap, but pull-to-refresh on the board is the obvious phone-native
follow-up.
Worth an operator decision, not changed here: allowBackup is still true, so
Android's cloud backup now includes a device token as well as the notes. Good
for restoring to a new phone, and a wider blast radius than before this commit.
Scribe #2777
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Tapping a card now opens something. Until this commit the phone could create,
find and navigate; it could not change anything.
A FULL SCREEN, not a sheet. Capture is a sheet because the board behind it is
reassurance that the thought landed; editing is a sustained task with the
keyboard up, and a sheet would spend the whole time fighting the IME for the
bottom half of the display. Full screen also puts the actions in a bottom bar,
which is where a thumb already is. The note's colour paints the whole screen,
so opening one reads as the same object growing to fill the display.
Text saves ONCE, on close — plus on ON_STOP, so app-switching mid-paragraph
doesn't lose it. Not debounced autosave: the core snapshots a revision on every
title/body change, so saving per typing pause would fill version history with
near-identical entries. A baseline check means opening a note and backing out
writes nothing at all, rather than bumping updated_at and marking it dirty for
sync. Same shape the web editor settled on, for the same reason.
The editor speaks in ACTIONS, not callbacks. The first version passed a bundle
of twenty lambdas and the doc comment on it was already worrying about two of
the same-shaped ones getting swapped, with nothing to catch it. `EditorAction`
plus one `(EditorAction) -> Unit` costs a `when` at the far end and buys
exhaustiveness: adding a variant breaks the dispatcher until it is handled.
Checklist rows are live here — real checkboxes, editable text, remove, and an
add row that keeps focus so a list types straight through. That is the answer
to the open question about list entry: the capture sheet stays one-item-per-
line because at capture time the list is already in your head and a tap per row
is the slow part; the editor is where a list is REVISED, and revising is
item-at-a-time. Row text commits on focus loss, not per keystroke — each commit
is a store write that reloads the note.
Colour, labels and reminders are bottom sheets. Reminders lead with presets
(later today / tomorrow / next week) and keep the exact picker one tap down:
the web's raw datetime-local is right for a desktop and three taps too many for
the common case on a phone. Recurrence only appears once there is a reminder to
recur from. The date picker reports UTC midnight of the calendar day tapped and
is read back in UTC — reading it in the device zone is the classic off-by-a-day
in that control.
Pin, labels, archive and delete live in the overflow as WORDS.
`material-icons-core` has no pin, archive or label glyph, and the alternatives
were pulling in the ~1,000-vector extended set for four icons or pressing
unrelated ones into service — a star meaning "pin" is a star meaning "favourite"
to everyone who has used another app. The colour button is a dot in the note's
current colour, which says what the colour IS as well as what the button does.
A trashed note renders read-only. Editing one would silently resurrect work
that was meant to be thrown away; Restore and Delete forever are the only
things to do with it. Deleting for good is the one irreversible action in the
app and gets the one confirmation in it.
`#tag` labels are never sent to `set_labels` and get no remove button. They are
owned by the body text and the core re-derives them on the next edit, so a
cross that undid itself a second later would look broken.
FFI additions: delete_note_forever, add_item, set_item_text, set_item_checked,
delete_item, complete_reminder, snooze_reminder, set_note_labels, create_label.
`set_item_text`/`set_item_checked` are split rather than exposing the core's
{text?, checked?} patch, for the same reason NoteEdit is a list — an
optional-field struct cannot say "leave this alone" in Kotlin without colliding
with "set it to null". Four new tests (11 total in the crate).
Found while extracting shared helpers: the card painted EVERY reminder blue,
so "you missed this" and "coming up Friday" looked identical. Now red when
overdue and neutral otherwise, matching the web card's exact pairs. And the
error banner was renderable only by the board — the one screen that needed it,
where the writes happen, was the one screen without it.
DRY, since three copies each had appeared: PlainTextField (the undecorated
field used by capture, editor, checklist rows and the search bar), Time.kt (the
RFC3339 seam), NoteKind.kt, ErrorBanner.
detekt: LongMethod and LongParameterList now ignore @Composable. Compose breaks
those rules' PREMISE, not just their thresholds — a composable's parameters are
its UI contract and its length tracks how many elements are on screen, not
branching. Two suppressions carry their reasoning at the site instead:
onEditorAction is sixty lines because EditorAction has twenty variants, and
splitting it would need an `else` that throws away the exhaustiveness; and
BoardViewModel stays one class because every editor mutation has to reload the
board behind it.
Verified locally before pushing, per ci-requirements.md: fmt/clippy/test in
ci-tauri:1.97 (89 + 11 + 11 tests, four crates present), ktlint and detekt in
ci-rust-android:1.97, uniffi bindings generated from a host build and read to
confirm every method and field name the Kotlin calls.
Still unbuilt: attachments, link previews, version history, and label
management (rename/recolour/delete). Setting up a server from the phone is next.
Scribe #2777
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two things at once, because they answer one question: what should this look like,
and what should it look like ON A PHONE.
IDENTITY IS SHARED, INTERACTION IS NOT. The card now renders exactly what the web
and desktop render — note colour, checklists, label chips, reminders — using the
same palette values, so a note looks like your note on every surface. The chrome
does not: the desktop's title bar and sidebar are wrong for a thumb.
* NoteTint.kt carries the Tailwind colours from frontend/src/notes/colors.ts
VALUE FOR VALUE, generated from tailwindcss 3.4 rather than eyeballed. Dark
tints keep the web's alpha (dark:bg-*-950/40) instead of a precomputed blend,
because Compose composites translucency over the background exactly as CSS
does.
* Dynamic colour is GONE. It was the more Android-native choice and it made the
app look like a different product — on a stock emulator with no wallpaper it
renders as undifferentiated grey, which is what the operator saw. Three peer
surfaces share one identity; the brand #F5C518 is the same value the web
manifest and the launcher icon already use.
* The board is a two-column staggered grid, the Compose equivalent of the CSS
multi-column NoteGrid.vue uses.
PHONE ERGONOMICS, chosen with the operator:
* Search IS the top bar. After writing a note, finding one is the most common
thing you do, and burying it behind an icon costs a tap every time. Debounced
180ms and cancelled per keystroke — without that a fast typist queues one
full-text query per character and results land out of order.
* A + button is the only way in. One obvious target beat a capture bar and a
button competing for the same job.
* Navigation moved into a drawer behind the search bar's menu icon, which is
where archive/trash/labels/reminders now live. They had nowhere to go once
search took the top bar, and would otherwise have been unreachable.
* The compose sheet asks note-or-list up front. On a phone those are different
typing tasks and switching halfway is worse than choosing at the start. A
list takes one item per line — fast to type, versus a tap per row.
Three new bindings the UI needed: search_notes, reminder_notes, list_labels.
Search goes through the CORE so "what matches" cannot drift between surfaces;
filtering the loaded list in Kotlin would have been less code and a different
product. reminder_notes is its own call because the core models it that way —
"has a reminder" cuts across archived and active alike.
Empty states are per-destination. "Nothing here yet" is encouraging on an empty
board, wrong in Trash, and misleading after a search where the notes exist but
did not match.
Verified locally before pushing: bindings generated from a host .so and read back,
ktlint and detekt clean from the image's pinned CLIs, cargo fmt/clippy/test green
(107 tests). Two detekt findings were fixed by extraction rather than by relaxing
the rules — this is the first Compose code in the repo and the thresholds should
have to earn their exceptions.
Still unbuilt: tapping a card does nothing. The editor is next.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Debug APKs get pulled into the working tree for emulator testing. They are ~57 MB
and come from CI artifacts, so they are never a source — but nothing stopped
`git add -A` from committing one permanently.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The first working APK carried libjnidispatch.so for armeabi, mips and mips64 as
well as our four — JNA's .aar still ships those, and AGP packages whatever it
finds. Android dropped mips in NDK r17 and armeabi in r17 too; nothing that can
install this app can load them, so they are pure payload.
abiFilters pins the set to the four the Rust is actually cross-compiled for, so
the APK's ABI list matches the build's intent rather than the union of every
dependency's history.
Found by unpacking the artifact rather than trusting the green: the run said
"Upload debug APK ✓", which is true and says nothing about what is inside it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Fifth run cleared ktlint and detekt and failed compiling the GENERATED Kotlin:
'message' hides member of supertype 'Throwable' and needs an 'override'
modifier
My design, surfacing one layer down. CoreError's variants carried a `message`
field, and uniffi turns an error enum into exception classes extending
Throwable — which already has `message`.
`#[uniffi(flat_error)]` is the right fix rather than renaming the field.
Renaming would dodge the collision and leave `e.message` null on the Kotlin side,
so every call site would have to know which variant it caught just to read the
text. Flat passes the Display string to the Throwable constructor, where Kotlin
expects it, and costs nothing that matters: each variant is still its own
subclass, so `catch (e: CoreException.NotLinked)` still works and a `when` is
still exhaustive. Only the fields stop crossing, and for every variant that has
one the field IS the Display string.
Confirmed by generating the bindings and reading them:
sealed class CoreException(message: String): kotlin.Exception(message) {
class NotLinked(message: String) : CoreException(message)
class Store(message: String) : CoreException(message)
class Network(message: String) : CoreException(message)
}
That check is worth keeping. thoughtsync-ffi already builds a HOST .so as part
of the workspace, and `--library` mode reads metadata straight out of it — so
the exact Kotlin the Android lane will compile can be generated and inspected
here, with no Android toolchain involved. It also let me verify the app's call
sites against the real generated API rather than against my assumptions about
uniffi's naming: ThoughtSync(dataDir), createNote(draft), listNotes(query),
Note.displayTitle, and NoteDraft/NoteQuery's parameter names all match.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Fourth run got the whole native pipeline through — cargo-ndk built all four
ABIs and uniffi generated the Kotlin — and then failed on style.
Two genuine mistakes, fixed:
* BoardViewModel's constructor parameter needed its own line.
* PaddingValues was written fully-qualified inline, which ktlint read as a
method chain. Importing it is what the rule was actually asking for, and
what the line should have said anyway.
The other ten were the tools not knowing this codebase:
* @Composable functions are PascalCase by universal Compose convention.
Exempted in BOTH .editorconfig (ktlint) and config/detekt.yml — they have to
agree or one of them is always wrong.
* MagicNumber on `private val Brand = Color(0xFFF5C518)`. The rule asks for a
well-named constant; that line IS one. ignorePropertyDeclaration.
* TooGenericExceptionCaught in the ViewModel and Application. Deliberate and
already commented: a note that fails to save must become a visible error
banner rather than a crash, and the store failing to open must still let the
app start so it can explain itself. Scoped to those two paths, not disabled
globally — everywhere else the rule is right.
Verified locally this time, both linters clean, using the SAME pinned CLIs from
ci-android:36 that the lane runs. ktlint and detekt are a formatter and a static
analyzer — the same category as cargo fmt and clippy, which is the precedent
ci-requirements already sets. No build was run locally.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Third Android run got further than either before it — all four ABIs
cross-compiled, vendored OpenSSL and all — then the generator died:
error: failed to run custom build command for `openssl-sys v0.9.117`
That is the HOST build. The generator was a [[bin]] inside thoughtsync-ffi, so
building it compiled that crate and therefore the core, reqwest, native-tls and
openssl-sys for linux. The vendored-OpenSSL block is scoped to
`cfg(target_os = "android")`, so the host build went looking for a system
OpenSSL that ci-rust-android has no reason to carry.
Adding libssl-dev to the image would have fixed it and been wrong: a code
generator has no business linking the app's TLS stack to emit Kotlin. Splitting
it into thoughtsync-uniffi-bindgen, whose only dependency is uniffi, removes the
entire chain. Verified from the dependency graph rather than from a build that
happened to succeed — `cargo tree -p thoughtsync-uniffi-bindgen` contains none of
openssl-sys, native-tls, reqwest, thoughtsync-core or rusqlite.
It stays a WORKSPACE MEMBER on purpose. Sharing one lockfile is what keeps uniffi
here and uniffi linked into the .so at one version; they are two halves of one
ABI, and a separate lockfile is precisely how they would drift apart. The cost is
that the desktop lane now compiles ~15 generator crates it never runs — cheap
next to Tauri, and better than leaving the crate unlinted.
Drops the `bindgen` feature and required-features bin from thoughtsync-ffi, which
existed only to keep those crates off the desktop lane and now have nothing to
gate.
Local fmt + clippy + test all green before pushing (107 tests).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Second Android run failed with AGP 9 refusing the previous fix by name:
You cannot add Provider instances to the Android SourceSet API. [...] Instead
you should use the Sources interface in the Variant API, in particular
SourceDirectories.addGeneratedDirectory
AGP cannot tell from a Provider whether the directory holds generated
(read-only) or hand-written (read-write) files, which is a distinction the IDE
needs. `addGeneratedSourceDirectory` is the supported route and — unlike the
plain-path form the error offers as an escape hatch — it carries the task
dependency, so Kotlin still cannot compile before the bindings are generated and
the APK cannot package a stale .so.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
First Android run failed at plugin resolution:
Plugin [id: 'io.gitlab.arturbosch.detekt', version: '2.0.0-alpha.3'] was not
found in any of the following sources
That version is published to neither Maven Central nor the plugin portal — the
latest detekt anywhere is 1.23.8. It was copied from Minstrel's catalog, where it
presumably resolves from a cached artifact; copying a pin without checking it
exists is what made it my problem.
Rather than chase a working plugin version, the analyzers now run from the CLIs
ci-rust-android already ships. That was the point of putting them in the image in
step 3, and going through Gradle plugins would have meant a SECOND pinned version
of each tool, resolved at build time, kept in lockstep with the image's by hand.
One less resolution step, and step 3's decision finally earns its keep.
Also replaces the source-ordering hack while here. Kotlin has to compile after
the bindings are generated, and the usual `tasks.withType<KotlinCompile>` cannot
be written in this build at all — AGP 9's built-in Kotlin means that class is not
on the buildscript classpath. Passing the TASK PROVIDERS to srcDir instead lets
Gradle read their @OutputDirectory and infer the ordering itself, which is the
idiomatic form and removes the dependsOn entirely.
Good news from the failed run: the Gradle wrapper check passed, so Gradle 9.1.0
on the image's JDK 25 works — the toolchain decision from step 3 holds.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The skeleton, and the lane that builds it. Gradle invokes cargo-ndk to
cross-compile thoughtsync-ffi for four ABIs, generates the Kotlin bindings from
the resulting .so, and packages both.
BUILT ON MINSTREL'S TOOLCHAIN, not a fresh guess. Gradle 9.1.0 / AGP 9.0.1 /
Kotlin 2.3.21 on JDK 25 is the combination already proven in this family on
ci-android, including the JDK 22+ native-access opt-in the launcher JVM needs
and the artifact-upload action pinned by SHA (issues 2255 / 2270). It also
independently confirms the JDK 25 call made on ci-rust-android in step 3.
Gradle wiring worth noting:
* ExecOperations, not project.exec — the latter was REMOVED in Gradle 9, and
touching `project` at execution time is also what breaks the configuration
cache this build enables.
* The cargo task's inputs are the Rust SOURCES, not the workspace directory.
Declaring the directory would make Gradle hash target/, which is gigabytes.
* Bindings are generated with `--library` against the built .so, so they can
never describe a different version of the Rust than the one being packaged.
* cargo runs --locked, so an Android build cannot silently re-resolve the
lockfile the desktop lanes are gated on.
JNA is a real dependency, with the @aar classifier. The plain jar builds fine
and fails at runtime with UnsatisfiedLinkError, which is the worst way to learn
it. R8 keep rules for JNA and the bindings are in for the same reason — that
failure would otherwise appear only in a minified release.
The UI is a working board, not a debug screen: capture field, note list, empty
state, error banner, and an honest failure screen for a store that won't open.
Rules 23/24 — a surface ships at quality from the first commit. Capture uses the
IME action key because the north star is a thought captured in under a second,
and leaves the title empty so the core derives it from the first body line.
Every core call runs on Dispatchers.IO: they are blocking FFI into synchronous
SQLite, and running them on the main thread is exactly the jank going native was
meant to avoid.
The launcher icon reuses frontend/public/icon-maskable-512.png as an adaptive
foreground on the brand #F5C518 — the same asset and colour the web app already
ships, so the three surfaces wear one face.
No signing config. A release keystore that has passed through an agent session
or shell history is compromised by construction (task 2136); it has to be
generated by the operator and reach CI only as a secret. CI builds debug.
CI can only prove this BUILDS — a Linux runner cannot execute an APK, so feel
and on-device correctness remain an operator pass on an emulator.
Scribe #2739.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
fmt was already documented here. Operator authorised clippy and test through the
same pinned image on 2026-08-18, so the section now covers the whole pre-push
loop rather than a third of it.
The commands are byte-identical to the workflow's on purpose — a local check that
differs from CI is worse than no local check, because it produces confidence
without coverage. That this is a faithful proxy is not an assumption: the local
test binary hashes matched CI run 3931's exactly (thoughtsync_core-bbaae797…,
thoughtsync_desktop_lib-9d162263…, thoughtsync_ffi-fc557b96…). Same image, same
lockfile, same compilation units.
Also records that target/ persists on the host, which is why the second run costs
~30s rather than several minutes, and that it is gitignored and disposable.
Scope note in the text: this authorises fmt/clippy/test only. Not the bundle
build, not a local stack.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The Clippy, Test and fmt steps ran with `working-directory: desktop/src-tauri`,
so cargo scoped them to the desktop PACKAGE. That was right while the desktop
was the only Rust in the repo. Extracting the core (M12 step 1) made it wrong
and nothing said so:
* the core's 89 tests have not run in CI since that extraction. They used to,
as part of the desktop crate, and moving the files out of that directory
quietly took them out of the lane.
* `android/ffi` was never compiled at all. I claimed the previous commit was
verified by this lane; it wasn't. Run 3928 went green without the word
"uniffi" appearing anywhere in its log.
Both crates still COMPILE, because the desktop depends on the core — which is
precisely why the hole was invisible. A green run kept meaning less than it
looked like it meant, and the tell was there to be read: the test output listed
`thoughtsync_desktop_lib` and nothing else.
Now run from the repo root with `--workspace` / `--all`. The lockfile gate keeps
its place on the first cargo invocation.
ci-requirements gains the rule and the reason, plus a note to check a new member
actually appears in the `cargo test` output rather than trusting the green.
Also corrects the lockfile procedure there to `cargo fetch` rather than
`cargo generate-lockfile`: both update the lockfile, but generate re-resolves
from scratch and bumps unrelated crates, turning a two-line manifest edit into
an unreviewable diff. fetch resolves minimally.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`android/ffi` is to Android what `desktop/src-tauri/src/commands/` is to the
desktop: a shim over the shared core holding no logic of its own. Third workspace
member, so the desktop lane's `cargo clippy --all-targets` compiles and lints it
— which until the Android lane lands (step 5) is the only thing that does.
Three decisions worth stating.
MIRRORED RECORDS, NOT DERIVES ON THE CORE. The core's model structs are serde
shapes contracted with the shared Vue frontend, and one of them holds a
serde_json::Value, which has no uniffi representation. Hanging uniffi derives on
them would couple two unrelated consumers to one definition. The cost of
mirroring is drift — an Android client quietly missing a field the desktop
gained — so every conversion destructures the core struct exhaustively. Add a
field to core::local::models::Note and this crate stops compiling until Android
is told what to do with it.
NoteEdit IS A LIST, NOT A STRUCT OF NULLABLE FIELDS. The store's patch format
distinguishes three states: leave alone, set, and clear to null. Kotlin cannot
express the third with a nullable field — `title = null` in a data class is
indistinguishable from `title` unset — so the editor could never clear a title.
Explicit Clear* variants say it out loud and give Kotlin a sealed class.
ASYNC IS TOKIO-BACKED, AND CANCELLATION ALREADY WORKED. Exported async methods
become Kotlin suspend functions. When a coroutine is cancelled uniffi drops the
future, and no async path in the core holds the store lock across an await —
a std MutexGuard isn't Send, so the compiler has been enforcing that all along.
A cancelled sync leaves the store consistent and simply hasn't stamped
last_sync_at, which is only written after both halves of a cycle succeed.
Also here:
* core gains Db::conn(). Every consumer was writing
`db.0.lock().map_err(|e| e.to_string())?` by hand, and worse, any helper
returning the guard had to NAME rusqlite::Connection — which would have made
rusqlite a dependency of a layer whose whole point is not knowing what the
store is made of. Same trap as the update.rs test module in step 1.
* The uniffi `cli` feature is gated behind our own `bindgen` feature. It drags
in clap, askama and goblin for a three-line binary, and the desktop lane
should not compile a code generator it never runs.
* The bindgen binary lives in this workspace on purpose: generated bindings and
the linked uniffi runtime are two halves of one ABI, and compiling the
generator against the same dependency keeps them in step by construction.
That is why ci-rust-android ships no uniffi-bindgen.
Tests cover the round trip the Android skeleton needs (open a store in a
directory that does not exist yet, write a note, read it back), that a body-only
note still has a display_title, that set and clear are genuinely different
edits, and that an unlinked app reports NotLinked rather than an error.
Known and deliberate: the workspace sets panic = "abort", so a panic crossing the
FFI aborts instead of arriving in Kotlin as an exception. Same behaviour the
desktop already has; noted in the crate header rather than silently changed.
Scribe #2733.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`ci-tauri-android` was repurposed into `ci-rust-android:1.97` rather than
deleted (CI-runner dc802f2, PR #12) — tauri-cli out, cargo-ndk in, ktlint and
detekt added so the Kotlin analyzer lane needs no second image, and JDK 25 now
that we hand-write the Gradle project instead of letting Tauri generate one.
Two things recorded here because they are constraints ON THIS REPO, not on the
image: our Gradle wrapper has to be 9.1+ for that JDK, and the Rust pin is in
lockstep with ci-tauri and ci-tauri-win because all three build
thoughtsync-core from one workspace Cargo.lock under --locked.
M12 step 3 (Scribe #2732). No workflow consumes the image yet; the lane arrives
with the app skeleton.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The extraction left update.rs's tests reaching for rusqlite and uuid directly to
build a Db — crates that now belong to the core alone, so clippy failed on
unresolved imports. The Windows job had already compiled the whole installer, so
this was only ever the test module.
Adding rusqlite as a dev-dependency of the desktop crate would have fixed it and
quietly undone part of the point: the desktop is not supposed to know what the
store is made of. So the core exposes open_in_memory() instead, which is what the
caller actually wanted, and the Android bindings will want the same thing when
they get tests.
uuid went the same way. It was generating unique scratch-directory names, which a
process id plus a counter does without a dependency — process id separates
concurrent cargo test runs, the counter separates tests within a run. The comment
right above it already said nothing there was worth a new dependency.
Verified the boundary holds in both directions afterwards: the desktop crate
references none of rusqlite/uuid/chrono/reqwest/sha2, and the core references no
tauri.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Android becomes a native Kotlin client over this same code (Scribe note 2730), so
the local store and sync engine stop being modules of the desktop app and become
`thoughtsync-core`, a crate with no UI framework in it at all.
This is a move, not a rewrite, and the measurement is why: every file in local/
and sync/ already carried ZERO Tauri references — 4,980 of 6,372 lines. The
coupling was 473 lines of command shim, which stays behind in the desktop crate
as src/commands/. Kept as git renames so history follows the files.
The desktop imports them under their old names (`use thoughtsync_core::{local,
sync}`) so every call site reads exactly as before. What moved is where they
live, not what they are.
Two things a workspace changes that are easy to miss, both caught before pushing:
[profile.release] now lives at the workspace ROOT. Cargo silently ignores
profiles declared by a non-root member — leaving it in the desktop crate would
have dropped lto/strip/opt-level from every release build with only a warning.
And a workspace shares ONE target dir, so the bundles moved from
desktop/src-tauri/target to target/. Thirteen references across publish-release,
debundle-graphics, verify.sh, package-prebuilt and the workflow now point there.
Pinning target-dir back would have been the smaller diff, but the Android lane
also produces Rust artifacts and they do not belong under desktop/.
Also retires the Tauri Android lane in the same push rather than leaving a path
that is being replaced: gen/android, android.yml and docs/android-dev.md are
gone, the mobile_entry_point attribute with them, and the lib drops to rlib —
staticlib/cdylib existed for Tauri mobile, and the .so Android loads will be
built from the core crate instead. Rule 22, no parallel path.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two things stop a fresh clone from opening in Android Studio, and both fail with
errors that name the wrong culprit — so they are written down rather than
rediscovered.
Android Studio runs Gradle on its bundled JDK 25, which Gradle 8.14.3 rejects
with an "Incompatible Gradle JVM version" message that reads like a project
misconfiguration. And settings.gradle applies tauri.settings.gradle, which is
generated per build and gitignored, so sync fails before anything can create it —
one CLI build fixes that permanently.
Also records why the Gradle pin is what it is, since the question came up and the
answer was not what it first looked like: the wrapper, the AGP pin and the
buildSrc file using the removed project.exec are all TRACKED in this repo. It is
scaffolding tauri android init wrote once, ours to bump when it is worth doing,
not a constraint of the framework. Tauri's own Android layer targets compileSdk
36 and registers back handling through OnBackPressedDispatcher — the library is
current, only the generated template trails.
Known gaps are listed so a tester does not file them as bugs: no safe-area
handling yet (2706), no enableOnBackInvokedCallback so predictive back will not
animate, and the templated app-wide usesCleartextTraffic that Minstrel already
hit as a Play Protect smell.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
arm64 is every real device, but a desktop emulator is x86_64 — an arm64-only APK
installs there and then dies unable to load its native library. A build nobody
can try on an emulator is a build nobody checks, which defeats the point of
producing an artifact at all while there is no phone in the loop.
armv7 and i686 stay out: 32-bit hardware we do not target, and the image carries
all four targets if that ever changes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Reminders was the last surface still reading as its own page — a bespoke row list
rather than the board's cards. It is now the same NoteGrid as every other lens.
The reason it wasn't already is that the list was a TRIAGE surface: one tap for
Done, 1h, 1d. Cards had none of that, so converting naively would have turned each
of those into open-act-close. Reminder upkeep is exactly the "maintenance must
stay dead simple or people stop coming back" case from the north star, so making
it three times more work to look tidier would have been a bad trade.
So the actions moved onto the card instead, shown wherever a note carries a
reminder — the board included. That turns out to be the better place for them
anyway: seeing something due while browsing and clearing it there is useful
outside the reminders lens. Always visible rather than hover-revealed, because a
finger cannot hover and these are the primary action on a due note; .chip-btn
takes the same coarse-pointer sizing rule as .icon-btn.
The card acts on the store directly, which the board picks up through reconcile.
The reminders lens fetches its own list, so it needs telling — hence the
reminder-changed event, which exists only for hosts that hold a list of their own.
Also carried recurrence (↻) onto the card. It was shown only in the reminders
list, so unifying would have silently dropped it; a repeating note now reads as
repeating on the board too. And the container went max-w-2xl → max-w-6xl, since a
narrower column would have reintroduced the different-page feeling the cards just
removed.
RemindersView is ~40 lines lighter for it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Which lens you're looking at is a property of the space, not of a page you
navigated to — so the name now sits in the bar that never moves, beside the app
name, and stays put while everything beneath it re-filters.
It replaces three per-view <h1>s that each sat in a different place with slightly
different markup (timeline, reminders, graph) and, more to the point, were absent
entirely on the board and in search — the two lenses people spend the most time
in had no name at all. A label lens is named by the label itself, because
"Groceries" is what the user came looking for and "Label" tells them nothing.
Shown at every width rather than hidden on small screens, which was my first cut
and would have been a regression: deleting the per-view titles while hiding the
shell one leaves a phone with no lens name anywhere, and Android is a peer surface
now. Below `sm` the app name is already hidden, so the lens name simply takes the
space it vacates — you know which app you're in; what you need is which lens.
The h1s on Settings, Sync, Account, Login and Register are untouched: those routes
render outside the shell entirely, so they have no chrome to be named by.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
"The same board, re-filtered" has to be literally true to read as true. The
column classes were copy-pasted into five places — the board's pinned and other
sections, its non-board branch, search, and timeline — so a lens could drift from
home by a single edit. One already had: the FLIP reflow from 1914 landed on the
board's three grids and left search and timeline popping. NoteGrid is now the only
file that knows how the masonry is laid out or how it moves, and search and
timeline gained the motion by adopting it.
It takes activeId rather than an index. The board splits its notes across two
grids, so index-based focus made the call site do offset arithmetic
(focusedIndex === pinnedNotes.length + i) against a list the grid didn't own.
The lens cross-fade is deliberately UNKEYED, which is the whole trick. Board,
archive, trash and label all render the same BoardView; keying the transition on
the route would remount it, blanking the board and refetching — exactly the
page-change feeling this is meant to remove. Unkeyed, Vue transitions only when
the component TYPE changes (board to search to timeline to graph), and moving
between the board's own lenses stays an in-place reflow that NoteGrid animates.
The two behaviours fall out of one rule rather than needing to be special-cased.
Out is quicker than in because mode="out-in" makes the durations additive.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two of M7's motion targets. prefers-reduced-motion was already in place from the
1999 pass and gates both of these for free.
FILTERED REFLOW. The three card grids become TransitionGroups sharing one
transition name, so "how the board moves" is defined once in CSS rather than
three times in markup. Vue's TransitionGroup does the FLIP itself — measure
before, measure after, transition the difference away — so no animation
dependency, which the task called for.
Leavers are deliberately NOT pulled out of flow with position:absolute, the usual
TransitionGroup trick. This masonry is CSS multi-column, and an absolutely
positioned child escapes its column to the container's origin: a note would fly
diagonally across the board on its way out. Keeping leavers in flow costs a small
settle when the element is finally removed, so the leave is the shortest of the
three durations.
EDITOR CONTINUITY. useNoteEditor.open() is the one place that knows which card
was clicked, so that is where the card's on-screen centre is captured; the editor
panel then scales from that point. Deliberately not a true shared-element morph:
scaling by the real card-to-panel ratio distorts the text on the way, and a card
is often a third of the modal, so an honest ratio reads as a zoom rather than a
transition. The task sanctioned a good-enough scale/position tween; this is that.
A point rather than a rect, because nothing needs the card's size and a point
survives the card being filtered away while the editor is open. Consumed on read,
so a compose — which has no card — cannot inherit the origin of whatever was
edited before it and grow from an arbitrary corner.
The animation lives inside NoteEditor rather than in the five views that render
it: the leave has to finish BEFORE the host unmounts, so the component owns its
own visibility and tells the host when it is done. visible starts true with
`appear`, because the panel lives inside that v-if and would not exist to measure
otherwise. The origin is measured with offsetLeft/offsetTop rather than
getBoundingClientRect — enter-from has already applied scale(0.94) by then, so
the bounding rect is of the shrunken panel and the origin would land off by a few
pixels. Offsets are layout geometry and ignore transforms.
Durations are 140-220ms. The brief is continuity, so a card should read as having
moved, not as having performed.
NOT verified: motion is a visual property and there is no frontend test lane, no
device, and no app run here. vue-tsc proves it compiles. Whether it FEELS right
is an operator live pass, which is what M7's own verification section asks for.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
First Android build failed at openssl-sys: "Could not find directory of OpenSSL
installation". reqwest is pinned to native-tls, which is right for Windows — it
resolves to schannel there and keeps C and assembly out of the cross-compile —
but on Android it resolves to OpenSSL, and there is no Android OpenSSL in the
image to link against.
Vendored rather than rustls. rustls builds faster and was the obvious fix, but it
ships its own root store, so the phone would trust a different set of
certificates than the desktop: a self-hosted server behind a private or
enterprise CA would work on one surface and fail on another. Peer surfaces that
quietly disagree about who to trust is a worse outcome than a slower build, so
one TLS stack stays everywhere and OpenSSL gets compiled from source with the NDK
toolchain — which is what perl and make are in ci-tauri-android for.
Scoped to cfg(target_os = "android") so nothing changes for the Linux, Windows or
web lanes; declared as a direct dependency purely to flip the feature, since
cargo's unification then applies it to the copy native-tls pulls in.
Cargo.lock regenerated in the same commit, per the documented procedure — the
--locked gates in every lane fail otherwise. openssl-src 300.6.1+3.6.3 joins.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The phone client is Tauri v2 mobile (operator decision), so it reuses the Vue
frontend and the Rust store and sync engine that already exist rather than
becoming a third implementation to keep in step by hand.
gen/android is committed. tauri android init generated it, its own .gitignore
already excludes the build outputs and every keystore file, and CI must not have
to regenerate a project that manifest edits will accumulate in.
What the scaffold confirms is that the image's JDK pin was load-bearing rather
than incidental: Tauri templated Gradle 8.14.3 with AGP 8.11.0, and CI-android's
versions.env records that JDK 25 needs Gradle 9.1.0+ and that anything older
fails with an opaque "25.0.3" message. Picking 17 for ci-tauri-android avoided
exactly that. namespace and applicationId came out as com.fabledsword.thoughtsync,
matching the desktop identifier, so the app-data story stays consistent.
The lane builds a DEBUG APK for arm64 only. Release APKs need signing, and the
keystore has to be generated by the operator and never pass through CI logs or an
agent session — the constraint recorded for the updater key applies unchanged.
Gradle's throwaway debug keystore needs nothing from anyone, so this can prove the
app compiles and packages today and grow a signed job when a key exists. arm64 is
every real device; the image carries the other three ABIs, so widening is a word.
Triggered by frontend/** as well as desktop/**, because generate_context! compiles
the frontend into the app — the same reasoning that widened desktop.yml. Android,
desktop and web are peers on one quality bar, and a frontend commit that skipped
this lane would ship a stale phone build.
Green here will mean it BUILT. A Linux runner cannot execute an APK, so nothing in
this lane proves the app runs, renders, or is usable by finger.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Native HTML5 drag-and-drop never fires from touch — the API predates it and was
never wired to it — so on a phone reordering did nothing whatsoever, and the grip
that starts it was hover-gated on top of that. Pointer Events cover mouse, touch
and stylus on one code path instead of two.
The awkward part is hit-testing. Native DnD routed dragover/drop to whatever was
under the cursor, so each card learned on its own that it was the target. A
captured pointer sends every move to the element that captured it, so the dragged
card has to hit-test for itself and publish the result where the other cards can
see it — hence the shared refs in useCardDrag. It reads the DOM via
elementFromPoint rather than tracking geometry because the board is a CSS masonry:
visual order isn't derivable from model order, and cards reflow as the column
count changes. Asking the browser what is actually under the finger is the only
answer that stays true.
Capture is what makes the gesture survive crossing a card boundary; touch-action:
none claims it from the browser's scrolling; a 6px threshold keeps a tap from
becoming a drag; and pointercancel is handled so a system interruption leaves no
half-set state.
The parent contract is unchanged apart from `drop` now carrying the target's ID
rather than its note — the dragged card finds its target in the DOM, so an id is
all it can know without a second lookup. BoardView keeps its own tracking of what
was picked up; that it now duplicates the composable's draggingId is real, and
noted for the DRY pass rather than expanded into here.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A finger cannot hover, and on a note card the hover toolbar is the only way to
pin, colour or archive — so on a phone those notes could not be acted on at all.
Same for deleting a checklist item, a saved view, an attachment or a preview.
Marked rather than rewritten inline: one `.hover-reveal` class on the five
elements and a single rule that says what it is for. The `group-hover:` reveal
stays in the markup because the trigger differs per component (named groups);
only the fallback is shared. `@media (hover: none)` asks the device directly,
which is more honest than inferring from viewport width — a narrow window on a
laptop still hovers, and a large tablet still doesn't. It sits after the Tailwind
directives so it beats the opacity-0/pointer-events-none utilities on source
order without !important.
Tap targets follow the same shape: p-1.5 around an 18px icon lands near 30px,
which is fine for a cursor and too small for a thumb. Bumped to 44px on coarse
pointers only, so desktop chrome doesn't inflate.
The drag grip is deliberately NOT revealed yet. Reordering still uses HTML5
drag-and-drop, which never fires from touch, so showing the handle would only
promise something that does nothing. It comes with the pointer-events rewrite.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
BaseModal declared role="dialog" aria-modal="true" and then enforced none of it.
Focus never moved into the panel, so Escape — handled ON the panel — did nothing
at all in LabelsModal, the integration prompt and the shortcuts modal. Only the
command palette escaped correctly, and only because it happens to focus its own
input. Tab walked straight out of the dialog into the page that aria-modal had
just told assistive tech was inert, and closing dropped focus to <body> so the
next Tab restarted from the top of the document.
All three are one contract, so it lives in BaseModal rather than in each of the
four callers: focus in on open, Tab trapped, focus restored to the opener. The
panel takes tabindex="-1" so it can hold focus itself when it wraps nothing
focusable. CommandPalette's input focus still wins, because a child's mounted
hook runs before its parent's.
The skip link is the other half. The header and sidebar are a dozen-odd tab stops
that repeat on every navigation, and a keyboard user walked all of them again to
reach their notes. <main> takes tabindex="-1" as well, because several browsers
scroll to a bare anchor without moving focus to it — which would have made the
link look like it worked while leaving the next Tab back at the top.
The rest of the audit came back clean: no click handlers on non-focusable
elements, and all 30 focus:outline-none uses already pair with a focus-visible
ring. M3.5's keyboard pass held up; the gaps were in focus management, not
styling.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign out was a trap on the desktop, not an action. It nulls the synthetic local
user and redirects to /login, but the offline adapter rejects every sign-in with
"there's no account to sign in to" — so the only way back into your own notes was
to restart the app. There is nothing to sign out of; the notes are on this
machine either way.
Linked devices was a quieter version of the same thing: it lists the tokens a
SERVER has issued to native clients, and the desktop is one of those clients, so
offline the list is always empty and issuing a token rejects. Its actual
relationship with a server already has a home at /sync. Also hid the account
name, which named a login the app doesn't have.
/account is now blocked in the router too, not merely hidden — the mirror of the
existing requiresDesktop guard — so a typed URL or a restored history entry
can't reach the dead end either. Deliberately not applied to /login and
/register: bouncing those on desktop would loop against the requiresAuth guard
whenever a session is missing.
The launch flash is the window painting before the webview does, showing the
platform default white through the gap — worst on a dark-mode desktop, and
widened by the software rendering we force on Linux. Set from the live system
theme rather than app.windows[].backgroundColor, because that config carries one
static colour and either choice would fix half of users while introducing the
same flash for the other half.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two halves of the same gap. The app had no reduced-motion handling at all — the
setting appeared nowhere in the frontend — and the desktop build didn't rebuild
on frontend changes, so shared UI work shipped to the web and silently never
reached the desktop app.
The CSS guard is global and blunt so it catches every Tailwind `transition`
already scattered through the components, and catches M7's motion work without
each new component having to remember. Near-zero durations rather than `none`,
so transitionend/animationend still fire and nothing waiting on them hangs.
useReducedMotion covers what CSS can't reach: JS-driven motion, where the honest
response to the preference is no animation at all rather than a faster one. It's
reactive because the setting can change while the app is open.
The path filter was narrowed to the adapter/bridge directories against a
"~20-40 min" build cost recorded in the header. Measured runs are 4-5 minutes,
so that cost isn't there, and the frontend is compiled into the binary by
generate_context! — any part of it changing means the shipped desktop app is
stale. Desktop, web and Android are peer surfaces on one quality bar, so shared
frontend work has to reach all of them by construction rather than by whichever
directory it happened to touch.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A fresh desktop install has no login — auth_me returns a synthetic local user so
the shared router's guard resolves — but nothing said so. You landed on a bare
board with no way to tell whether the app was storing your thoughts on this
machine, waiting for a credential, or quietly shipping them somewhere.
The start state is the empty board itself, not a welcome modal or an onboarding
gate. The product exists to take a thought in under a second; spending that
second on a dialog taxes the one thing it is for. It also means there is no
"seen it" flag to persist, migrate, or let drift out of step with reality — the
message retires itself the moment a first note exists, which is exactly when it
stops being true that you have nothing here.
Shown only when the app is unlinked: offering to connect a server to someone who
already has one is noise. The status read is best-effort and never awaited, so
the board renders at full speed regardless; if it fails we keep showing the
offline copy, which is the honest reading of "we know of no server".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The app answered to three different names depending on how it arrived, and the
part that actually hurt was WM_CLASS. Reading tauri-bundler settles what it is:
the generated .desktop template writes StartupWMClass={{exec}} where exec is
main_binary_name, and tao creates its GtkApplication with a NULL app id
(enableGTKAppId defaults off), so GTK falls back to the program name. WM_CLASS
is the binary name, nothing else.
Which inverts this issue's premise. The rename could not break grouping,
because two channels weren't grouping in the first place: pacman ships
/usr/bin/thoughtsync and the AppImage's AppRun execs thoughtsync-desktop, while
all three hand-written entries hardcoded StartupWMClass=ThoughtSync — a string
no binary in any channel has ever reported. Only the .deb worked, and only
because Tauri generates its entry from the binary and never consulted us.
So: thoughtsync everywhere, carried by the build target itself via Cargo [[bin]]
plus mainBinaryName rather than by the install path, since the target name is
what the desktop reads. The pacman package sheds its -desktop suffix and
declares conflict+replaces so an upgrade retires the old one instead of landing
beside it and fighting over /usr/bin/thoughtsync.
The .deb verifier now asserts binary path, Exec and StartupWMClass all agree,
which is the part that keeps this fixed: the .deb's entry is the one no human
writes, so it's the one that drifts silently.
Package: thought-sync stays. tauri-bundler derives it as kebab-case(productName)
with no override, and rewriting a control archive on every build is a poor trade
for one uninstall command.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The desktop crate is a binary, and binaries commit their lockfile. Without one
every run re-resolved the graph: a tagged .deb/.AppImage/.exe couldn't be
rebuilt from its tag, any semver-compatible upstream release landed
automatically on the next build — the failure mode hardest to read, because the
commit that broke it changed nothing relevant — and Renovate had no lockfile to
bump, leaving Rust dependency movement invisible to the Dashboard.
Generated with cargo generate-lockfile inside ci-tauri:1.97, the same image CI
builds in, so the format and the picked versions are what CI would have chosen
itself. That takes the artifact-upload round-trip the issue proposed off the
table: ci-requirements.md already blesses the image for cargo fmt, and resolving
a dependency graph is no more a build than formatting is. 503 packages.
Enforcement goes on each job's FIRST cargo invocation rather than the bundle
build: cargo clippy --locked on Linux, and its own cargo fetch --locked step on
Windows, whose only crate-graph command is otherwise the cross-compile itself.
Drift fails in the first thirty seconds instead of thirty minutes in, and
everything after the gate in that job compiles the recorded versions anyway.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Unlink was local-only. It cleared the server URL, token and cursor from the
device, and left the bearer token valid on the server indefinitely — so someone
who unlinked because the laptop was being sold or handed on believed they had
revoked access when they hadn't.
The blocker was identification, not intent: a token pasted from the web app
never carried a device id, and /api/auth/me describes the user, not the device
row, so DELETE /devices/<id> could only ever have worked for one of the two ways
this app can be linked. DELETE /api/auth/devices/self keys off the token in the
Authorization header instead, which the caller always holds — one route that
works for both paths, owner-scoped like the rest, and no local schema change.
Unlinking is never blocked on the network. Wanting to stop syncing is a local
decision, so the revoke is attempted first, its outcome carried back, and the
link cleared either way. When the token survives — server unreachable, or older
than the route — the Sync screen says so in place, with where to revoke it. A
toast would have been the wrong shape for that: it disappears, and this is
exactly what someone returns to the screen to check.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`install.sh --channel dev` set the channel in the installer and nowhere
else. The app kept its `stable` default, stable advertises 0.1.0, and
0.1.0 is older than any dev build — so every update check said "up to
date", forever, and the user had to know to go set it themselves.
The installer now records the channel as a plain file in the app-data
dir; the app adopts it at startup. A file rather than a write into the
app's SQLite store, because shell has no business knowing that schema.
Adoption compares against the value last adopted, not against "is the
pref unset". Seeding only when unset would have fixed the first install
and left the second silently wrong: install stable, then install dev,
and the pref is already set so dev never takes. Comparing to the last
marker makes both directions work — an in-app channel switch survives
the next launch, and re-running the installer on a different channel is
honoured.
An unreadable marker is ignored rather than read as `stable`, so a
truncated file can't move someone off the channel they're on.
Four references to "Forgejo" actually meant this instance, which has run Gitea
since the migration: the registry push, the missing /releases/latest/download
route, the API a packaging script resolves URLs against, and the 422 on an
illegal JSON escape.
Kept as-is — these are genuinely about the upstream Forgejo project, not us:
the `forgejo/upload-artifact` mirror and "the Forgejo project's fork".
Prose only — no workflow, path, or script change. Scribe issue #2272.
Both desktop upload steps used actions/upload-artifact@v3, which reports
success while Gitea stores the result in a format its v4-only artifact API
will never serve back — 110 artifacts on this repo are on disk, have valid
DB rows, and are invisible to the REST API, the web download route and the
MCP tools alike. Green jobs producing nothing retrievable.
Point both at bvandeusen/upload-artifact (pull mirror of the Forgejo
project's fork, GHES refusal disabled), pinned by SHA because the mirror
auto-syncs. Not actions/upload-artifact@v4: its isGhes() throws on the
hostname before opening a connection, so no server-side change reaches it.
Also drop continue-on-error and set if-no-files-found: error on both steps.
Between them, a failed or empty upload was reported as a green run — the
same silence that let this go unnoticed for a month.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Run 2981 built everything and then died posting the release: HTTP 422,
"invalid escape sequence \`". The body's other backticks are written \` because
they sit in an UNQUOTED heredoc, where that backslash is the shell's and is gone
before any JSON exists. Copying the idiom into a single-quoted variable changed
what it meant — single quotes already stop substitution, so the backslash
survived into the body as an escape JSON has no rule for.
bash -n passes either way; it checks syntax, not what a string becomes. So parse
the assembled body for every branch it can take instead, and write down the
recipe next to the one for formatting Rust.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MKsUY9Z45KQd34V956hZ9Q
`git push origin dev` fails outright now that the rolling channel put a TAG
named `dev` beside the branch, and the error names neither. And nothing in CI
lints the packaging shell scripts, so a broken installer surfaces when a user
runs it rather than when it's built — record how to check them locally.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MKsUY9Z45KQd34V956hZ9Q
install.sh asked /releases/latest and installed whatever came back. That is
v0.1.0 today, which predates the updater, and it was about to get worse: the
`stable` pointer release write-manifest.sh creates is non-prerelease and holds
only latest.json, so from the next v* tag onward it would have WON
/releases/latest and the installer would have found nothing to install.
So resolve a channel instead of a "latest". `--channel stable|dev` (or
TS_CHANNEL), default stable, named to match update.rs's Channel exactly. dev
reads /releases/tags/dev. stable reads the pointer's own latest.json, takes its
version, and installs that v* release — the same file the app reads, so the
installer and the updater cannot disagree about what stable means.
Two things found on the way. The dev release's description still told people to
run the stable command, and always would have: publish-release.sh writes a body
only when it CREATES a release, and a fixed-tag release is only created once, so
the text froze at the first build. The 409 path now PATCHes it. And the asset
greps were unanchored, so a .AppImage.sig URL could match as the bundle URL —
harmless by coincidence, not by construction.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MKsUY9Z45KQd34V956hZ9Q
Two halves of one mistake, both visible on the dev release right now: the
manifest said 0.1.134 and pointed at ThoughtSync_0.1.132_amd64.AppImage.
The rolling channel accumulates every build's assets, and the manifest picked
its bundle by file extension with `head -1` — the OLDEST match. A client would
have been told 0.1.134 was available, downloaded 0.1.132, installed it, and
been offered 0.1.134 again. Forever.
Signature verification could not have caught it. The old bundle's signature is
perfectly valid for the old bundle; nothing about it says "this isn't the build
the manifest claims". Selection is now matched on the build's own version
string, so the manifest can only ever describe the binary it was written for.
The accumulation is the other half. Nothing can reach a superseded build once
the manifest moves on, and an AppImage is ~100 MB — three pushes had already
left 300 MB of unreachable binaries on the Git host. A rolling channel now
prunes everything but the current build once the manifest points at it.
Versioned releases are untouched: that IS the archive, and the stable pointer's
URLs aim into it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi
The de-bundle step deletes the AppImage and repackages it without the host
graphics libraries — necessary, and it runs AFTER tauri signed the original.
So the .sig published on the release described a file that no longer existed,
and every Linux in-app update would have failed signature verification.
Worth naming the failure mode: the error would have said the signature didn't
match, which points at the key, the manifest, or the download — anywhere except
"a later build step rewrote the file after signing it". The Windows lane hid it
too, because nothing post-processes the NSIS installer, so the one platform
already verified working was the one platform that couldn't reveal the bug.
Signs the file that actually ships, and fails the build if no .sig comes out
rather than quietly publishing an unverifiable bundle.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi
It read the version straight out of tauri.conf.json, which was correct until
dev builds started overriding the version on the command line — the file still
says 0.1.0, so release `dev` came out carrying a pacman package labelled 0.1.0
around a binary that reports 0.1.132.
Nothing breaks from it (a pacman install can't self-update anyway), but a
package that lies about its version is exactly what makes a later "which build
is this?" impossible to answer. Now uses the same build-version.sh the bundles
and the manifest do.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi
2026-07-27 15:07:40 -04:00
362 changed files with 46308 additions and 6574 deletions
echo "::warning::No ANDROID_KEYSTORE_BASE64 secret. Building an UNSIGNED DEBUG APK: it cannot be installed over a signed build and cannot self-update."
<!-- Renaming onto an existing tag merges the two, older survives (Scribe
#3324). A merge cannot be undone by repeating it and is reachable here by
a typo, so it says so before it happens — same reasoning as #2116. -->
<stringname="tags_rename_merges_title">Merge with %1$s?</string>
<stringname="tags_rename_merges_body">A tag called %1$s already exists. Renaming will merge these two into one, carrying every note from both. The notes are kept; one of the two tags stops existing, and that cannot be undone.</string>
<!-- The survivor is named in the button, not just the title: this is the one
operation here that repeating does not undo. -->
<stringname="tags_merge_body">Every note tagged %1$s will be tagged with the one you pick instead, and %1$s will stop existing. The notes are kept.</string>
<stringname="tags_merge_none">There is no other tag to merge into.</string>
<stringname="tags_delete_body">It will be removed from every note that has it, on every device you sync with. The notes themselves are kept.</string>
<stringname="tags_delete_body_counted">It is on %1$d notes. It will be removed from all of them, on every device you sync with. The notes themselves are kept.</string>
<stringname="tags_delete_confirm">Delete</string>
<!-- A tag written as #tag in a note's body is owned by that text. Deleting the
row cannot un-write the word, so it comes back on that note's next edit —
said here rather than left as a surprise. -->
<stringname="tags_delete_from_text">Tags written as #tag in a note come back when that note is next edited.</string>
<stringname="tags_cancel">Cancel</string>
<!-- Pickers -->
<stringname="label_picker_title">Tags</string>
<stringname="label_new_hint">Type a tag and press enter</string>
<stringname="label_from_tag">from the text</string>
<stringname="label_none_body">No tags yet. Type one above, or write a #tag in a note and it becomes one.</string>
<stringname="picker_next">Next</string>
<stringname="picker_set">Set</string>
<stringname="picker_time_title">Pick a time</string>
<stringname="store_unavailable_title">Your notes couldn\'t be opened</string>
<stringname="store_unavailable_body">The note store on this device could not be read. Reinstalling will start a fresh one, but anything not synced to a server would be lost.</string>
<!-- Sync. Opt-in, and the copy has to carry that: being unlinked is the
normal resting state of a local-first app, not unfinished setup. -->
<stringname="sync_unsent">This device has changes that haven\'t been sent yet.</string>
<stringname="sync_now">Sync now</string>
<stringname="sync_disconnect">Disconnect</string>
<stringname="sync_disconnect_title">Stop syncing with this server?</string>
<stringname="sync_disconnect_body">Your notes stay on this device, and the copy on the server is left alone. This device\'s access token is revoked, so it can\'t be used to reach the server again.</string>
<stringname="reminder_channel">Reminders</string>
<stringname="reminder_channel_description">Notifies you when a note\'s reminder is due.</string>
<stringname="reminder_inexact_title">Reminders may arrive late</string>
<stringname="reminder_inexact_body">Without permission for exact alarms, Android delivers reminders when it next wakes the phone — usually within a few minutes, sometimes longer.</string>
<stringname="update_needs_server">App updates come from a server you connect. Until then, install new builds yourself.</string>
<stringname="sync_footer">Your notes live on this device either way — syncing just keeps a server copy in step, so your other devices can catch up.</string>
<stringname="sync_rejected_title">The server wouldn\'t accept some changes</string>
<pluralsname="sync_rejected_body">
<itemquantity="one">%1$d change was rejected: %2$s</item>
<itemquantity="other">%1$d changes were rejected: %2$s</item>
</plurals>
<stringname="sync_degraded_title">Some features aren\'t available here</string>
<stringname="sync_degraded_body">This server doesn\'t support: %1$s. Everything else syncs normally.</string>
<!-- Unlinked -->
<stringname="sync_offline_title">Working offline on this device</string>
<stringname="sync_offline_body">Everything works without a server — your notes are stored on this phone. Connect an Inkwell server if you want them to reach your other devices.</string>
<stringname="sync_insecure_body">You\'re about to sign in over plain http. Anyone on the same network can read your password and your notes. Use https unless this is a server you control, on a network you trust.</string>
<stringname="sync_signin">Sign in</string>
<stringname="sync_mode_password">Email and password</string>
<stringname="sync_token">Paste a device token</string>
<stringname="sync_token_help">Create one in the web app under Account → Linked devices.</string>
<stringname="sync_device_name">Name for this device</string>
<stringname="sync_device_name_help">Shown in your account\'s list of linked devices.</string>
<stringname="sync_connect">Connect and sync</string>
<!-- An unlink whose server-side revoke didn\'t land leaves a live credential.
Never a transient message: someone disconnecting to retire a phone has to
still find this when they come back to check. -->
<stringname="sync_revoke_title">This device\'s token is still valid on the server</string>
<stringname="sync_revoke_unsupported">This server is older than in-app sign-out, so this device\'s token had to be left in place. Revoke it in the web app under Account → Linked devices.</string>
<stringname="sync_revoke_failed">%1$s Until it\'s revoked, this device\'s token still works — you can revoke it in the web app under Account → Linked devices.</string>
<!-- What a sync did. Counts what MOVED; batches, pages and cursors are real
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.