53 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5	6fbee27f9c	A tag with no colour of its own derives one from its name ... Every #tag ever typed is `default`. `notes/tags.py` mints one as `Label(owner_id=…, name=name)` with no colour, so it takes the column default — which means tag-driven note colour, built on top, would have left the board exactly as grey as it was. Four #todo notes in the operator's screenshot, four different colours, because the tint is per-note-id and ignores tags entirely. DERIVED RATHER THAN PERSISTED AT MINT TIME, reversing the plan in 2965. That plan wanted a hashed colour written wherever a label is born, and named the risk in its own body: `find_or_create_label` is "easy to miss, and it is the common one", because most tags are born from typing `#grocery`, not from a management screen. Deriving has no mint points to miss, needs no backfill for the tags that already exist, and reuses the hash and the fixture the notes already have. The cost is that renaming a tag recolours it. That is defensible — the name IS the tag — and an explicitly picked colour is still stored and still wins, so tag colours stay editable exactly as asked. Lowercased before hashing: tags dedupe case-insensitively, so #Todo and #todo are one tag and must not be two colours. All five places a label's colour is drawn now resolve the same way — the card chip, the editor chip, the drawer's tag list, and the management modal's dot and swatch ring. The modal's ring follows the resolved colour rather than the stored one, so opening the picker highlights what you can already see instead of nothing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 12:57:59 -04:00
bvandeusenandClaude Opus 5	cddaf35280	android: ktlint forces a multiline signature at two parameters ... `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>	2026-08-26 12:38:23 -04:00
bvandeusenandClaude Opus 5	6f173b166b	Every note carries a tint, derived from its id ... The board was a wall of white rectangles: `default` is the colour nobody picks, so it was the colour of every note except the two the operator had coloured by hand. Reported twice — 2026-08-23 as "a wall of broken up text", and again today as "all the existing notes are the same dull color". The ask was "random subdued colors", but random is the one thing it must not be. A tint rolled at render time would differ between the phone and the browser and change on every reload. FNV-1a over the note's id is deterministic, identical on every surface, needs no column and no migration, and a note keeps its colour for life — which is what "random" meant here. Two implementations, deliberately mirrored, same discipline as the checklist grammar. The Kotlin half lives in a Compose-free file so a host-JVM test can pin the fixture; the TypeScript half carries the same four ids and hashes as a comment because the frontend has no test runner at all — its whole CI lane is `vue-tsc --noEmit`. That asymmetry is worth naming rather than papering over. A draft has no id yet (DRAFT_ID is ""), so it stays white until it is saved. Hashing the empty string would give every draft one shared tint and then change it on save anyway — two surprises where one will do. An explicitly-picked colour still wins. The picker is on its way out (milestone 309 step 5) but it has not gone yet, and a hand-coloured note changing under the operator would read as data loss. First of five steps toward colour coming from tags. This one stands alone: no storage change, nothing removed, and the board stops being white today. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 12:26:01 -04:00
bvandeusen	f92a3d0a99	android: detekt's return limit, on two functions I wrote after it caught me once ... `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.	2026-08-26 10:01:24 -04:00
bvandeusen	1e2b42af25	android: say nothing until the update is downloaded, and only fetch on wifi ... 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.	2026-08-26 09:53:40 -04:00
bvandeusen	a48b034a94	android: my insertion stole downloadTarget's doc comment ... 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.	2026-08-26 08:43:42 -04:00
bvandeusen	ee47a61270	android: find updates without being asked, fetch them, then nag ... `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.	2026-08-26 08:34:28 -04:00
bvandeusen	68f851110f	android: checklist rows were still 48dp of touch target ... 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.	2026-08-26 08:31:21 -04:00
bvandeusen	44b3bcb2b2	Correct a claim about the operator's data, and the first-row delete ... 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.	2026-08-26 07:44:31 -04:00
bvandeusen	a45a44ef11	android: split the block model from the block UI ... 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.	2026-08-26 07:13:27 -04:00
bvandeusen	56264a9220	android: the checklist rows were carrying a form field's padding ... 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.	2026-08-26 07:03:15 -04:00
bvandeusen	a88f7c2dd0	core: drop the two helpers the block editor made unnecessary ... `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.	2026-08-24 10:42:26 -04:00
bvandeusen	32ec29fc4a	android: the comment pointed at the file's old name	2026-08-24 10:32:55 -04:00
bvandeusen	ae17b8a8e7	android: name the file after the type in it ... 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.	2026-08-24 10:32:45 -04:00
bvandeusen	eeca4d48c2	android: a trailing blank line where the dead helpers used to be ... 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.	2026-08-24 10:23:59 -04:00
bvandeusen	b2435d97b6	android: the editor draws the checklist instead of the markup for one ... 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.	2026-08-24 10:14:53 -04:00
bvandeusen	9a3c4ec377	android: ticking a box on a card threw the editor open on top of it ... 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.	2026-08-24 09:59:00 -04:00
bvandeusen	315c5f19e6	android: detekt caught a callback that never reached the cards ... 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.	2026-08-24 08:35:52 -04:00
bvandeusen	77b1a87712	android: ktlint on the import order and a leftover blank line ... 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.	2026-08-24 08:26:01 -04:00
bvandeusen	68b2a5dc8d	android: a checklist is lines of the note here too ... 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.	2026-08-24 08:16:57 -04:00
bvandeusen	668f7faf03	core: the body is the checklist, and checklist_items is gone ... M304 steps 2 and the client half of 4, together — they cannot be separated. A commit where the store writes items into the body while push.rs still reads them from a table is one that silently pushes the wrong list, and dev publishes to the dev channel on every green build. Store: * load_items becomes items_of(body) — a parse, not a query. An item's id is its ORDINAL, which is all it ever amounted to: push.rs sent text and checked and never an id, and both sides replaced the whole list on every sync. * add_item / update_item / delete_item route through update_note, so they get revision snapshotting, #tag re-derivation and the dirty/updated_at bookkeeping without any of it being written a second time. * create_note folds its items: input into the body, and syncs tags from the FOLDED body — an item can carry a #tag too. * display_title no longer takes items, because items ARE body lines now. It strips the task marker instead: a list-only note is still named by its first item, and calling that note "- [ ] milk" would show someone the storage. Wire: items leave it. A second copy of data already in the body field of the same message is how the two come to disagree. CLIENT_PROTOCOL_VERSION and MIN_SERVER_PROTOCOL_VERSION go to 3, which is what makes this safe to land before the server: a v3 client refuses a v2 server outright rather than pushing a body whose list the old _apply_note_items would then delete. Schema v8 folds every existing row into its note's body before dropping the table. Written in Rust, not SQL: the fold has to produce exactly what derive::append_item produces, and group_concat only gained a guaranteed ORDER BY in SQLite 3.44 — a checklist that quietly reordered itself during a migration would be a poor way to learn that. updated_at and dirty are deliberately left alone, because the server's migration folds the same rows the same way and both sides land on identical bodies; marking every note dirty would push a body the server already has, from every device at once. NOT deployable yet. The server still speaks v2 and still has note_items, so a client built from this will refuse to sync until the server half lands.	2026-08-24 00:41:23 -04:00
bvandeusen	65af37d159	android: a checkmark to leave, and asking for a checklist stops writing a blank one ... 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.	2026-08-23 23:50:30 -04:00
bvandeusen	8257e1035c	android: put the way out of a note back within reach ... 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.	2026-08-23 23:46:03 -04:00
bvandeusen	bca9e16bd0	android: ktlint wants that body expression on one line	2026-08-23 22:30:56 -04:00
bvandeusen	9ea2a2f9b6	android: the toolbar moves to the top, and the note says when it saved ... 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.	2026-08-23 22:26:12 -04:00
bvandeusenandClaude Opus 5	ce6a1093a3	android: writing a note and editing one are the same surface ... 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>	2026-08-23 22:14:02 -04:00
bvandeusenandClaude Opus 5	24685556b7	android: open an existing note ready to keep writing ... 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>	2026-08-23 21:00:57 -04:00
bvandeusenandClaude Opus 5	50e2d308ea	android: the editor toolbar was black icons on a near-black bar ... 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>	2026-08-23 17:40:28 -04:00
bvandeusen	95aa10c2c3	Remove the title field — a note is named by its first line ... Operator (note 2897): "notes shouldn't have a title field." The concept of a NAME stays — search results, export filenames and the command palette all need one — but nothing is typed into it any more. `display_title` is now the first non-empty line of the body, falling back to the first checklist item. That fallback is what step 2 bought, and the reason this could not go first: a checklist had no body to be named from, so the title was its only name. Now every note has a body, and a note that is only a checklist is named by its first item. Gone everywhere: the column and note_revisions.title (0026), the field on the core's Note/NoteCreateInput/NoteRevision and its SQLite columns (user_version 7), `normalize_title`, the wire field, the FFI record and `NoteEdit::Title` / `ClearTitle`, the web editor's "Title (optional)" input and the card's <h3>, and the Android title field in both the compose sheet and the editor. **The search vector had to be rebuilt, not just left alone.** `notes.search_vector` is a STORED GENERATED column whose expression names `title` — Postgres refuses to drop a column another generated column depends on. It is dropped and recreated over `display_title` at weight A, which keeps the original intent: a note's NAME ranks above the rest of its body. **An imported title becomes the note's first body line.** Keep notes carry one, and so does any ThoughtSync export taken before this. Dropping it would silently lose text someone wrote; folding it in puts it exactly where a name now lives, so the note arrives named as it was. Skipped when the body already opens with that line, so re-importing an export this code produced doesn't stack duplicates. Two smaller things fell out. The Android editor loses its bold first field — one weight throughout, because the first line is the note's name but not a different KIND of text, which is most of step 4 arriving early. And `ClearTitle`'s justification comment moved to `ClearRemindAt`, which is now the surviving example of why NoteEdit is a list rather than a struct of options. Protocol note corrected to say what actually shipped: v2 is "no kind, no title", one bump for the pair. Verified with the local Rust gate this time, not by CI: fmt, clippy and 116 tests all green before pushing. It caught four things — orphaned serde attributes where fields were removed, a `wire::Preview.title` I deleted by mistake (a link preview still has one), nine retention fixtures inserting a dropped column, and four rustfmt diffs.	2026-08-22 19:33:57 -04:00
bvandeusen	6d778f26a7	Fix the ktlint and compat-test failures, and start using the Rust gate ... Two more from the step-2 removals: **Two unused Kotlin imports** — `FilterChip` (the Note/List switch) and `Icons.Filled.Create` (the "switch to a note" icon), both orphaned when their callers went. ktlint treats them as errors. **`server_info_tolerates_unknown_and_absent_fields`** pinned `sync_protocol_version: 1` as a literal, so bumping the protocol to v2 made it fail for a reason that has nothing to do with what it tests. It is about unknown FIELDS; the versions now come from `CLIENT_PROTOCOL_VERSION`, like every other test in that file already did. The bigger fix is the habit. `ci-requirements.md` has documented since 2026-08-18 that the operator authorised running fmt/clippy/test against the CI image locally, and I had not been doing it. All three now pass here — 116 tests, clippy clean, fmt clean — and every Rust failure in this milestone so far would have been caught by them in under a minute instead of by CI, several commits downstream. Noted in ci-requirements so the next session doesn't relearn it: a removal is exactly the change that looks too safe to check.	2026-08-22 14:51:38 -04:00
bvandeusen	c46a4a7709	A checklist is something a note has, not something a note is ... `kind` was never a type. A plain TEXT column with no enum and no CHECK behind it, compared against a hardcoded ("text", "list") tuple in six places; `note_items` was always an ordinary child table keyed by note_id; serialization already emitted `items` whatever the kind; and the Android editor already toggled between the two losslessly, saying so in a comment. The storage has modelled "a body plus optional checkable items" the whole time. This deletes the gates that forbade it. Every surface: the create/PATCH gates, the ?kind= filter and its saved-filter facet, the three import/export branches, the column (alembic 0025); the core's `kind` field, its SQLite column (user_version 6), the sync wire, push and pull; the FFI records and `NoteEdit::Kind`; and on Android `NoteKind.kt`, `DraftKind`, the compose sheet's Note/List switch, and the branches in the card, the editor and the chrome. The editor's note⇄list toggle becomes "Add a checklist" — on both the web and Android. It is not a conversion any more: nothing moves, nothing is swapped, the body stays exactly where it is and the note gains somewhere to put items. The card renders both, in order. Two things that fell out of the merge rather than being aimed at: - The Keep importer was DISCARDING `textContent` whenever a note also had `listContent`, because the target could only hold one. Both survive now, and the test says so. - Markdown export wrote the body OR the checklist. It writes both. Protocol goes to v2, floor included: dropping a field a v1 client sends and expects back is breaking. `title` leaves in step 3 and lands in the same generation, so it needs no further bump. This is the change that will make the 0.1.227 build on the operator's phone refuse to sync — the in-app updater is independent of the handshake and remains the recovery path. The V1 SQLite schema deliberately KEEPS the kind column. V1 is the historical schema and every later block alters it, so removing it there would make a fresh database run V1 without the column and then v6's DROP COLUMN against a column that never existed — "no such column: kind" on every new install.	2026-08-22 12:53:53 -04:00
bvandeusen	81695fa0c8	android: update the app from the server it syncs with (2727, M12 step 7) ... 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.	2026-08-21 08:44:08 -04:00
bvandeusen	cae9888eb9	android: build the release APK with a debug-profile .so, for now ... `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.	2026-08-20 19:16:03 -04:00
bvandeusen	d0a9c73bf9	android: sign the release build, and give it a version that rises ... 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.	2026-08-20 19:03:57 -04:00
bvandeusen	f38864088b	core: a completed recurring reminder advances instead of ending ... `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.	2026-08-19 21:22:22 -04:00
bvandeusen	8f13dc2e2c	android: restore the dismiss I deleted, and teach the checker to see it ... `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.	2026-08-19 20:13:43 -04:00
bvandeusen	785ebdba59	android: reminders that actually reach you (M12 step 6) ... 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.	2026-08-19 20:06:05 -04:00
bvandeusen	39170b715c	android: leaving the composer keeps the note, and the board loses its dead space ... 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.	2026-08-19 19:39:40 -04:00
bvandeusen	5680f046e3	android: name all four permissions WorkManager adds, not one ... 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.	2026-08-19 19:11:19 -04:00
bvandeusen	452c66c8ef	android: sync without being asked (M12 step 6) ... 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.	2026-08-19 19:04:45 -04:00
bvandeusen	64542ed6cb	android: pull the board down to sync (M12 step 6) ... 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.	2026-08-19 16:36:56 -04:00
bvandeusen	65d8f5f9c6	android: the import ktlint and detekt cannot see ... `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.	2026-08-19 15:51:12 -04:00
bvandeusenandClaude Opus 5	750d11d32e	android: connect a server from the phone (M12 step 6) ... 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>	2026-08-19 15:41:02 -04:00
bvandeusenandClaude Opus 5	cf0ce382a0	android: the note editor (M12 step 6) ... 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>	2026-08-19 11:18:24 -04:00
bvandeusenandClaude Opus 5	64e016f32d	android: phone-shaped chrome and the real note card (M12 step 6) ... 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>	2026-08-19 09:23:00 -04:00
bvandeusenandClaude Opus 5	c8af808432	android: package only the ABIs we actually build for ... 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>	2026-08-18 16:24:37 -04:00
bvandeusenandClaude Opus 5	5eab2dd0b3	android: the error enum has to be flat, or the bindings don't compile ... 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>	2026-08-18 16:15:46 -04:00
bvandeusenandClaude Opus 5	dee71dffb3	android: teach the linters this codebase's conventions, and fix two real nits ... 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>	2026-08-18 16:04:40 -04:00
bvandeusenandClaude Opus 5	5d0de7a682	android: the binding generator gets its own crate, free of the app's deps ... 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>	2026-08-18 15:54:10 -04:00
bvandeusenandClaude Opus 5	3d3df1beb0	android: register generated sources through the Variant API ... 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>	2026-08-18 15:43:57 -04:00