Offline PWA sync

Make every read and write go through an IndexedDB queue and render the UI from local state — so the app works with DevTools set to Offline and a write survives a reload. The queue is an append log of `{id, op: 'create'|'update'|'delete', payload, local_updated_at, status: 'pending'|'synced'}` keyed by note id; reads merge the pending queue over the last-synced snapshot so the UI is always optimistic. The critical invariant is durability: a write made offline is written to IndexedDB synchronously (inside the same tick that updates the UI) and is still queued after a page reload — if it lives only in memory, a reload before reconnect loses it. Prove it: go offline, create/edit a note, reload the page while still offline, and show the note is still there and still pending; then go online and show it syncs.

Add a service worker with differentiated caching strategies and a correct update lifecycle. The app shell (HTML) uses stale-while-revalidate — always fast (serve from cache immediately, update in the background) with a one-visit staleness window that is acceptable for a shell. Versioned static assets (JS/CSS with content-hash filenames) use cache-first — they are truly immutable, so serve from cache with no revalidation. A new deploy must update the cached shell on the next visit without a hard refresh: the new worker installs, waits in 'waiting' until all tabs unload (or skipWaiting is called), then activates and claims clients. Document the tradeoff: waiting until tabs close means 'stale until restart' but no mid-session inconsistency; skipWaiting means immediate activation but risks serving the new shell against the old asset set. State the stale-content window for each strategy and why the lifecycle makes update timing non-obvious.

Flush the write queue on reconnect, resolve conflicts with last-writer-wins, and register a Background Sync tag as a fallback for missed flushes. On reconnect (online event + visibilitychange + Background Sync), iterate the pending queue in order and POST each op to the server; the server compares `server_updated_at` vs `local_updated_at` and keeps the later one (LWW). No edit is silently lost — the losing version is at least logged and surfaced in the UI as a conflict. Register a Background Sync tag (`sync-pending-writes`) on every write so the browser fires the sync event even if the tab was closed at reconnect time. Then address the browser-support caveat: Safari's partial Background Sync support means the queue must also flush on page-visible and online events as a fallback. Document where whole-document LWW fails: two users editing different fields of the same note — the later flush clobbers the other's field change because the merge key is document + timestamp, not field + timestamp.

Make the offline experience feel instant and legible. Every local write updates the UI immediately (optimistic) before the sync confirms it — no spinner on create/edit/delete. The sync status is always visible: a persistent indicator shows 'All synced' / 'Syncing…' / 'Offline — N pending' / 'Conflict on note X', and each note shows its sync state (synced vs pending). A pending queue that grows while offline is shown with a count, and a conflict resolved via LWW surfaces which version won and why (timestamp comparison). Measure the perceived latency: with optimistic UI, create-to-visible is <16 ms (one frame); without it, it's network RTT + server time. Prove it by toggling optimistic off and showing the delay, and by going offline, queuing 5 edits, and showing all 5 appear instantly with correct status transitions as they sync on reconnect.

Make sync observable and prove it survives an incident. Emit metrics for the offline subsystem: pending queue depth, flush success/failure rate, sync duration p50/p99, conflict rate, and service-worker cache hit rate. Show them on a small dashboard or console panel. Then work an incident: simulate a flaky network (intermittent failures on the flush endpoint) mid-sync and watch the queue stall — pending depth stops draining, retry backoff kicks in, conflicts accumulate if the server mutated the same notes. Detect it from your dashboard (pending depth flat, failure rate up), mitigate (retry with backoff, surface conflicts to the user, don't duplicate-queue), and write a 5-line post-mortem whose prevention is not 'never go offline'. Document the Background Sync failure modes: the browser fires sync when it believes the network is available but doesn't guarantee delivery time; a failed sync re-queues with browser-controlled exponential backoff; if the browser kills the SW before sync completes, the tag stays registered and retries — but only where Background Sync is supported.