21 Commits

Include renames

Author	SHA1	Message	Date
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	3d490bb6f3	HSL lightness is not luminance — the dark floor was too low ... The unit test I added with the generated fills failed on its first run, on exactly the claim it was written to check, so it earned its keep immediately. The floor was 0.090 — `neutral-900`'s own HSL lightness — reasoning that a ramp starting at the card surface and climbing could not end up below it. That confuses HSL lightness with luminance. At one fixed lightness the eye sees very different brightnesses by hue, because green carries 71% of the luminance formula and blue only 7%: at L=0.090 a yellow measures 0.0118 and a blue 0.0061. Every blue-ish untagged note was 1.41x DARKER than the card it was supposed to match, which on the board reads as a hole rather than as variety — the opposite of what the whole change is for. Solved rather than nudged: 0.113 is the lowest floor at which EVERY hue clears the card surface. The range now measures 1.11-1.71 against the board against the old 1.06-1.54, so the floor is back where the shipped ramp had it and the ceiling is higher. Body text 7.8 against the 4.5 it needs, meta 4.6 against 3.0. 338 distinct dark fills. Two things about the test are worth keeping. It asserts on LUMINANCE rather than on the lightness that was put in — a test of the input would have agreed with the bug and passed. And it now sweeps 40,000 ids rather than 500. The worst case is a HUE, not an id, and 500 ids reach only 459 of the 2160 hue/level combinations — it caught this one by luck. 40,000 covers all 2160. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 17:17:32 -04:00
bvandeusenandClaude Opus 5	1d3cc7bcd4	Nine tints that looked like three — generate the fill instead ... Measured, the nine dark subdued fills were separated from each other by at most a 1.03 contrast ratio. That is not "subtle", it is identical, and it is why a board of them reads as one card repeated: "I only see 3 colors ... it looks like a monolithic wall." Two causes, and the second one is mine. NINE IS TOO FEW. The palette exists to say WHICH TAG. An untagged note's fill says nothing at all — it only has to keep the board from repeating. Those are different jobs and tying them together capped the second at nine values for a board that will hold hundreds. ONE AXIS IS TOO FEW. The subdued ramp varied hue while pinning every fill to the same lightness — deliberately, so each would read as a card against the board. But the eye separates by lightness first, so nine hues at one lightness are one card nine times. Hue alone was never going to carry it at that darkness. So an untagged note's fill is now generated from its id rather than looked up: hue anywhere on the circle, one of six lightness levels, saturation fixed. 324 distinct fills in dark and 193 in light, against nine. Separation between fills goes from a 1.03 ceiling to 1.42. Varying lightness is only SAFE because the card has its own grey edge now. While the fill was the card's only boundary it could not afford to drift toward the board; the edge bought that freedom, one commit before it was needed. Saturation is the one dial the hash never touches — variety comes from hue and lightness, loudness would come from saturation. Dark starts a hair under `neutral-900` and climbs, so no note is ever darker than a plain card. Light runs from white down past the board. Body text measures 8.7 at worst against the 4.5 it needs; the meta row 5.1 against 3.0. DOUBLE, NOT FLOAT, on the Kotlin side. JavaScript has one number type and it is binary64; a Kotlin Float is binary32, so the two would round differently near a channel boundary and a note would be one byte off between the phone and the browser. Nobody would ever file that — they would see two colours that are "sort of the same" and never work out why. The web half cannot be executed here at all (no node on this machine), so the Kotlin fixture test is the only place the two implementations are ever compared. It now pins eight generated values as well as the hash, plus the properties that actually matter: that lightness varies, that nothing sinks below the card surface, and that body text stays clear of AA. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 16:55:50 -04:00
bvandeusenandClaude Opus 5	ae2053d2ed	Give the cards an edge again — one grey, not ten hues ... The border was never the problem; a border that carried COLOUR was. It said exactly what the fill already said, at 1.56-2.09 against that fill where the fill managed 1.03-1.05 against the board — the loudest element on every card was redundant with the quietest. A line that varies by colour is content and competes with the fill. A line that never varies is structure and does not. So the edge comes back, and it comes back as a constant in NoteCard rather than a column in the palette. Uniformity is the feature, and putting it where the palette cannot reach it is how that stays true. light #b8b8b8 1.57-1.98 against all twenty card fills dark #404040 1.58-1.73 Matched, not eyeballed: both land at ~1.6-1.7 against the card they edge, so the edge reads with the same authority in either theme. Dark is `neutral-700` — what the `default` card's border always was, one entry's value promoted to the rule for all of them. Light sits between `neutral-300` and `neutral-400` because neither lands in range: 300 fades to 1.18 on a gray-tagged card, 400 jumps to 2.52 and reads as a wireframe. Rejected on measurement: a translucent black/white edge, which is the tidier way to write it and self-adjusts per card. A border composites over the card's own fill, so `border-white/20` comes out #56396d on a purple card and #a3c9c1 on a teal one. Hue-coded edges are the thing being removed. The shadow steps back to what it was for — depth, not the boundary. Web returns to `shadow-sm`; Android's 2dp drops to 1dp, matching it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 15:00:22 -04:00
bvandeusenandClaude Opus 5	47f108c9c8	The border was the thing making every note look the same ... A note card carried a 1px tint border. Measured against its own fill, that line was a 1.56-2.09 contrast in dark mode while the fill managed only 1.03-1.05 against the board — so the loudest thing on every card was an identical line in an identical place, and a field of them read as a grid of outlined rectangles however different the colours inside were. Removed from the note card on both surfaces. `border` survives for panels, banners, the update card and the pickers: those are single elements, not a field of them. What replaces it differs by theme, because elevation does. Light leans on a shadow. An untagged card is `bg-red-50` on a `neutral-50` board — a 1.04 contrast that can only read as a card by sitting above one. The web goes `shadow-sm` -> `shadow`; Android had no shadow at all and gets 2dp. Dark cannot use one, black on near-black. So the subdued fills moved onto the card surface instead: `{hue}-950` composited at 0.18 over #171717 and baked, rather than the same hue at 0.25 over the near-black board. An untagged card now sits where the plain white card always sat (1.11-1.14 against the board, against `bg-neutral-900`'s 1.10) while carrying LESS hue than before — chroma 7-17 where the old ramp had 10-23. Subtler and more visible at once, which is only a contradiction if subtlety has to come from lightness. Here it comes from chroma, and lightness is left to say "this is a card". Which also reframes the two weights: in dark they now sit within a hair of each other (red: 1.11 vs 1.12) and differ threefold in colour (chroma 10 vs 41). The chosen ramp is untouched — the operator signed those colours off, and a ramp somebody likes is not something to redo while fixing something else. Light was already built this way: `-50` and `-100` are both white plus a different amount of hue. Body text still measures 14.3-16.4 against the 4.5 it needs, meta 6.9-7.1 against 3.0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 14:21:42 -04:00
bvandeusenandClaude Opus 5	fe18aaa956	The contrast pass, and the invisible chip it found ... Step 4 of milestone 309. All 40 combinations measured rather than eyeballed — 10 hues x 2 themes x 2 weights, dark ones composited over the board the way Compose and CSS both do, against the text actually drawn on a card (neutral-700/300 body, neutral-500/400 meta). Body text ranges 8.23:1 to 13.01:1 against a 4.5:1 requirement; meta text 4.33 to 7.11 against 3.0. Every combination passes AA with room to spare, so the two ramps step 3 introduced need no adjustment. That is the boring half. THE PASS FOUND A REAL REGRESSION. A tagged note takes its first tag's colour and is drawn at that hue's `-100` — which is exactly what the chip uses as its fill. Measured contrast between the chip and the card it had itself coloured: 1.00 in light mode. Perfectly invisible. Dark was 1.04-1.07, invisible in practice. On every tagged note the tag name had stopped reading as a chip and become loose text, and nothing about step 3 looked wrong while writing it. Fixed with an EDGE rather than a different fill. A fill can collide with any card colour and chasing that would need the chip to know what it is sitting on; a border in the chip's own foreground reads against any background and needs no plumbing. Alpha is 0.60, measured: 2.32:1 at worst, where the 0.30 I first wrote gave 1.49 and was no edge at all. It does not reach WCAG 1.4.11's 3:1, which needs 0.80 and draws a hard outline instead of a hairline. 1.4.11 governs boundaries carrying REQUIRED information, and a chip's information is its text — passing AA at 8:1 or better on every card here. The number and the reasoning are both in the source so the judgment can be overruled rather than rediscovered. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 13:37:51 -04:00
bvandeusenandClaude Opus 5	988e1d3f00	A note's colour is its first tag's colour, at a heavier weight ... Four #todo notes on the operator's board in four different colours, because the tint was derived per-note-id and ignored tags entirely. Now a tagged note wears its first tag's colour, so notes that share a tag share a look. TWO WEIGHTS, NOT ONE RAMP. The operator, seeing step 1: "the tints look the same as the chosen colors". They did — there was only one ramp. `strong` is not a second decision, it IS whether the colour was chosen: a tag (or, until step 5, the picker) means somebody said what this note is, while a derived tint only means the board should not be a wall of white. The two weights move in OPPOSITE directions per theme, because that is where each has headroom. The operator asked whether the tint could go lighter instead of the tagged end going darker; in dark mode that is the better half of the answer, so the derived end drops to a quarter opacity — closer to the board, which gives the light body text MORE contrast rather than less. Light mode has nowhere to go below `-50` without being white again, so there the gap opens by deepening the chosen end to `-100`. No hex was transcribed for any of it. `-100` is already in NoteTint.kt as every hue's `lightChipBackground`, and the dark weights are the existing `-950` fill re-alphaed, so the only two numbers that have to agree by hand are the alphas. Copying ten more Tailwind values from memory is exactly how this mirror would have drifted. `default` is marked not tintable — it is the ABSENCE of a colour, there is no emphatic version of it, and re-alphaing its opaque neutral fill would have made every draft card translucent. Borders untouched: the fill is the signal, moving both muddies the edge. Resolution order is explicit pick, then first tag, then the id hash. First tag because it is the one you control by typing; manual labels count the same as #tags because nobody can tell which kind they made by looking. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 13:15:47 -04:00
bvandeusenandClaude Opus 5	6fbee27f9c	A tag with no colour of its own derives one from its name ... Every #tag ever typed is `default`. `notes/tags.py` mints one as `Label(owner_id=…, name=name)` with no colour, so it takes the column default — which means tag-driven note colour, built on top, would have left the board exactly as grey as it was. Four #todo notes in the operator's screenshot, four different colours, because the tint is per-note-id and ignores tags entirely. DERIVED RATHER THAN PERSISTED AT MINT TIME, reversing the plan in 2965. That plan wanted a hashed colour written wherever a label is born, and named the risk in its own body: `find_or_create_label` is "easy to miss, and it is the common one", because most tags are born from typing `#grocery`, not from a management screen. Deriving has no mint points to miss, needs no backfill for the tags that already exist, and reuses the hash and the fixture the notes already have. The cost is that renaming a tag recolours it. That is defensible — the name IS the tag — and an explicitly picked colour is still stored and still wins, so tag colours stay editable exactly as asked. Lowercased before hashing: tags dedupe case-insensitively, so #Todo and #todo are one tag and must not be two colours. All five places a label's colour is drawn now resolve the same way — the card chip, the editor chip, the drawer's tag list, and the management modal's dot and swatch ring. The modal's ring follows the resolved colour rather than the stored one, so opening the picker highlights what you can already see instead of nothing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 12:57:59 -04:00
bvandeusenandClaude Opus 5	6f173b166b	Every note carries a tint, derived from its id ... The board was a wall of white rectangles: `default` is the colour nobody picks, so it was the colour of every note except the two the operator had coloured by hand. Reported twice — 2026-08-23 as "a wall of broken up text", and again today as "all the existing notes are the same dull color". The ask was "random subdued colors", but random is the one thing it must not be. A tint rolled at render time would differ between the phone and the browser and change on every reload. FNV-1a over the note's id is deterministic, identical on every surface, needs no column and no migration, and a note keeps its colour for life — which is what "random" meant here. Two implementations, deliberately mirrored, same discipline as the checklist grammar. The Kotlin half lives in a Compose-free file so a host-JVM test can pin the fixture; the TypeScript half carries the same four ids and hashes as a comment because the frontend has no test runner at all — its whole CI lane is `vue-tsc --noEmit`. That asymmetry is worth naming rather than papering over. A draft has no id yet (DRAFT_ID is ""), so it stays white until it is saved. Hashing the empty string would give every draft one shared tint and then change it on save anyway — two surprises where one will do. An explicitly-picked colour still wins. The picker is on its way out (milestone 309 step 5) but it has not gone yet, and a hand-coloured note changing under the operator would read as data loss. First of five steps toward colour coming from tags. This one stands alone: no storage change, nothing removed, and the board stops being white today. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 12:26:01 -04:00
bvandeusen	96a6f6e691	web: the editor draws the checklist too ... 2992's other half. The browser was the last surface still showing `- [ ] ` as markup: cards rendered and ticked checkboxes, the editor did not. Same shape as Android, deliberately. notes/blocks.ts mirrors EditorBlock.kt — splitBlocks, joinBlocks, afterEnter, withoutIndex, plusTask — because the two editors should behave alike and the cheapest way to keep them that way is for the code to read alike. `body` becomes a computed over the blocks, so every save, baseline check and draft still reads the one markdown string they always did. markdown.ts now exports parseTaskLine and renderTaskLine, and parseMarkdown uses the former. The read view and the editor's block split had been matching the same grammar through two separate copies of one regex; now they agree by construction. Two places the web can do better than Compose, and does: * Backspace at the start of an empty item removes it. A browser sends a real keydown for Backspace; an Android soft keyboard sends an IME delete that never surfaces as one, which is why that surface only has Enter-on-empty. * Prose fields size to their text — rows="1" plus a scrollHeight fit, which beats guessing a row count that is wrong the moment a line wraps. KNOWN, and the same on both surfaces: typing `- [ ] ` by hand into a prose block leaves it prose until the note is reopened. Blocks are split when the editor loads, not re-derived per keystroke — re-splitting mid-type would move the caret. The toolbar button is the intended path. Converting on blur would fix it and is worth doing to BOTH editors at once rather than letting them drift.	2026-08-26 07:53:13 -04:00
bvandeusen	3cab054684	web: task lines render as checkboxes where they sit in the note ... M304 step 5. The server already returns a derived `items` array, so the web kept working across the last two commits — but it was rendering every list TWICE: once as literal `- [ ] milk` bullets inside the body, and again as the separate NoteChecklist block underneath. This is the commit that makes the body the only place a checklist appears. markdown.ts gains a `task` block, matched BEFORE the plain bullet — which would otherwise swallow the marker and leave the brackets showing, the same ordering reason `code` is matched before emphasis in INLINE_RE. Each item carries its ordinal across the WHOLE document, because that is what an item's id means everywhere else now; counting per block would have made the second list's checkboxes toggle the first list's items. The card's preview clamp is why that ordinal is safe there: it only ever drops lines from the end, so a visible item's index is the same whether or not the body was truncated. MarkdownText emits a toggle rather than reaching for the store. Ticking a box rewrites a line of someone's note, and a renderer used in several places should not be the thing deciding that is allowed — the card passes `toggleable` and wires it, a read-only render does not and the boxes are inert. Not wrapped in a <label> either: on a card the text is the note's own words and clicking it opens the note, so only the box toggles. In the editor, the toolbar button stops revealing a section and inserts `- [ ] ` at the caret. That makes it the one toolbar action needing no persisted note to hang anything off — ensureDraft is gone from it, and it works on an empty compose box the moment it opens. Enter on a task line continues the list, and on an EMPTY one clears the marker; without that second half a list would be impossible to get out of. Indent and bullet are carried over rather than normalised, because continuing someone's `*` list with a `-` is an edit they did not ask for. NoteChecklist.vue is deleted (rule 22). The store's item methods stay: they are the repository seam the REST routes and Tauri commands both implement, not the old path. CI cannot check any of this beyond types — there are no frontend tests, only vue-tsc. It wants a real browser pass.	2026-08-24 08:10:20 -04:00
bvandeusen	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	bc22f8e249	Remove [[wiki-links]], backlinks and the graph ... Operator, 2026-08-22 (note 2897): ThoughtSync is an intermediary surface. You write here because it's easy — a notebook in your pocket — and later you recall the thing and go finish it somewhere else. Recall is the product; organization is secondary. A linking system is organization, and it isn't what this is for. So: `[[wiki-links]]`, backlinks, the `[[` autocomplete, the note_links table, `/api/notes/link-search`, `/api/notes/<id>/backlinks`, the whole graph blueprint and GraphView. Rust core loses `extract_links`, `backlinks`, `link_search` and `create_titled`; the desktop loses the three Tauri commands that exposed them. This subsumes 982d24c rather than reverting it. That commit bound links to a note id so a rename would stop rewriting other notes' bodies — real infra, but infra for a feature that is now gone, and nothing it added survives. Alembic 0023 stays in the chain anyway: it shipped in an image and may already be applied, and deleting an applied revision strands a database's version pointer. 0024 drops the table and takes the column with it. The history stays honest about the fact that it existed for a day. Two things deliberately kept, because they were serving recall and only incidentally serving links: - `/api/notes/titles` and the titles store. The command palette lists them so you can jump to a note by name. `resolve()` — the name→note lookup that only linking needed — is gone. - `display_title`. Every note still has a name for search results and export filenames. What that name is FOR changed; that it exists did not. `notes/links.py` is now `notes/tags.py`, holding the #tag→label reconciliation it always also owned. A file called links.py with no links in it would have been exactly the drift this removal is meant to end. Also swept out on the way: `_escape_like`, whose only caller was link-search, and the `graph` icon. Nothing lost that a person typed — note_links was always derived, and the `[[text]]` is still sitting in every body it was written in.	2026-08-22 12:00:57 -04:00
bvandeusenandClaude Opus 5	e64d67e904	Expire trash after 30 days, and make the deadline something you can see ... Trash had no end. A note sat in /trash until someone emptied it by hand, and its attachment BYTES sat on disk the whole time — the pile-up the operator asked about. Nothing purged; there was no scheduler at all. Retention is server-owned: `trash_retention_days` (default 30, 0 = keep forever) in the settings registry, so it lands in admin Settings with no migration and takes effect without a restart. A background sweep started in before_serving does the work. Clients learn about a purge the way they learn about any deletion — as a tombstone on the delta feed. An auto-purge nobody can see coming is data loss on a timer, so the window is now visible: /api/config publishes it, notes carry `deleted_at`, Trash leads with the policy, and each card counts down. The countdown rounds DOWN — saying "1 day left" for a note with ten minutes on the clock is the one error here that actually costs someone a note. Three things this turned up on the way: - `DELETE /api/notes/<id>` hard-deleted the row, leaving no tombstone at all. A permanent delete in the web UI never reached a linked device, which would keep its copy forever and push it back on the next edit. It now purges through the same path as everything else. - The purge left `note_revisions` and `note_link_previews` behind. A revision holds the full body, so the text of a "permanently deleted" note was still sitting in the database. - `deleted_at` now SURVIVES a purge instead of being cleared. It's still true, and it means every query that says "not trashed" excludes tombstones for free — without it a content-less row reads as a perfectly normal active note and shows up on the board as a blank card. Desktop keeps its own clock only when there's nobody else to keep one: the sweep runs at startup on an UNLINKED device and refuses otherwise. A linked client that expired notes on its own schedule could destroy something the server was deliberately keeping, then push that delete upstream. Local policy must never outrank the server's — so it also adopts the server's window for the countdown rather than showing its offline default. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-26 16:20:13 -04:00
bvandeusenandClaude Opus 4.8	e1cf63e875	M9 S3 (frontend): consolidate local-date helpers into notes/datetime.ts ... The created-date range facets built local-day bounds by hand in two places (FilterBar's onTo/toInput, TimelineView's buildQuery) — parse a "YYYY-MM-DD", shift a day for the half-open upper bound, format back. - datetime.ts: parseLocalDate() / addLocalDays() (non-mutating) / formatLocalDay(). - TimelineView: drops its inline localDate() + the +1-day Date math. - FilterBar: drops its inline isoDay() + the setDate(±1) mutations. Behavior-preserving and deliberately NOT unifying output: Timeline still emits UTC (.toISOString()) bounds, FilterBar still emits naive-local "…T00:00:00" strings — only the shared primitives are extracted. (The naive-vs-UTC divergence is a separate backend-datetime-semantics question, flagged for later, not silently changed.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-23 21:40:13 -04:00
bvandeusenandClaude Opus 4.8	5c045aed63	M6 1902b: facet bar + saved views UI (frontend) ... The dead-simple facet bar over the board + saved views in the sidebar, completing task 1902. Filter state lives in the URL query, so a filtered board is a shareable lens and a saved view is just a link ("one space, many lenses"). - notes/facets.ts: facetsFromQuery / facetsToQuery / facetCount helpers. - FilterBar.vue (board only): a "Filters (N)" toggle expanding to text search + color swatches + label chips + has-reminder / has-attachment / Lists / Notes toggles + a created-date range; Clear + "Save view". Each control writes the URL query (router.replace). - notes store: load(view, label, facets) builds the query; NoteFacets type + activeFacets; import reload preserves active facets. - savedFilters store + sidebar "Views" section (each a query-link, delete on hover); loaded on mount. - BoardView derives facets from the query, reloads on facet change (ignores ?open=), and shows a "no notes match these filters" empty state. - Backend: saved-filter param whitelist keys on `label` (matches the repeatable ?label= query) so saved views keep their labels. New filter icon. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-23 08:45:56 -04:00
bvandeusenandClaude Opus 4.8	261d8fcac5	M6: lightweight markdown rendering on note cards ... Render a small Markdown subset in the read view — headings (#..###), bullet/ordered lists, blockquote, fenced code, and inline **bold** / *italic* / `code` — alongside the existing [[wiki-links]] (task 1905). Capture stays plain text; only the card render is formatted. Hand-rolled dependency-free parser (notes/markdown.ts) rendered as Vue vnodes (MarkdownText/MarkdownInline), never v-html, so there is no HTML-injection surface — matches the no-heavy-dep ethos. Headings require '# ' (space), so a #tag (no space) stays plain text and is never mistaken for a heading; the two coexist. Replaces LinkedText (links-only) on the card; LinkedText deleted. Pure frontend — no backend/DB/migration. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-22 14:44:03 -04:00
bvandeusenandClaude Opus 4.8	894dd4ac42	graph: interactive liveliness (drag/pan/zoom, unlinked toggle, label colors) ... Backend /api/graph now returns ALL non-trashed notes as nodes, each with its first label's color; edges unchanged. GraphView reworked: drag a node to reposition it (pins to cursor + reheats the sim), pan the background, wheel- zoom toward the cursor, a "Show unlinked notes" toggle (connected-only by default), a Reset view button, and nodes filled by label color. Click (a press without a drag) still opens the note; re-fetches on view open. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-20 22:40:28 -04:00
bvandeusenandClaude Opus 4.8	f321c2bf70	labels: per-label color ... Give labels a color (migration 0011 adds labels.color, server_default 'default' so existing labels keep the neutral chip). The PATCH endpoint now updates name and/or color; note serialization carries each label's color. Frontend: a swatch picker per label in the Edit-labels modal, colored chips on cards + in the editor (LABEL_CHIP_CLASSES), and a color dot on each sidebar label. Reuses the note color vocabulary. (Graph node coloring rides this in the graph-liveliness task.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-20 13:11:50 -04:00
bvandeusenandClaude Opus 4.8	c57982d910	M3 reminders: notes.remind_at + Reminders view ... - Migration 0010: notes.remind_at (nullable tz). PATCH accepts remind_at (ISO set / null clear); GET /api/notes/reminders (soonest first, non-trashed); serialize includes remind_at. - Frontend: datetime util (local<->ISO, format, overdue); notes store setReminder; editor datetime-local picker + clear; card reminder chip (overdue = red); sidebar Reminders entry + /reminders view. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-20 08:12:14 -04:00
bvandeusenandClaude Opus 4.8	0f604f9a26	M1: masonry board UI — quick-add, note cards, editor, views ... - notes Pinia store (load/create/pin/archive/color/trash/restore/delete) with view-aware reconcile; api client patch/del methods. - colors.ts palette (10 keys → light/dark card + swatch tints). - QuickAdd (collapsed → expand, title/body/color, click-outside/Esc to save), NoteCard (color tint, click-to-edit, hover action bar), NoteEditor modal, ColorPicker, inline Icon set (no icon dep). - BoardView rewrite: Notes/Archive/Trash routes, CSS-columns masonry, Pinned + Others sections, per-view empty states, sign-out. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-19 16:08:53 -04:00