2026.08.27.03 — a filter on both screens

a calendar of a few hundred events and an address book of a few hundred cards are
both lists you scroll until you give up. one box on each header narrows them.

CLIENT SIDE, because the data is already here: both screens fetch a whole
collection in one request and hold it, so filtering is a string comparison over
what is in hand. a round trip per keystroke would be slower, would need a search
endpoint on the sidecar, and would put a spinner where a person expects a list to
narrow as they type.

ACCENT-INSENSITIVE, and that is the half that decides whether this is usable
here: these contacts are portuguese, and a box where "jose" does not find "José"
is a box nobody uses twice. NFD splits the letter from its accent and the range
strips what is left, so it matches in both directions — "josé" finds "Jose" too.

every term must match somewhere, not all in one field, so "ana lisboa" finds the
ana whose address is in lisbon. events match on their start as well, which is an
ISO string, so "2026-08-29" narrows to a day without anything having to parse it.

the count in the header becomes "12 of 340" while filtering, and a filter that
matches nothing says so by name — otherwise it reads as a calendar that lost its
events.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043

manifest.ts

@@ -9,7 +9,7 @@ import type { PluginManifest } from '@@/plugins/manifest';
  */
 export const manifest: PluginManifest = {
   publisher: 'officerdev',
-  version: '2026.08.27.02',
+  version: '2026.08.27.03',
   platform: '>=1.0.0',
 
   /**