276 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5	b7e0e5dbba	ffi: two items: lines left at the indent of the field above them ... `cargo fmt --check`. Deleting `color:` from these two NoteDraft literals left the line after it one level too deep — the sort of thing a formatter exists to catch and an eye does not. #3041 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 14:23:10 -04:00
bvandeusenandClaude Opus 5	e14d9d340a	core: the v9 test pinned v8, and a blank line ktlint counted ... Two CI failures from the colour removal, both mine. `a_fresh_database_reaches_v8` asserted the version the migration no longer stops at. Renamed to say what it actually guards — the LATEST version — so the next migration updates a number instead of a name that has quietly become wrong. While there, two tests the migration deserved and did not have. One asks SQLite whether `notes.color` is gone rather than reading a row back, because a SELECT that omits the column passes either way; it also asserts `labels.color` is still there, since getting that wrong would take every tag's colour with it. The other seeds three saved views and checks the sweep: one loses its colour key and keeps its query, one without the key is untouched, and one holding text that is not JSON at all comes out unchanged rather than NULL. Writing that third case is what found a real bug in the migration. The guard was `json_valid(params) AND json_extract(params, '$.color') IS NOT NULL`, which is the obvious way to write it and is a trap: SQLite does not promise to short-circuit AND, so `json_extract` can be evaluated against the very rows `json_valid` was there to exclude — and on malformed input it does not return NULL, it RAISES, which would have aborted the whole migration over one corrupt blob. It is a LIKE now, which is total over any text. The ktlint failure is a doubled blank line where `EditorAction.SetColor`'s branch used to be. #3041 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 14:15:33 -04:00
bvandeusenandClaude Opus 5	fa89da1fab	notes: color leaves the model, the wire and all three surfaces ... Step 3 of M315, and the destructive half. Steps 1 and 2 stopped every read of this field: a card is one neutral surface per theme, and the only coloured thing on a board is a tag. What was left was a column written by a picker and read by nothing. Rule 22 — the old path comes out completely. No flag, no fallback, no "override if set". Server: the column, the `?color=` facet, the create/update/serialise paths, the sync assignment, the front-matter line, and Keep's colour map. Alembic 0029 drops it and sweeps `"color"` out of stored saved-filter params — a view that silently filtered on a field the app no longer has would return nothing and never say why. That sweep is Python, not `params::jsonb - 'color'`, because Postgres has no try-cast and one malformed blob would abort a migration that is running over somebody's saved views. `NOTE_COLORS` moves from `models/note.py` to `colors.py`. A palette defined on the model that lost one is an invitation to put the column back; labels still name a colour, so the vocabulary belongs where the normalizer already is. Core: the field, the facet, the `NoteCreateInput`, and every read and write in store/push/pull. Local schema v9 drops the column and does the same saved-filter sweep, guarded on `json_valid` so a corrupt blob loses a key rather than becoming NULL. The uniffi layer drops `NoteEdit::Color` and `NoteDraft.color` with it. Web: `ColorPicker.vue`, the per-card swatch popover and its stylesheet rule, the FilterBar colour row, the facet in the query round-trip, and the colour half of the editor's baseline-and-save. Android: the `ColorSheet`, the `Picker.COLOR` case, the toolbar's swatch dot, `EditorAction.SetColor`. ## The protocol: v4, and the floor deliberately stays at 3 Checked against `compat.rs` and the push handler rather than trusting the `#[serde(default)]` annotation, because the v2 precedent points the other way: v2 dropped `kind` and `title` and DID raise both floors, on the rule that dropping a field a client sends and expects back is breaking. `color` fails the second half of that test. A v3 client reading a v4 note gets `"default"` from its own serde default and draws the colour it derives locally — the board it drew yesterday. A v3 client pushing `color` has the key ignored, since `_assign_note_fields` reads its payload key by key and never validates the shape. Neither direction errors and neither shows anything wrong. `title` was the note's NAME; this is a field that no longer renders. So `SYNC_PROTOCOL_VERSION` and `CLIENT_PROTOCOL_VERSION` go to 4, and both floors stay at 3. `docs/sync.md` carries the reasoning and the per-version history, and its push example is brought back in line — it still listed `title`, `kind` and `items`, all gone before this. Import stays tolerant: a pre-M315 export or a Keep takeout carrying `color:` imports fine, the key simply read past. Old exports must still import. #3041 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 14:07:03 -04:00
bvandeusenandClaude Opus 5	13a88179b8	tags: one ink, chip and inline, and the chip edge solved for 3:1 ... Step 1 left one card surface per theme, so the tag ink is no longer choosing a value that has to clear twenty backgrounds. Re-measured against the one it actually lands on, the two tables collapse into one. `-800` in light, `-300` in dark, for a `#tag` in the prose AND for a chip's text. Dark needed no decision at all — the two tables already held the same value for all ten hues, which is most of the argument on its own. Light collapses onto the INLINE column deliberately: since M311 a tag whose text is in the body is drawn where it was typed and not repeated as a chip, so inline is the common case and this leaves what is seen most exactly as it was. The chip is strictly better for the move: inline, on the card as a chip, on its own fill light `-800` 7.09 - 15.13 6.37 - 12.01 (was 4.52 - 8.23) dark `-300` 9.45 - 14.23 8.23 - 11.88 (unchanged) The chip edge goes 0.60 -> 0.65, and this is the first time that number could be solved rather than judged. 0.60 was picked against a chip sitting on a card of its own colour, a case that no longer exists; against a known fill the smallest alpha clearing the 3:1 of WCAG 1.4.11 for all ten hues is arithmetic. 0.60 gives 2.75-3.82 and misses for six of them, 0.65 gives 3.03-4.36 and misses for none. Dark runs 4.52-5.76. That edge is doing more work than it looks: a chip's fill measures 1.02-1.26 against the card in light and 1.02-1.73 in dark, and dark red at 1.02 is invisible. The ring is the pill; the fill only tints it. `LABEL_CHIP_CLASSES` becomes `LABEL_CHIP_SHELL` — fill and edge, no ink — and `labelChipClasses(label)` composes shell and ink in one place. The board and the editor each had their own copy of that composition, with a comment on one of them asking the other to stay in step. Now it is one call. Fixed on the way past: the web drew `default`'s chip ring at `black/10` (1.36 against its own fill) where Compose derived it from the ink (3.21) — the same chip, visibly different pills. Both are the ink at 65% now. `chipForeground` stays, narrowed to what it always actually was: the REMINDER pill's ink, transcribed from NoteCard.vue's literal red-700 / neutral-600. It is not a tag and must not move with one. Also gone: `NOTE_NODE_FILL`, a per-hue table of solid hexes for graph nodes with no consumer anywhere in the repo. Step 2 of M315. #3149 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 13:13:43 -04:00
bvandeusenandClaude Opus 5	b91091caca	cards: one neutral surface, and the generated fill deleted with it ... A card's fill stops being a function of the note. One neutral per theme on all three surfaces — white in light, neutral-900 in dark, which is what the palette's `default` always was and what both editors already used, so this is a collapse onto a surface everything already had rather than a colour anybody has to like. Measured, against "not the same color as their background but close to it": card vs board 1.04 light / 1.10 dark, edge vs card 1.98 / 1.73, body text 17.93 / 17.17, muted 10.37 / 14.23. The fill is deliberately the weakest number on the card — the edge and the shadow separate it from the board, so a fill that separated on its own would make it a panel. Deleted, since the card was their only consumer: `derivedFill` / `hslHex` and the level tables in colors.ts, `derivedFillArgb` / `hslToArgb` in DerivedTint.kt, `NOTE_CARD_CLASSES_STRONG`, `chosenNoteColor`, `noteCardClasses`, `noteTintVars`, the `.note-tint` rule in style.css, `chosenBackground` / `tintable` / `noteTintFor` / `noteCardColor` / `noteIsStrong` / `firstLabelColor` in NoteTint.kt, and `resolvedNoteColor` / `noteColorIsChosen`. `tintHash` and `derivedTint` STAY, against the plan: a label with no colour of its own still derives one from its name, and that path was never the one that failed. The mirrored pair and its fixture survive intact. The editor follows the card, and its Done button takes the brand — the board's compose FAB is the app's existing statement of "affirmative action here", where Material's default secondaryContainer is a baseline colour this theme never sets. The colour picker is left in place, doing nothing, for exactly one step: removing it here would leave `note.color` written by nothing and read by nothing, which is a worse intermediate than a control that visibly does nothing. #3041 takes the field and the picker together. Step 1 of M315. #3148 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 10:55:51 -04:00
bvandeusenandClaude Opus 5	f50204a98b	editor: detekt counts returns, so the promotion guards collapse into one ... `promotingTasks` had four returns against ReturnCount's limit of two — three of them the same `return this`. Collapsed into a null-or-task guard and a `changed` flag, which says the contract more plainly anyway: the list comes back untouched unless something was actually promoted. Mirrored in blocks.ts even though nothing lints it there. The two files are kept line-by-line alike on purpose, and letting them drift on shape is how the next person stops trusting that reading one tells you the other. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 12:59:15 -04:00
bvandeusenandClaude Opus 5	1a49ae7ea9	editor: a - [ ] typed by hand becomes a real item when you leave the line ... `splitBlocks` runs once, when the editor opens. After that the blocks ARE the state and nothing reads the body again — every edit travels the other way, through `joinBlocks`. So a marker typed by hand stayed literal text on screen until the note was closed and reopened, even though it was already a real item in storage and the card was already drawing a checkbox for it. The editor was the only place that disagreed with itself. (#3024) On BLUR, and only the block being left. There is no good moment to convert while someone is typing: re-splitting on a keystroke moves the caret out of the word being written, and converting the instant `- [ ]` is complete does it before the item has any text. Blur is the one moment the person has demonstrably finished with the block. `promotingTasks` / `promoteTasks` return the SAME list when there was nothing to promote, and both call sites compare by identity. Without that, every blur would re-key every field below it — including the blur that fires on first composition, before a field has ever held focus. Both surfaces in one commit, deliberately: blocks.ts is a line-by-line mirror of EditorBlock.kt, and the reason that mirror is worth keeping is that the two editors behave identically. Fixing one would spend its whole value. Non-canonical markers (`- [X]`, an odd bullet) come back canonical — the only case where this changes the body rather than just how it is drawn, and exactly what reopening the note already did. No unit test: `splitBlocks` reaches the core over uniffi for the grammar, so it needs the native library and cannot run in the JVM lane. No existing Android test touches the core for the same reason. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 12:50:43 -04:00
bvandeusenandClaude Opus 5	e7af7a4b77	board: the FAB and the undo snackbar rode behind the keyboard ... 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>	2026-08-27 11:55:23 -04:00
bvandeusenandClaude Opus 5	396e91e609	board: ktlint on the long-press menu — a named modifier, three dead imports ... 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>	2026-08-27 07:49:57 -04:00
bvandeusenandClaude Opus 5	3f0eef145b	board: a long press on a card does what the editor's overflow does ... 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>	2026-08-27 07:40:29 -04:00
bvandeusenandClaude Opus 5	4f351c10ca	core: rustfmt wraps the chain in the tag-span grammar test ... `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>	2026-08-26 22:23:46 -04:00
bvandeusenandClaude Opus 5	d9e5753dc2	board: a tag in the prose is coloured where it sits, not printed twice ... A tagged note was showing its tag twice — once where it was typed, once as a chip — and the duplicate was the loud copy. Now the chip row carries only what the body cannot say (a tag lifted off its own line, a label from the picker), and a `#tag` left mid-sentence is tinted in place. Which characters are a tag is asked of the CORE, the way the card already asks it which lines are checklist items: `extract_tag_spans` keeps the spans `extract_tags` throws away, and `body_tags` hands them to Kotlin. Offsets are UTF-16 code units, because `AnnotatedString` and JS both index that way and a char index lands mid-token the first time somebody writes an emoji. The web keeps its own matcher in markdown.ts, mirroring `line_tags` case for case. The inline ink is its own table, one Tailwind step deeper than the chip's. A chip brings its own -100 fill and reads against that alone; inline text sits on whatever the card is, including a gray-tagged card at neutral-200 — where the chip's -700 measured 3.98 (green), 4.11 (orange) and 4.34 (teal), under the 4.5 body text needs. At -800/-300 every hue lands 5.63-12.01 light and 7.20-10.84 dark across every palette and generated fill. Chips now carry the `#` on every surface. The via_tag branch that used to decide it is gone from the card, and Android's row said no hash at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 22:20:17 -04:00
bvandeusenandClaude Opus 5	8c22425e91	M311 step 3 — the core lifts too, so a note never lifts twice ... 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>	2026-08-26 20:01:32 -04:00
bvandeusenandClaude Opus 5	9810a75564	M311 step 2 — the migration that lifts the notes already written ... 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>	2026-08-26 19:54:26 -04:00
bvandeusenandClaude Opus 5	606e345580	Fix the rename that renamed itself ... `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>	2026-08-26 19:48:50 -04:00
bvandeusenandClaude Opus 5	ad48d30c68	M311 step 1 — lift a tag that is standing on its own ... 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>	2026-08-26 19:44:43 -04:00
bvandeusenandClaude Opus 5	23fd2da91e	The tag goes at the top of the card, where it gets looked at ... Label chips sat under the body, the checklist, the attachments and the link previews. On a tall note that puts the one thing saying what a note IS below the fold of a glance — and a board is scanned, not read. "Which of these is about the thing I am looking for" should be the first thing the eye lands on. Above the body rather than beside it: the body's first line is the note's NAME (M13 steps 3 and 4), and a chip floated next to it would compete with the thing that identifies the note. A row of its own costs one line, and only on notes that carry tags. Both surfaces, same order. Does not depend on tag lifting, which is a much larger change — see the task. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 17:17:32 -04:00
bvandeusenandClaude Opus 5	3d490bb6f3	HSL lightness is not luminance — the dark floor was too low ... The unit test I added with the generated fills failed on its first run, on exactly the claim it was written to check, so it earned its keep immediately. The floor was 0.090 — `neutral-900`'s own HSL lightness — reasoning that a ramp starting at the card surface and climbing could not end up below it. That confuses HSL lightness with luminance. At one fixed lightness the eye sees very different brightnesses by hue, because green carries 71% of the luminance formula and blue only 7%: at L=0.090 a yellow measures 0.0118 and a blue 0.0061. Every blue-ish untagged note was 1.41x DARKER than the card it was supposed to match, which on the board reads as a hole rather than as variety — the opposite of what the whole change is for. Solved rather than nudged: 0.113 is the lowest floor at which EVERY hue clears the card surface. The range now measures 1.11-1.71 against the board against the old 1.06-1.54, so the floor is back where the shipped ramp had it and the ceiling is higher. Body text 7.8 against the 4.5 it needs, meta 4.6 against 3.0. 338 distinct dark fills. Two things about the test are worth keeping. It asserts on LUMINANCE rather than on the lightness that was put in — a test of the input would have agreed with the bug and passed. And it now sweeps 40,000 ids rather than 500. The worst case is a HUE, not an id, and 500 ids reach only 459 of the 2160 hue/level combinations — it caught this one by luck. 40,000 covers all 2160. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 17:17:32 -04:00
bvandeusenandClaude Opus 5	86f1e4a08f	detekt: sector indices as a table, not a when ... 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>	2026-08-26 17:08:20 -04:00
bvandeusenandClaude Opus 5	c255b170d4	ktlint: a stray blank line from the append ... Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 17:01:40 -04:00
bvandeusenandClaude Opus 5	1d3cc7bcd4	Nine tints that looked like three — generate the fill instead ... Measured, the nine dark subdued fills were separated from each other by at most a 1.03 contrast ratio. That is not "subtle", it is identical, and it is why a board of them reads as one card repeated: "I only see 3 colors ... it looks like a monolithic wall." Two causes, and the second one is mine. NINE IS TOO FEW. The palette exists to say WHICH TAG. An untagged note's fill says nothing at all — it only has to keep the board from repeating. Those are different jobs and tying them together capped the second at nine values for a board that will hold hundreds. ONE AXIS IS TOO FEW. The subdued ramp varied hue while pinning every fill to the same lightness — deliberately, so each would read as a card against the board. But the eye separates by lightness first, so nine hues at one lightness are one card nine times. Hue alone was never going to carry it at that darkness. So an untagged note's fill is now generated from its id rather than looked up: hue anywhere on the circle, one of six lightness levels, saturation fixed. 324 distinct fills in dark and 193 in light, against nine. Separation between fills goes from a 1.03 ceiling to 1.42. Varying lightness is only SAFE because the card has its own grey edge now. While the fill was the card's only boundary it could not afford to drift toward the board; the edge bought that freedom, one commit before it was needed. Saturation is the one dial the hash never touches — variety comes from hue and lightness, loudness would come from saturation. Dark starts a hair under `neutral-900` and climbs, so no note is ever darker than a plain card. Light runs from white down past the board. Body text measures 8.7 at worst against the 4.5 it needs; the meta row 5.1 against 3.0. DOUBLE, NOT FLOAT, on the Kotlin side. JavaScript has one number type and it is binary64; a Kotlin Float is binary32, so the two would round differently near a channel boundary and a note would be one byte off between the phone and the browser. Nobody would ever file that — they would see two colours that are "sort of the same" and never work out why. The web half cannot be executed here at all (no node on this machine), so the Kotlin fixture test is the only place the two implementations are ever compared. It now pins eight generated values as well as the hash, plus the properties that actually matter: that lightness varies, that nothing sinks below the card surface, and that body text stays clear of AA. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 16:55:50 -04:00
bvandeusenandClaude Opus 5	ae2053d2ed	Give the cards an edge again — one grey, not ten hues ... The border was never the problem; a border that carried COLOUR was. It said exactly what the fill already said, at 1.56-2.09 against that fill where the fill managed 1.03-1.05 against the board — the loudest element on every card was redundant with the quietest. A line that varies by colour is content and competes with the fill. A line that never varies is structure and does not. So the edge comes back, and it comes back as a constant in NoteCard rather than a column in the palette. Uniformity is the feature, and putting it where the palette cannot reach it is how that stays true. light #b8b8b8 1.57-1.98 against all twenty card fills dark #404040 1.58-1.73 Matched, not eyeballed: both land at ~1.6-1.7 against the card they edge, so the edge reads with the same authority in either theme. Dark is `neutral-700` — what the `default` card's border always was, one entry's value promoted to the rule for all of them. Light sits between `neutral-300` and `neutral-400` because neither lands in range: 300 fades to 1.18 on a gray-tagged card, 400 jumps to 2.52 and reads as a wireframe. Rejected on measurement: a translucent black/white edge, which is the tidier way to write it and self-adjusts per card. A border composites over the card's own fill, so `border-white/20` comes out #56396d on a purple card and #a3c9c1 on a teal one. Hue-coded edges are the thing being removed. The shadow steps back to what it was for — depth, not the boundary. Web returns to `shadow-sm`; Android's 2dp drops to 1dp, matching it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 15:00:22 -04:00
bvandeusenandClaude Opus 5	47f108c9c8	The border was the thing making every note look the same ... A note card carried a 1px tint border. Measured against its own fill, that line was a 1.56-2.09 contrast in dark mode while the fill managed only 1.03-1.05 against the board — so the loudest thing on every card was an identical line in an identical place, and a field of them read as a grid of outlined rectangles however different the colours inside were. Removed from the note card on both surfaces. `border` survives for panels, banners, the update card and the pickers: those are single elements, not a field of them. What replaces it differs by theme, because elevation does. Light leans on a shadow. An untagged card is `bg-red-50` on a `neutral-50` board — a 1.04 contrast that can only read as a card by sitting above one. The web goes `shadow-sm` -> `shadow`; Android had no shadow at all and gets 2dp. Dark cannot use one, black on near-black. So the subdued fills moved onto the card surface instead: `{hue}-950` composited at 0.18 over #171717 and baked, rather than the same hue at 0.25 over the near-black board. An untagged card now sits where the plain white card always sat (1.11-1.14 against the board, against `bg-neutral-900`'s 1.10) while carrying LESS hue than before — chroma 7-17 where the old ramp had 10-23. Subtler and more visible at once, which is only a contradiction if subtlety has to come from lightness. Here it comes from chroma, and lightness is left to say "this is a card". Which also reframes the two weights: in dark they now sit within a hair of each other (red: 1.11 vs 1.12) and differ threefold in colour (chroma 10 vs 41). The chosen ramp is untouched — the operator signed those colours off, and a ramp somebody likes is not something to redo while fixing something else. Light was already built this way: `-50` and `-100` are both white plus a different amount of hue. Body text still measures 14.3-16.4 against the 4.5 it needs, meta 6.9-7.1 against 3.0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 14:21:42 -04:00
bvandeusenandClaude Opus 5	fe18aaa956	The contrast pass, and the invisible chip it found ... Step 4 of milestone 309. All 40 combinations measured rather than eyeballed — 10 hues x 2 themes x 2 weights, dark ones composited over the board the way Compose and CSS both do, against the text actually drawn on a card (neutral-700/300 body, neutral-500/400 meta). Body text ranges 8.23:1 to 13.01:1 against a 4.5:1 requirement; meta text 4.33 to 7.11 against 3.0. Every combination passes AA with room to spare, so the two ramps step 3 introduced need no adjustment. That is the boring half. THE PASS FOUND A REAL REGRESSION. A tagged note takes its first tag's colour and is drawn at that hue's `-100` — which is exactly what the chip uses as its fill. Measured contrast between the chip and the card it had itself coloured: 1.00 in light mode. Perfectly invisible. Dark was 1.04-1.07, invisible in practice. On every tagged note the tag name had stopped reading as a chip and become loose text, and nothing about step 3 looked wrong while writing it. Fixed with an EDGE rather than a different fill. A fill can collide with any card colour and chasing that would need the chip to know what it is sitting on; a border in the chip's own foreground reads against any background and needs no plumbing. Alpha is 0.60, measured: 2.32:1 at worst, where the 0.30 I first wrote gave 1.49 and was no edge at all. It does not reach WCAG 1.4.11's 3:1, which needs 0.80 and draws a hard outline instead of a hairline. 1.4.11 governs boundaries carrying REQUIRED information, and a chip's information is its text — passing AA at 8:1 or better on every card here. The number and the reasoning are both in the source so the judgment can be overruled rather than rediscovered. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 13:37:51 -04:00
bvandeusenandClaude Opus 5	20e9d535de	android: two more ktlint rules, both in the code I just added ... `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>	2026-08-26 13:25:28 -04:00
bvandeusenandClaude Opus 5	988e1d3f00	A note's colour is its first tag's colour, at a heavier weight ... Four #todo notes on the operator's board in four different colours, because the tint was derived per-note-id and ignored tags entirely. Now a tagged note wears its first tag's colour, so notes that share a tag share a look. TWO WEIGHTS, NOT ONE RAMP. The operator, seeing step 1: "the tints look the same as the chosen colors". They did — there was only one ramp. `strong` is not a second decision, it IS whether the colour was chosen: a tag (or, until step 5, the picker) means somebody said what this note is, while a derived tint only means the board should not be a wall of white. The two weights move in OPPOSITE directions per theme, because that is where each has headroom. The operator asked whether the tint could go lighter instead of the tagged end going darker; in dark mode that is the better half of the answer, so the derived end drops to a quarter opacity — closer to the board, which gives the light body text MORE contrast rather than less. Light mode has nowhere to go below `-50` without being white again, so there the gap opens by deepening the chosen end to `-100`. No hex was transcribed for any of it. `-100` is already in NoteTint.kt as every hue's `lightChipBackground`, and the dark weights are the existing `-950` fill re-alphaed, so the only two numbers that have to agree by hand are the alphas. Copying ten more Tailwind values from memory is exactly how this mirror would have drifted. `default` is marked not tintable — it is the ABSENCE of a colour, there is no emphatic version of it, and re-alphaing its opaque neutral fill would have made every draft card translucent. Borders untouched: the fill is the signal, moving both muddies the edge. Resolution order is explicit pick, then first tag, then the id hash. First tag because it is the one you control by typing; manual labels count the same as #tags because nobody can tell which kind they made by looking. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 13:15:47 -04:00
bvandeusenandClaude Opus 5	6fbee27f9c	A tag with no colour of its own derives one from its name ... Every #tag ever typed is `default`. `notes/tags.py` mints one as `Label(owner_id=…, name=name)` with no colour, so it takes the column default — which means tag-driven note colour, built on top, would have left the board exactly as grey as it was. Four #todo notes in the operator's screenshot, four different colours, because the tint is per-note-id and ignores tags entirely. DERIVED RATHER THAN PERSISTED AT MINT TIME, reversing the plan in 2965. That plan wanted a hashed colour written wherever a label is born, and named the risk in its own body: `find_or_create_label` is "easy to miss, and it is the common one", because most tags are born from typing `#grocery`, not from a management screen. Deriving has no mint points to miss, needs no backfill for the tags that already exist, and reuses the hash and the fixture the notes already have. The cost is that renaming a tag recolours it. That is defensible — the name IS the tag — and an explicitly picked colour is still stored and still wins, so tag colours stay editable exactly as asked. Lowercased before hashing: tags dedupe case-insensitively, so #Todo and #todo are one tag and must not be two colours. All five places a label's colour is drawn now resolve the same way — the card chip, the editor chip, the drawer's tag list, and the management modal's dot and swatch ring. The modal's ring follows the resolved colour rather than the stored one, so opening the picker highlights what you can already see instead of nothing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 12:57:59 -04:00
bvandeusenandClaude Opus 5	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	96a6f6e691	web: the editor draws the checklist too ... 2992's other half. The browser was the last surface still showing `- [ ] ` as markup: cards rendered and ticked checkboxes, the editor did not. Same shape as Android, deliberately. notes/blocks.ts mirrors EditorBlock.kt — splitBlocks, joinBlocks, afterEnter, withoutIndex, plusTask — because the two editors should behave alike and the cheapest way to keep them that way is for the code to read alike. `body` becomes a computed over the blocks, so every save, baseline check and draft still reads the one markdown string they always did. markdown.ts now exports parseTaskLine and renderTaskLine, and parseMarkdown uses the former. The read view and the editor's block split had been matching the same grammar through two separate copies of one regex; now they agree by construction. Two places the web can do better than Compose, and does: * Backspace at the start of an empty item removes it. A browser sends a real keydown for Backspace; an Android soft keyboard sends an IME delete that never surfaces as one, which is why that surface only has Enter-on-empty. * Prose fields size to their text — rows="1" plus a scrollHeight fit, which beats guessing a row count that is wrong the moment a line wraps. KNOWN, and the same on both surfaces: typing `- [ ] ` by hand into a prose block leaves it prose until the note is reopened. Blocks are split when the editor loads, not re-derived per keystroke — re-splitting mid-type would move the caret. The toolbar button is the intended path. Converting on blur would fix it and is worth doing to BOTH editors at once rather than letting them drift.	2026-08-26 07:53:13 -04:00
bvandeusen	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	1a66d9c3a8	tests: pin the export against writing every checklist twice ... 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.	2026-08-24 08:26:50 -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	3cab054684	web: task lines render as checkboxes where they sit in the note ... M304 step 5. The server already returns a derived `items` array, so the web kept working across the last two commits — but it was rendering every list TWICE: once as literal `- [ ] milk` bullets inside the body, and again as the separate NoteChecklist block underneath. This is the commit that makes the body the only place a checklist appears. markdown.ts gains a `task` block, matched BEFORE the plain bullet — which would otherwise swallow the marker and leave the brackets showing, the same ordering reason `code` is matched before emphasis in INLINE_RE. Each item carries its ordinal across the WHOLE document, because that is what an item's id means everywhere else now; counting per block would have made the second list's checkboxes toggle the first list's items. The card's preview clamp is why that ordinal is safe there: it only ever drops lines from the end, so a visible item's index is the same whether or not the body was truncated. MarkdownText emits a toggle rather than reaching for the store. Ticking a box rewrites a line of someone's note, and a renderer used in several places should not be the thing deciding that is allowed — the card passes `toggleable` and wires it, a read-only render does not and the boxes are inert. Not wrapped in a <label> either: on a card the text is the note's own words and clicking it opens the note, so only the box toggles. In the editor, the toolbar button stops revealing a section and inserts `- [ ] ` at the caret. That makes it the one toolbar action needing no persisted note to hang anything off — ensureDraft is gone from it, and it works on an empty compose box the moment it opens. Enter on a task line continues the list, and on an EMPTY one clears the marker; without that second half a list would be impossible to get out of. Indent and bullet are carried over rather than normalised, because continuing someone's `*` list with a `-` is an edit they did not ask for. NoteChecklist.vue is deleted (rule 22). The store's item methods stay: they are the repository seam the REST routes and Tauri commands both implement, not the old path. CI cannot check any of this beyond types — there are no frontend tests, only vue-tsc. It wants a real browser pass.	2026-08-24 08:10:20 -04:00
bvandeusen	fe1f72ae1b	tests: the display-title tests still passed the argument that went away ... 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.	2026-08-24 08:06:11 -04:00