@bobfrankston/rmfmail 1.2.125 → 1.2.127

package/TODO.md

@@ -254,7 +254,7 @@ Small, self-contained items. Pick them up between higher-priority blocks without
 
   Alternative source worth evaluating before generalizing: **Hebcal** (`https://www.hebcal.com/`) publishes a more rigorously curated Jewish-only feed (iCal + JSON API), and similar projects exist for other traditions. A `JsonHolidayProvider` interface that abstracts Google vs Hebcal vs ICS-by-URL behind a common shape would let users plug in whatever feed they trust.
 - **Q150 — `discovered` contacts don't belong in the cloud file — split it.** Bob 2026-05-16 hit a 1.5 MB `contacts.jsonc` (11,034 `discovered` rows) and asked about CSV. CSV is the wrong fix (saves ~half the bytes, loses the preferred/denylist/groups structure). Real issue: `discovered` is a *derived cache* — name/email/useCount/lastUsed rebuildable per-device from the message corpus (`seedContactsFromMessages`) — so it shouldn't be in the cloud-synced JSONC at all. Split: cloud `contacts.jsonc` keeps only user-curated data (`preferred`, `denylist`, `groups`) ≈ a few KB; `discovered` lives in the local DB only, rebuilt from each device's mail. Shrinks the cloud file ~700×, kills the 1.5 MB-blob fragility, and matches the "local store is a cache" rule.
-- **Q154 — Prefetch "0 FETCH responses" on new arrivals: verify-then-classify instead of ERROR noise.** [S] Diagnosed 2026-07-12: 60–120×/day, bobma INBOX. Sequence: envelope arrives → server-side filtering (Sieve/screener) moves it to _Spam within seconds → body prefetch FETCHes the now-gone UID in INBOX → 0 responses → logged as ERROR twice; move-detect later rebinds the row (self-healing). Fix: on a 0-response batch, UID SEARCH the missing UIDs — absent from folder = expected-move (log one info line, let reconcile own it); still present = REAL fetch failure (keep the ERROR). Also answers the broader "deleted on server — find out for certain" principle (see v1.2.124 bodyError classifier: deletion is only claimed on positive server evidence). Watch: whether messages that STAY in INBOX ever hit this path — if so that is a real prefetch bug, not noise.
+- ~~**Q154 — Prefetch "0 FETCH responses" on new arrivals: verify-then-classify instead of ERROR noise.**~~ **DONE (2026-07-12, v1.2.125).** Zero-response chunks now UID-verify against the server: absent → one info line ("no longer in folder — reconcile owns the rows"); still present → ERROR marked "real fetch failure". Watch the log for the STILL-PRESENT variant — that would be a genuine prefetch bug. [S] Diagnosed 2026-07-12: 60–120×/day, bobma INBOX. Sequence: envelope arrives → server-side filtering (Sieve/screener) moves it to _Spam within seconds → body prefetch FETCHes the now-gone UID in INBOX → 0 responses → logged as ERROR twice; move-detect later rebinds the row (self-healing). Fix: on a 0-response batch, UID SEARCH the missing UIDs — absent from folder = expected-move (log one info line, let reconcile own it); still present = REAL fetch failure (keep the ERROR). Also answers the broader "deleted on server — find out for certain" principle (see v1.2.124 bodyError classifier: deletion is only claimed on positive server evidence). Watch: whether messages that STAY in INBOX ever hit this path — if so that is a real prefetch bug, not noise.
 
 - **Q151 — AI config window (natural-language config edits).** Bob 2026-05-16: an AI window that understands the config files so he can say "don't show outlook_…@outlook.com". Feasible — mailx already has AI plumbing (aiTransform, provider+key in autocomplete settings) so it reuses the existing key. Design constraint: the AI must NOT free-form-rewrite a JSONC file (a malformed contacts.jsonc wipes everything — just saw it). It proposes a structured operation (`denylist add <email>`, `preferred add …`), shows a diff, the user confirms, and mailx applies it via the existing typed methods (`addToDenylist`, `addPreferredContact`, …). Worth it for open-ended requests ("stop showing anything from that marketing company", "merge these contacts") — for a single denylist it's overkill vs. a direct affordance (Q149).
 - **Q149 — Visible prefer/ignore affordances.** (1) ✅ **Done v1.1.55** — compose autocomplete rows now have visible per-row ★ (prefer → `contacts.jsonc#preferred[]`) and ⊘ (ignore → `denylist[]`) buttons, shown on hover; plain click, no dependence on the flaky right-click. (2) STILL OPEN — "Never use this address" in the message-viewer From/To/Cc right-click menu (currently Copy / Add to contacts / Reply only). (3) Related: route ★ to a Google-Contacts star instead of `preferred[]` once that's decided (see Q151 discussion).

package/client/app.bundle.js

@@ -46,6 +46,7 @@ __export(api_client_exports, {
   deleteTask: () => deleteTask,
   drainStoreSync: () => drainStoreSync,
   emptyFolder: () => emptyFolder,
+  fetchImageAsDataUri: () => fetchImageAsDataUri,
   flagSenderOrDomain: () => flagSenderOrDomain,
   formatJsonc: () => formatJsonc,
   getAccounts: () => getAccounts,
@@ -648,6 +649,10 @@ function closeComposePopout(id) {
   const fn = ipc().closeComposePopout;
   return fn ? fn(id) : Promise.resolve({ ok: false });
 }
+function fetchImageAsDataUri(url) {
+  const fn = ipc().fetchImageAsDataUri;
+  return fn ? fn(url) : Promise.resolve({ error: "no bridge" });
+}
 async function popoutMainWindow(accountId, folderId, name) {
   const fn = ipc().popoutMainWindow;
   if (!fn)