15 Commits

Include renames

Author	SHA1	Message	Date
bvandeusen	761c3b5e82	server: the body is the checklist here too, and note_items is dropped ... M304 steps 3 and the server half of 4. The client half landed in 668f7fa; these belong in one deploy, and the protocol floor below is what enforces that. notes/checklist.py is the Python half of a grammar that now exists three times — here, core/src/local/derive.rs, and (next) frontend/src/notes/markdown.ts. That triplication is the deliberate cost: the alternative is a round trip to the server before a phone can draw a checkbox. Each copy names the other two, and each is tested against the same table of cases, including the near-misses that must stay prose: `-[ ] x`, `- []`, `- [ ]x`, a `[ ]` mid-sentence. Routes: add/update/delete items stop touching rows and rewrite note.body, all through one _rewrite_body that runs the same sequence the PATCH route runs for a body change — because it IS a body change. Revisions, #tag reconciliation, the name, and link unfurls therefore happen in one place rather than three routes each remembering to. The reorder route is gone (rule 22). Reordering a checklist is moving a line, and no client ever called it — the only reference in the tree was a test asserting the route existed. The API still returns `items`, DERIVED from the body on the way out. That is not a second source of truth and it cannot disagree with the body it came from; it keeps the web client working across the rest of this milestone and saves any consumer that only wants to draw checkboxes from carrying a parser. Export drops its separate items block, in both formats. The body already ends with those exact lines, so writing them again would double every checklist in an export and then double it again on re-import. Import still ACCEPTS items, because a Keep takeout has a list and not a blob; it folds them in before the Note is built, so display_title and _reconcile_tags both see the finished text. Protocol 3 on both sides now. A v2 client is refused rather than half-served — which matters more than I first said: _apply_note_items returned early on an absent `items` key, so an un-bumped v3 client against a v2 server would not have LOST the rows, it would have kept them and then had the migration fold them a second time. Duplicated lists rather than missing ones. The floor prevents both. Migration 0027 folds every existing row into its note's body and drops the table. It inlines its own copy of the fold on purpose — a migration has to keep producing what it produced the day it ran — and a test pins that copy against the app's until they are allowed to diverge. updated_at is deliberately untouched: a client holding an unpushed edit keeps the newer timestamp, so last-write-wins keeps its work instead of the migration silently winning. The downgrade is honest rather than faithful. It recreates an empty note_items and leaves the bodies alone, because once items are lines nothing distinguishes one this migration wrote from one somebody typed, and a downgrade that guessed would eat hand-written lists. Recreating the table is still necessary: 0015's downgrade drops a trigger ON note_items, and IF EXISTS covers the trigger, not the table.	2026-08-24 08:03:37 -04:00
bvandeusenandClaude Opus 5	2707054563	A write should not cost a revision ... Every body change snapshotted into history — core/src/local/store.rs and notes/__init__.py both — so a write was expensive, and the clients compensated by writing as rarely as they could. BoardViewModel says it outright: "Saved on close rather than per keystroke, so a session of typing costs one write and one revision snapshot." That is durability paying for version history. An app kill mid-session lost everything typed, so that the revision list would stay tidy. The safety property is worth more than the feature it was subsidising, and no comparable product makes this trade: Keep and Apple Notes write continuously with no history, Docs and Notion write continuously and coalesce history behind the scenes, Obsidian debounces and snapshots on an interval. Save-on-close is the outlier, and this coupling is why we had it. A body change now earns a snapshot only if it is the first of an editing session — the body actually differs, and the note carries no revision from the last ten minutes. Session granularity falls out of the window rather than being declared. A snapshot stores the body as it was BEFORE the edit, so the first write of a sitting captures the note as you found it and every write after it inside the window adds nothing. One revision per sitting, with no commit flag for a client to send and no wire surface to carry it. That is why it is a time rule and not a protocol one. sync.py applies pushed bodies through the same check, so a client autosaving every second cannot make the server snapshot every second either — which a client-declared commit point could not have guaranteed without a protocol bump. Restoring a revision still snapshots unconditionally: a considered act, not a keystroke, and it stays undoable. Unblocks idle-debounced autosave, an honest updated_at, and the "Edited just now" line the editor is getting. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-23 21:47:01 -04:00
bvandeusen	de72d27bd4	URLs unfurl on their own, and a lone link becomes the note ... Operator: *"I'd like for URLs to unfurl. To be the whole note when the note is a single URL, and to be a compact slot on the bottom of the note when the URL is inline. We also need to support multiple URLs in a single note."* Less new machinery than it sounds: `unfurl.py` already fetched and parsed OG tags, SSRF-hardened, and `note_link_previews` was already `UNIQUE(note_id, url)` — so several URLs per note has worked at the storage layer all along. What was missing was that it needed a button, had one size, and drew that size in the wrong place. **Automatic, and never in the way.** New `unfurl_queue.py` detects a body's URLs and fetches them on a background task AFTER the note is committed. Capture speed is the product: an unfurl is a five-second timeout against a host nobody controls, and a note has to persist the instant someone stops typing. Scheduled from create, from a body edit, and from a synced push — so a linked desktop or Android client gets previews too, on its next pull. An unlinked one has no server to ask and simply has none, which is the honest consequence of being offline. Safe to call on every save: it re-reads what's cached and does nothing when nothing is new. Capped at five URLs per note, silent on every failure (a link that won't fetch isn't an error the person needs — the note is fine, the link is still there), and it re-checks before storing, so a slow fetch can't resurrect a preview for a URL that was deleted while it was in flight. **Two presentations.** A note whose body is nothing but a URL renders as its preview and nothing else — printing the raw URL under a card that already says where it goes is saying the same thing twice, badly. Until the fetch lands, or if it never does, the URL stands in, so the card is never blank. Anything else gets a compact strip. **And the strip moved.** Previews were rendered ABOVE the body, which put a stranger's headline where the note's own first line should be — worse now that the first line IS the note's name. They sit at the foot of the card now, under the note's own words. The editor's "Preview example.com" button is gone with the manual path; removing an unwanted preview stays, and stays editor-only. Nine tests: three on detection (order, dedupe, sentence-punctuation trimming, non-http rejection) in the unit lane, and three in the integration lane for what only a real database shows — the upsert landing on the right row, a second pass fetching nothing, and a preview NOT being stored for a URL that left the body.	2026-08-23 01:05:37 -04:00
bvandeusen	95aa10c2c3	Remove the title field — a note is named by its first line ... Operator (note 2897): "notes shouldn't have a title field." The concept of a NAME stays — search results, export filenames and the command palette all need one — but nothing is typed into it any more. `display_title` is now the first non-empty line of the body, falling back to the first checklist item. That fallback is what step 2 bought, and the reason this could not go first: a checklist had no body to be named from, so the title was its only name. Now every note has a body, and a note that is only a checklist is named by its first item. Gone everywhere: the column and note_revisions.title (0026), the field on the core's Note/NoteCreateInput/NoteRevision and its SQLite columns (user_version 7), `normalize_title`, the wire field, the FFI record and `NoteEdit::Title` / `ClearTitle`, the web editor's "Title (optional)" input and the card's <h3>, and the Android title field in both the compose sheet and the editor. **The search vector had to be rebuilt, not just left alone.** `notes.search_vector` is a STORED GENERATED column whose expression names `title` — Postgres refuses to drop a column another generated column depends on. It is dropped and recreated over `display_title` at weight A, which keeps the original intent: a note's NAME ranks above the rest of its body. **An imported title becomes the note's first body line.** Keep notes carry one, and so does any ThoughtSync export taken before this. Dropping it would silently lose text someone wrote; folding it in puts it exactly where a name now lives, so the note arrives named as it was. Skipped when the body already opens with that line, so re-importing an export this code produced doesn't stack duplicates. Two smaller things fell out. The Android editor loses its bold first field — one weight throughout, because the first line is the note's name but not a different KIND of text, which is most of step 4 arriving early. And `ClearTitle`'s justification comment moved to `ClearRemindAt`, which is now the surviving example of why NoteEdit is a list rather than a struct of options. Protocol note corrected to say what actually shipped: v2 is "no kind, no title", one bump for the pair. Verified with the local Rust gate this time, not by CI: fmt, clippy and 116 tests all green before pushing. It caught four things — orphaned serde attributes where fields were removed, a `wire::Preview.title` I deleted by mistake (a link preview still has one), nine retention fixtures inserting a dropped column, and four rustfmt diffs.	2026-08-22 19:33:57 -04:00
bvandeusen	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	229076c82d	sync: stop deleting a note's checklist items because it isn't a "list" ... `_apply_note_items` didn't ignore items on a non-list note — it deleted them. That was survivable only because nothing in the product could produce a note holding both a body and items. M13 makes exactly that the normal shape: a checklist is something a note HAS, not something a note IS. Against that shape this guard is a data-loss path — the first sync after adding a checklist to a note would wipe it. Landing it before the UI that can create the state, so there is never a window where the two disagree. `kind` itself, and the rest of the merge, follow.	2026-08-22 12:45:14 -04:00
bvandeusen	bc22f8e249	Remove [[wiki-links]], backlinks and the graph ... Operator, 2026-08-22 (note 2897): ThoughtSync is an intermediary surface. You write here because it's easy — a notebook in your pocket — and later you recall the thing and go finish it somewhere else. Recall is the product; organization is secondary. A linking system is organization, and it isn't what this is for. So: `[[wiki-links]]`, backlinks, the `[[` autocomplete, the note_links table, `/api/notes/link-search`, `/api/notes/<id>/backlinks`, the whole graph blueprint and GraphView. Rust core loses `extract_links`, `backlinks`, `link_search` and `create_titled`; the desktop loses the three Tauri commands that exposed them. This subsumes 982d24c rather than reverting it. That commit bound links to a note id so a rename would stop rewriting other notes' bodies — real infra, but infra for a feature that is now gone, and nothing it added survives. Alembic 0023 stays in the chain anyway: it shipped in an image and may already be applied, and deleting an applied revision strands a database's version pointer. 0024 drops the table and takes the column with it. The history stays honest about the fact that it existed for a day. Two things deliberately kept, because they were serving recall and only incidentally serving links: - `/api/notes/titles` and the titles store. The command palette lists them so you can jump to a note by name. `resolve()` — the name→note lookup that only linking needed — is gone. - `display_title`. Every note still has a name for search results and export filenames. What that name is FOR changed; that it exists did not. `notes/links.py` is now `notes/tags.py`, holding the #tag→label reconciliation it always also owned. A file called links.py with no links in it would have been exactly the drift this removal is meant to end. Also swept out on the way: `_escape_like`, whose only caller was link-search, and the `graph` icon. Nothing lost that a person typed — note_links was always derived, and the `[[text]]` is still sitting in every body it was written in.	2026-08-22 12:00:57 -04:00
bvandeusen	982d24c83b	links: bind a [[link]] to a note, not to a string ... A wiki-link was stored only as normalized TEXT, so a note's NAME was the edge. Renaming it broke every inbound link — and the fix that shipped for that (task 1848, option b) was `_rename_inbound_links`: rewrite the `[[Old Name]]` text inside the body of every note that linked to the renamed one. That works while an explicit title exists to hold still. It stops being defensible the moment a note's name is just its first body line, which is where M13 is going: fixing a typo in your opening sentence would silently edit other notes' words, with nothing to opt out to. So this lands first, before the title comes out, and that window never ships. `note_links` gains `target_id`, bound when the link is written. `target_norm` stays and is what an UNRESOLVED link carries — linking to a note that doesn't exist yet is a supported way to create one, so a link has to be able to name a target that isn't there. Resolution reads the id, falling back to the name only where nothing was bound, which is what lets a forward link connect the moment its target appears. `_claim_unresolved_links` then binds it, so the fallback is a transitional state rather than a permanent one. `_rename_inbound_links` and `rewrite_link_title` are gone. What replaced them touches link rows only: a note's text is never modified by something happening to a different note. The client can no longer resolve links for itself, and that is the point. It used to look `[[text]]` up in a client-side name index, which only held together BECAUSE renaming rewrote the text everywhere. Now the written text can name something the target is no longer called, and only the server holds the binding — so each note serializes its resolved links (`norm`, `id`, and the target's name as it stands NOW). A renamed note reads correctly everywhere it is linked from, without a single body having been edited. Unresolved links are simply absent and fall through to the create-on-click affordance that already existed; so does the offline desktop store, which derives links at query time and has no binding to send. The name-fallback join is owner-scoped everywhere it appears. Bound ids were resolved owner-scoped when written, but matching on display_title alone would have let two users who each have a note called "Groceries" see the other's id and name through an unresolved link (rule 47). The new behaviour is all SQL and this suite runs without a database, so the dead helpers' tests are removed rather than replaced. This repo has no integration lane to hold that ground — noted, not papered over.	2026-08-22 11:02:39 -04:00
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 5	fbbe877c46	M10.6: client↔server sync protocol handshake (task 1995) ... Version the sync WIRE PROTOCOL separately from either program's release version, so a self-hosted server and the desktop app can sit on different releases and still work out whether they can talk. Each side declares two numbers — what it speaks, and the oldest counterpart it accepts. Either side can therefore mark a change breaking without the other shipping in step, which is the whole point: no app↔server lockstep. Server advertises on the existing public /api/config (a client must be able to ask "can I talk to you?" before it holds a device token, or even has an account): sync_protocol_version, min_client_protocol_version, sync_features. sync_features exists because a version number can only say newer/older. An ADDITIVE change earns a capability name instead of a minimum bump, so a newer client meeting an older server drops that one feature and syncs the rest, rather than refusing. Raising a minimum is reserved for genuinely breaking changes — it's the switch that hard-blocks the other side. Client half is pure decision logic (sync/compat.rs), no I/O, so every branch is unit-testable — there's no live-server lane in CI. Three outcomes: ok / degraded{unavailable} / incompatible{reason, client_must_update}. The last names which side can fix it, so the message is actionable. A server that predates the handshake sends no protocol fields at all; that reads as "update the server", deliberately not as a parse error, which would look to the user like they mistyped the URL. normalize_base_url defaults a bare host to https://, never http:// — silently downgrading would put a long-lived device token on the wire in cleartext because someone omitted five characters. Plain HTTP on a trusted LAN stays supported; the user types http:// and thereby chooses it. Transport (the actual fetch) lands next, separately: it needs an HTTP/TLS stack, and that's a real risk to the Windows cross-compile lane, so it gets its own CI run to bisect against rather than riding along with this. No UI here by design — the link/settings surface it feeds is M10.7's, per this task's own sequencing. Policy documented in docs/sync.md. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-25 22:40:25 -04:00
bvandeusenandClaude Opus 4.8	be34fe8619	M9 S4: sync adopts serialization/parse_dt toolkit + normalizes push oracle ... DRY: - serialize.py: serialize_label_sync(label) = base serialize_label + the delta-only fields (sync_revision/purged_at/created_at via iso()). sync's changes() adopts it; the local _serialize_label_row near-dup is gone. - sync adopts common.parse_dt (drops the byte-identical _parse_client_dt; 4 call sites) and common.iso for the note delta augmentation. (Manual-label reconciliation was already shared in S3.) Fully folding the note re-augmentation into the serializer waits on the notes.py split. - test_sync: drops the now-redundant _parse_client_dt test (parse_dt is covered in test_notes) + its dead import. Security (issue — push existence-oracle): a foreign-owned id on push was rejected with "not yours", distinguishing "another user's note" from a free id. A legit client only pushes ids of notes it created, so that branch is only hit by a probe (or ~0-prob UUID collision) — now a GENERIC "cannot apply" rejection that doesn't confirm the id exists. The residual create-vs-reject status difference is inherent to client-chosen ids over a global PK and is practically unexploitable (a shared note already exposes its id to recipients). Sync behavior operator-verified on deploy (no Postgres CI lane). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-23 21:45:36 -04:00
bvandeusenandClaude Opus 4.8	f1033da75e	M9 S3 (backend): organize routes adopt toolkit + shared label reconciliation ... DRY across the "organize/recall" backend surface: - serialize.py (new): serialize_label(label) — the base {id,name,color} shape. labels.py builds on it (adds count); sync deltas will (S4). - labeling.py (new): resolve_owned_label_ids() + reconcile_manual_labels() — the "set a note's MANUAL (picker) labels, leave the via_tag rows alone" logic was duplicated line-for-line between notes.set_note_labels and sync._apply_note_manual_labels. Now one home; both adopt it (removes the redundant `chosen`==owned recompute in notes). Behavior-preserving. - labels.py: json_error/not_found/parse_uuid, colors.normalize_color, and serialize_label; dropped local LABEL_COLORS + _normalize_label_color (NOTE_COLORS is the single palette) and `import uuid` (rule 22). - saved_filters.py: json_error/not_found/parse_uuid for its 2 uuid parses + error shapes. - graph.py: no change — no error/uuid/palette-normalize duplication to fold. Test: DB-free test_serialize_label_shape guards the base shape. sync.py's reconciliation swap is behavior-identical; operator-verified on deploy (no Postgres CI lane). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-23 21:26:59 -04:00
bvandeusenandClaude Opus 4.8	882d4206aa	M6 1908a: recurring reminders + complete/snooze (backend, no web-push) ... Per operator: skip Web Push; build the rest of reminder delivery. This is the client-agnostic half — the model + logic that foreground/native delivery drives. - notes.recurrence (migration 0022): daily/weekly/monthly/yearly or null. update_note accepts it (cleared when the reminder is cleared); rides export/import + sync push. Serialized on the note. - Pure next_occurrence(remind_at, recurrence, after): the next fire strictly after `after`, rolling past missed occurrences; _add_months clamps the day to the target month (Jan 31 → Feb 28). - POST /api/notes/<id>/reminder/complete — a recurring reminder advances to its next occurrence; a one-off clears. POST .../reminder/snooze {minutes} → remind_at = now + minutes (1 min .. 30 days). No VAPID / push-subscription / service-worker — foreground + native delivery land in the UI commit and the native clients. Tests (DB-free): normalize_recurrence; next_occurrence (daily/weekly/ monthly-clamp/skip-missed/yearly/none); complete + snooze auth-guards. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-23 11:53:07 -04:00
bvandeusenandClaude Opus 4.8	68abaa0f3f	Sync 4: push endpoint POST /api/sync/push (LWW + history snapshot) ... The core conflict-resolution step. Applies a batch of client changes, additive + owner-scoped, with last-write-wins by client edit-time — and a version-history snapshot on every overwrite so nothing is ever lost. client_wins(client_edited_at, server_edited_at): apply iff client >= server; a missing client time never overwrites a real server edit; a missing server time (new row) yields. Notes compare against updated_at; labels gain an updated_at (migration 0017, backfilled from created_at) as their LWW field. Notes: - upsert with a client-supplied id: create if absent, else LWW-apply the full note state (title/body/color/kind/pins/trash/remind/position/items/ manual label_ids) with the same ripple as a web edit — derive_display_title, _rewrite_links, _reconcile_tags (#tags), _rename_inbound_links. Overwriting an existing title/body snapshots the old version into note_revisions first. A resurrected tombstone clears purged_at. - delete: purge tombstone (drop children + attachment files, clear content, set purged_at), LWW-guarded so a newer server edit survives a stale delete. Labels: upsert (create/rename/recolor) + delete (detach from notes, tombstone), LWW-guarded; per-owner name-uniqueness clash on a different id is rejected rather than raising. Response: per-item {status: created|applied|kept|noop|rejected, sync_revision}; the client pulls afterward to converge. Whole-note semantics (client sends the full state, not a partial patch). Tests (DB-free): client_wins across all edit-time combinations; _parse_client_dt; push auth-guard. Apply behavior + triggers operator-verified on deploy. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-22 23:09:23 -04:00
bvandeusenandClaude Opus 4.8	8e40ea1188	Sync 3: pull endpoint GET /api/sync/changes (M8) ... Delta pull for native clients: returns every note + label the caller owns whose sync_revision advanced past ?since=<cursor>, ascending by revision, paginated (?limit, default 500 / max 1000), with the next cursor + has_more. since=0 is a full initial sync. Web app unaffected (new blueprint). Notes and labels share one revision sequence, so the cursor is a single watermark. _page_cursor() handles the two-stream paging: when either stream fills its page, it advances only to the SMALLER of the two page boundaries so nothing between the cursor and the next pull is skipped. Notes reuse _serialize_notes (items/labels/attachments inline) + sync_revision + purged_at (tombstone); labels carry name/color/purged_at/sync_revision. Returns ALL of the owner's notes regardless of state (active/archived/ trash/purged) — a client mirrors everything. Registered sync blueprint. Tests (DB-free): changes auth-guard; _parse_since / _clamp_limit validation; _page_cursor across empty / drained / one-full / both-full. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-22 23:03:06 -04:00