From 7aef01d95e4af204ccda033a047765d1c0854dd9 Mon Sep 17 00:00:00 2001 From: Jean-Luc Makiola Date: Sat, 25 Jul 2026 21:34:24 +0200 Subject: [PATCH] docs(architecture): record what the second review pass changed The visibility section claimed the reminder side needed no per-calendar handling. It does on the one path where VISIBLE was never written: an alert the notifier silences keeps its SCHEDULED state while its event is still ahead, and switching the calendar back on re-posts it, so the provider's own table is the stash the deleted SuppressedReminderStore used to be. Also rewraps the paragraph and separates it from the one that follows, which it had been running into since the section was added. Co-Authored-By: Claude Opus 5 (1M context) --- docs/ARCHITECTURE.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/docs/ARCHITECTURE.md b/docs/ARCHITECTURE.md index 50698ae..629f57f 100644 --- a/docs/ARCHITECTURE.md +++ b/docs/ARCHITECTURE.md @@ -171,8 +171,13 @@ the app has not been allowed to write yet (read-only permission grant, or a pre-permission launch); `CalendarVisibilityReconciler` drains it entry by entry, and until it does, the repository and `ReminderNotifier.post` honour it. That gate also covers a snooze re-shown from our own alarm after its calendar was -switched off. The drawer's filter sheet (`CalendarPrefs.hiddenCalendarIds`) is a -separate in-app declutter that never touches reminders. +switched off. Silencing is not handling: an alert the gate drops keeps its +`SCHEDULED` state while its event is still ahead (`handledAlertIds`), so +switching the calendar back on re-posts it (`ReminderRecovery`) instead of +losing it — the provider's own table is the stash. The drawer's filter sheet +(`CalendarPrefs.hiddenCalendarIds`) is a separate in-app declutter that never +touches reminders. + Deliberately absent until real devices prove it necessary: own alarm scheduling, `BOOT_COMPLETED`, snooze/dismiss actions, battery-exemption prompts.