feat: open Day view when tapping a date header in Week/Agenda

Tapping a date header in the Week (day-of-week column) and Agenda
(sticky section) views now drills into that date in Day view, mirroring
the Agenda widget's header behaviour. Both reuse the existing onOpenDay
callback (pendingDayIso + drillToDay) that Month already used, so the
back stack lands on Day with the tapped view as its parent.

Month already navigated on any cell tap (the transparent tap layer sits
above the day number), so no change was needed there — all four views
now behave consistently.

Closes #37

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.gitignore

@@ -55,3 +55,6 @@ Thumbs.db
 
 # KSP
 .ksp/
+
+# Claude Code
+/CLAUDE.md

app/src/main/java/de/jeanlucmakiola/calendula/ui/CalendarHost.kt

@@ -284,6 +284,7 @@ fun CalendarHost(
                 CalendarView.Week -> WeekScreen(
                     selectedView = currentView,
                     onSelectView = onSelectView,
+                    onOpenDay = onOpenDay,
                     onEventClick = onEventClick,
                     onOpenSettings = onOpenSettings,
                     onOpenSearch = onOpenSearch,
@@ -315,6 +316,7 @@ fun CalendarHost(
                 CalendarView.Agenda -> AgendaScreen(
                     selectedView = currentView,
                     onSelectView = onSelectView,
+                    onOpenDay = onOpenDay,
                     onEventClick = onEventClick,
                     onOpenSettings = onOpenSettings,
                     onOpenSearch = onOpenSearch,

app/src/main/java/de/jeanlucmakiola/calendula/ui/agenda/AgendaScreen.kt

@@ -93,6 +93,7 @@ private val zone = TimeZone.currentSystemDefault()
 fun AgendaScreen(
     selectedView: CalendarView,
     onSelectView: (CalendarView) -> Unit,
+    onOpenDay: (LocalDate) -> Unit,
     onEventClick: (EventInstance) -> Unit,
     onOpenSettings: () -> Unit,
     onOpenSearch: () -> Unit,
@@ -191,6 +192,7 @@ fun AgendaScreen(
                     pastDisplay = pastDisplay,
                     onRetry = viewModel::goToToday,
                     onEventClick = onEventClick,
+                    onOpenDay = onOpenDay,
                     modifier = Modifier
                         .weight(1f)
                         .fillMaxWidth(),
@@ -289,6 +291,7 @@ private fun AgendaContent(
     pastDisplay: PastEventDisplay,
     onRetry: () -> Unit,
     onEventClick: (EventInstance) -> Unit,
+    onOpenDay: (LocalDate) -> Unit,
     modifier: Modifier = Modifier,
 ) {
     when (state) {
@@ -318,6 +321,7 @@ private fun AgendaContent(
                     dimPast = pastDisplay == PastEventDisplay.DIM,
                     now = now,
                     onEventClick = onEventClick,
+                    onOpenDay = onOpenDay,
                     modifier = modifier,
                 )
             }
@@ -333,6 +337,7 @@ private fun AgendaList(
     dimPast: Boolean,
     now: Instant,
     onEventClick: (EventInstance) -> Unit,
+    onOpenDay: (LocalDate) -> Unit,
     modifier: Modifier = Modifier,
 ) {
     LazyColumn(
@@ -342,7 +347,7 @@ private fun AgendaList(
     ) {
         days.forEach { day ->
             stickyHeader(key = "header-${day.date}") {
-                AgendaDayHeader(date = day.date, today = today)
+                AgendaDayHeader(date = day.date, today = today, onOpenDay = onOpenDay)
             }
             itemsIndexed(
                 items = day.events,
@@ -362,10 +367,16 @@ private fun AgendaList(
 }
 
 @Composable
-private fun AgendaDayHeader(date: LocalDate, today: LocalDate) {
+private fun AgendaDayHeader(
+    date: LocalDate,
+    today: LocalDate,
+    onOpenDay: (LocalDate) -> Unit,
+) {
     Surface(
         color = MaterialTheme.colorScheme.surface,
-        modifier = Modifier.fillMaxWidth(),
+        modifier = Modifier
+            .fillMaxWidth()
+            .clickable { onOpenDay(date) },
     ) {
         Text(
             text = agendaDayLabel(date, today),

app/src/main/java/de/jeanlucmakiola/calendula/ui/week/WeekScreen.kt

@@ -128,6 +128,7 @@ private fun WeekUiState.Success.allDayStripHeight(): Dp {
 fun WeekScreen(
     selectedView: CalendarView,
     onSelectView: (CalendarView) -> Unit,
+    onOpenDay: (LocalDate) -> Unit,
     onEventClick: (EventInstance) -> Unit,
     onOpenSettings: () -> Unit,
     onOpenSearch: () -> Unit,
@@ -249,6 +250,7 @@ fun WeekScreen(
                     onSwipePrev = goPrev,
                     onRetry = jumpToToday,
                     onEventClick = onEventClick,
+                    onOpenDay = onOpenDay,
                     onCreateAt = { d, minutes -> onCreateEvent(d, minutes) },
                     modifier = Modifier
                         .padding(innerPadding)
@@ -268,6 +270,7 @@ private fun WeekContent(
     onSwipePrev: () -> Unit,
     onRetry: () -> Unit,
     onEventClick: (EventInstance) -> Unit,
+    onOpenDay: (LocalDate) -> Unit,
     onCreateAt: (LocalDate, Int) -> Unit,
     modifier: Modifier = Modifier,
 ) {
@@ -342,6 +345,7 @@ private fun WeekContent(
                 scrollState = scrollState,
                 allDayHeight = allDayHeight,
                 onEventClick = onEventClick,
+                onOpenDay = onOpenDay,
                 onCreateAt = onCreateAt,
             )
         }
@@ -355,6 +359,7 @@ private fun WeekSuccess(
     scrollState: ScrollState,
     allDayHeight: Dp,
     onEventClick: (EventInstance) -> Unit,
+    onOpenDay: (LocalDate) -> Unit,
     onCreateAt: (LocalDate, Int) -> Unit,
 ) {
     Column(modifier = Modifier.fillMaxSize()) {
@@ -363,7 +368,7 @@ private fun WeekSuccess(
                 .fillMaxWidth()
                 .background(topSectionColor),
         ) {
-            WeekDayHeader(days = state.days, today = state.today)
+            WeekDayHeader(days = state.days, today = state.today, onOpenDay = onOpenDay)
             AllDayStrip(state = state, height = allDayHeight, onEventClick = onEventClick)
         }
         // Breathing room between the (colour-shifting) top section and the
@@ -427,7 +432,11 @@ private fun WeekTopBar(
 }
 
 @Composable
-private fun WeekDayHeader(days: List<LocalDate>, today: LocalDate) {
+private fun WeekDayHeader(
+    days: List<LocalDate>,
+    today: LocalDate,
+    onOpenDay: (LocalDate) -> Unit,
+) {
     val locale = currentLocale()
     val weekStart = days.first()
     val weekNumber = remember(weekStart) {
@@ -453,7 +462,10 @@ private fun WeekDayHeader(days: List<LocalDate>, today: LocalDate) {
             val javaDow = java.time.DayOfWeek.of(date.dayOfWeek.ordinal + 1)
             val isToday = date == today
             Column(
-                modifier = Modifier.weight(1f),
+                modifier = Modifier
+                    .weight(1f)
+                    .clip(RoundedCornerShape(12.dp))
+                    .clickable { onOpenDay(date) },
                 horizontalAlignment = Alignment.CenterHorizontally,
             ) {
                 Text(

docs/superpowers/plans/2026-06-11-03-write-support.md

@@ -1,204 +0,0 @@
-# Calendula - Plan 03: Write Support (Milestone 2 / v2.0)
-
-> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
-
-**Goal:** Calendula kann Events anlegen, bearbeiten und löschen — direkt über
-`CalendarContract`-Writes, ohne eigene DB. Der V1-Spec dient als Leitplanke,
-nicht als Gesetz: Ausgeliefert wird in vier Slices (v1.1 → v2.0), jeder Slice
-ist für sich releasebar und lässt `./gradlew lint test assembleDebug` grün.
-
-**Architecture:** Writes laufen durch dieselbe Schichtung wie Reads:
-`ui/` → `CalendarRepository` (Interface) → `CalendarDataSource` →
-`ContentResolver.insert/update/delete`. Kein neuer Layer, keine Transaktions-
-Abstraktion — der Provider notified nach jedem Write selbst, der bestehende
-`ContentObserver`-Tick aktualisiert alle Views automatisch (F3 gilt unverändert).
-Domain bleibt pure Kotlin.
-
-**Leitentscheidungen (Abweichungen / Präzisierungen ggü. Spec §2 "V2"):**
-
-1. **Permission-Strategie:** `WRITE_CALENDAR` kommt ins Manifest. Das Onboarding
-   fragt READ+WRITE zusammen an (eine System-Dialog-Gruppe), zwingend bleibt
-   nur READ — wer Write ablehnt, nutzt die App weiter read-only.
-   v1.0-Upgrader (haben nur READ) bekommen den WRITE-Request kontextuell beim
-   ersten Schreib-Versuch. Onboarding-Footnote verliert die "Nur Lesezugriff"-
-   Behauptung (wäre mit Manifest-Eintrag gelogen).
-2. **Read-only-Kalender respektieren:** `Calendars.CALENDAR_ACCESS_LEVEL` wird
-   mitgelesen (`canModifyContents` = Level ≥ `CAL_ACCESS_CONTRIBUTOR`).
-   Edit/Delete-Actions erscheinen gar nicht erst für WebCal-Subscriptions,
-   Geburtstags- und andere read-only-Kalender.
-3. **Recurring Events:** Löschen bietet "Nur dieser Termin" (Exception-Insert
-   via `Events.CONTENT_EXCEPTION_URI` mit `STATUS_CANCELED` +
-   `ORIGINAL_INSTANCE_TIME`) vs. "Ganze Serie" (Delete der Events-Row).
-   Bearbeiten startet mit "ganze Serie"; Occurrence-Edit (Exception mit neuen
-   Werten) folgt erst, wenn das Serien-Edit stabil ist.
-4. **Kein RRULE-Editor in v1.2:** Create startet ohne Wiederholungs-UI
-   (einmalige Events). Ein einfacher Recurrence-Picker (täglich/wöchentlich/
-   monatlich/jährlich + Ende) kommt mit v1.3/v2.0.
-5. **Conflict UX (Spec V2 "event modified externally during edit"):** kein
-   Locking. Beim Speichern wird gegen die beim Laden gemerkte Row verglichen
-   (Dirty-Check auf den editierten Feldern); bei externem Konflikt Dialog
-   "Überschreiben / Verwerfen". Mehr ist YAGNI.
-
----
-
-## Slices
-
-| Slice | Inhalt | Status |
-|---|---|---|
-| v1.1 | Write-Fundament: `WRITE_CALENDAR`, `canModifyContents`, Delete (Serie + einzelnes Vorkommen) | ausgeliefert (v1.1.0, 2026-06-11) |
-| v1.2 | Create: Event-Formular (Titel, Kalender, ganztägig, Start/Ende, Ort, Beschreibung), FAB, Default-Kalender-Pref | ausgeliefert (v1.2.0, 2026-06-11) |
-| v1.3 | Edit: Formular wiederverwendet, Serien-Edit, Reminder-Edit, einfacher Recurrence-Picker | ausgeliefert (v1.3.0, 2026-06-11) |
-| v2.0 | Konflikt-Dialog, Polish-Pass (Store-Copy, Screenshots), Release | ausgeliefert (v2.0.0, 2026-06-11) |
-
-## v1.1 — Write-Fundament + Delete
-
-**Build/Manifest:**
-- [x] `AndroidManifest.xml`: `WRITE_CALENDAR` ergänzen
-
-**Data layer:**
-- [x] `Projections.kt`: `CALENDAR_ACCESS_LEVEL` in `CalendarProjection`
-- [x] `Models.kt`: `CalendarSource.canModifyContents: Boolean` (Default `false`).
-      Kein neuer `FailureReason` — Delete-Fehler sind ein Snackbar-Fall, kein
-      Full-Screen-Failure
-- [x] `CalendarMapper.kt`: Access-Level → `canModifyContents`
-- [x] `CalendarDataSource`: `deleteEvent(eventId)`, `deleteOccurrence(eventId, beginMillis)`
-      — Impl in `AndroidCalendarDataSource` (`delete` auf Events-URI bzw.
-      Exception-Insert), `WriteFailedException` bei 0 rows / null-Uri
-- [x] `CalendarRepository(+Impl)`: beide Methoden durchreichen, auf `io`
-
-**UI:**
-- [x] `EventDetailUiState.Success.canModify` (Kalender-Lookup im ViewModel)
-- [x] `EventDetailViewModel`: `delete(mode)` mit eigenem One-Shot-State
-      (Idle/Deleting/Deleted/Failed); `SecurityException` → kontextueller
-      WRITE-Request statt Failure-Screen
-- [x] `EventDetailScreen`: Edit/Delete nur wenn `canModify`; Delete →
-      Confirm-Dialog (recurring: "Nur dieser Termin" / "Ganze Serie"),
-      Erfolg → zurück, Fehler → Snackbar
-- [x] Onboarding (`PermissionScreen`): `RequestMultiplePermissions` READ+WRITE,
-      Gate bleibt READ; Copy-Anpassung (Footnote, Rationale-Body) DE+EN
-
-**Tests:**
-- [x] `FakeCalendarDataSource`: Write-Ops aufnehmen
-- [x] `CalendarRepositoryImplTest`: delete-Pfade (Erfolg, Fehler)
-- [x] `CalendarMapperTest`: Access-Level-Mapping
-
-## v1.2 — Create
-
-- [x] `EventForm`-Domain-Modell + Validierung (`problems()`: EndBeforeStart,
-      NoCalendar; leerer Titel und Instant-Events erlaubt)
-- [x] `EventEditScreen` (ein Formular, ab v1.3 auch für Edit), M3-Date/Time-Picker
-- [x] FAB-Stack auf allen drei Hauptansichten (`CalendarFabColumn`: "+" immer,
-      Heute-Pill darüber), vorbelegt mit dem sichtbaren Tag
-- [x] Kalender-Vorauswahl: explizit > zuletzt benutzt
-      (`CalendarPrefs.lastUsedCalendarId` statt Settings-Eintrag) > erster
-      beschreibbarer; Picker bietet nur beschreibbare Kalender an
-- [x] `insertEvent(form): Long` im DataSource; `EventWriteMapper` (JVM-testbar)
-      normalisiert all-day auf UTC-Mitternächte mit exklusivem DTEND
-
-## v1.3 — Edit
-
-**Domain:**
-- [x] `EventForm.rrule` (roher RRULE-Wert, null = einmalig); komplexe Regeln
-      (ordinales BYDAY wie "2TH", BYMONTHDAY etc.) bleiben verbatim erhalten,
-      solange der Picker sie nicht ersetzt
-- [x] `SimpleRecurrence` (FREQ + INTERVAL + UNTIL/COUNT + wöchentliches
-      BYDAY — Review-Feedback: "jede Woche Mo+Fr" muss gehen) mit
-      `parseSimpleRecurrence`/`toRRule` (Recurrence.kt, JVM-getestet)
-- [x] `EventDetail.toEditForm(begin, end, zone)` — Prefill inkl. all-day-
-      Rückrechnung (exklusives DTEND → letzter abgedeckter Tag)
-- [x] Validierung: `RecurrenceEndsBeforeStart` (UNTIL vor erstem Tag hieße
-      null Vorkommen — Event würde unsichtbar)
-
-**Data layer:**
-- [x] `buildEventUpdateValues(original, updated, seriesDtStart, zone)` —
-      Dirty-Check, nur geänderte Spalten; Zeitfelder als Einheit:
-      einmalig → DTSTART/DTEND (RRULE/DURATION genullt), wiederkehrend →
-      Serien-DTSTART verschiebt sich um das User-Delta, DURATION statt DTEND
-- [x] `CalendarDataSource.updateEvent(eventId, original, updated)` — Events-Row-
-      Update + Reminder-Diff nach Minuten (unberührte Rows behalten ihre Methode)
-- [x] `insertEvent` versteht RRULE (RRULE+DURATION statt DTEND — Provider-Invariante)
-- [x] `CalendarRepository(+Impl).updateEvent` durchgereicht, auf `io`
-- [x] `EventDetailMapper`: Titel bleibt roh (kein "(Ohne Titel)"-Fallback mehr —
-      der Detail-Screen ersetzt selbst lokalisiert, das Formular braucht den Rohwert)
-
-**UI:**
-- [x] `EventEditViewModel.openForEdit` (lädt Detail, merkt Original für
-      Dirty-Check; unverändertes Formular speichert als No-Op); Felder mit
-      Werten werden unabhängig vom Settings-Default eingeblendet
-- [x] `EventEditScreen`: `editKey`-Parameter, Kalender im Edit-Modus fixiert,
-      Repeat-Karte + `RecurrencePickerDialog` (Presets per Tap, Custom-Schritt
-      mit Intervall/Einheit + Wochentags-Toggles bei "Wochen" (Wochenstart
-      nach Locale, Start-Wochentag vorausgewählt) + Ende nie/Datum/Anzahl,
-      OptionCard-Stil)
-- [x] Recurrence-Humanizer nach `ui/common/RecurrenceText.kt` (Detail + Formular)
-- [x] `EventDetailScreen`: Edit-Action (nur `canModify`, kontextueller
-      WRITE-Request wie Delete); Save schließt Formular **und** Detail (die
-      getappte Occurrence existiert danach evtl. nicht mehr)
-- [x] **Occurrence-Edit (aus v2.0 vorgezogen, Review-Feedback):** Die
-      Scope-Frage kommt **beim Speichern** (Google-Modell, Review-Feedback):
-      ein dirty wiederkehrender Termin parkt in `SaveUiState.AwaitingScope`,
-      der Dialog bietet "Nur dieser Termin / Dieser und alle folgenden /
-      Ganze Serie"; bei geänderter Wiederholungsregel entfällt "nur dieser"
-      (eine Exception-Row trägt keine eigene Regel). "Nur dieser" schreibt
-      eine Modified-Occurrence-Exception (`CONTENT_EXCEPTION_URI`, alle
-      Formularwerte, leere Optionals als explizite NULLs weil der Provider
-      die Serien-Row klont), Reminder werden gegen die tatsächlichen
-      Provider-Rows abgeglichen. "Dieser und folgende" = Serien-Split:
-      neues Event mit den Formularwerten (insert zuerst — schlägt es fehl,
-      bleibt das Original unberührt), dann Original-RRULE per UNTIL gekappt;
-      ab der ersten Occurrence = normales Serien-Update. Ein mitgenommenes
-      COUNT zählt in der neuen Serie neu (kein Rest-COUNT-Rechnen wie AOSP)
-- [x] **Delete dreistufig (Review-Feedback):** "Nur dieser Termin" /
-      "Dieser und alle folgenden" (RRULE-Truncation via `rruleTruncatedAt`)
-      / "Alle Termine der Serie"; ab der ersten Occurrence = ganze Serie
-      löschen
-- [x] **Split-Duplikat-Bugfix (On-Device-Review):** Nach dem Serien-Split
-      blieb die getappte Occurrence doppelt sichtbar. Root cause (per
-      adb-Probe verifiziert): der Provider regeneriert die Instances eines
-      Events nur aus den **Values des Updates selbst** — ein RRULE-only-
-      Update lässt die alten Instances stehen, und ein Teilset (nur DTSTART)
-      erzeugt kaputte Nulllängen-Instanzen. Truncation-Updates schicken
-      deshalb das komplette Zeit-Set (DTSTART/DURATION/RRULE/ALL_DAY/
-      EVENT_TIMEZONE) zusammen (`truncateSeries`), wie AOSPs
-      EditEventHelper. Zusätzlich (Robustheit, Google-Modell): Cutoff =
-      Ende des Vortags in der Event-Zeitzone (`previousLocalDayEndUtcMillis`)
-      statt Occurrence−1s, und der Recurrence-Picker rendert UNTIL als
-      lokales Tagesende in UTC (`toRRule(zone)`) statt pauschal `T235959Z`
-      (sonst kann bei UTC+x ein Extra-Tag hineinrutschen)
-- [x] `CalendarHost`: Edit-Overlay mit Held-Key-Pattern
-- [x] `EventFormField.Recurrence` (Formular, "Mehr Felder", Settings-Default)
-- [x] Strings DE+EN
-
-**Tests:**
-- [x] `RecurrenceTest` (Parse/Render/Roundtrip, Ablehnung komplexer Regeln)
-- [x] `EventFormTest`: Prefill (timed/all-day), `populatedFields`, UNTIL-Validierung
-- [x] `EventWriteMapperTest`: Duration-Format, Dirty-Check-Pfade (Text-only,
-      Zeit einmalig/wiederkehrend, Recurrence an/aus, Reminder-only)
-- [x] `CalendarRepositoryImplTest` + `FakeCalendarDataSource`: update-Pfade
-- [x] `EventDetailMapperTest`: roher Titel
-
-Bewusst nicht in v1.3 (→ v2.0): Konflikt-Dialog, Kalender-Wechsel beim
-Bearbeiten (Sync-Adapter-Minenfeld, sperren auch alle Stock-Apps).
-
-## v2.0 — Abschluss (Scope-Recut 2026-06-11, nach v1.4)
-
-- ~~Quick-Add-Sheet (Titel + Zeit, Rest Defaults)~~ — **gestrichen**: das
-  Formular öffnet bereits vorbefüllt (sichtbarer Tag, zuletzt benutzter
-  Kalender, optionale Felder versteckt); der Sheet spart nur einen
-  Screen-Übergang und kostet eine zweite Create-Surface. Nur bei
-  Praxis-Feedback wieder aufnehmen
-- ~~Occurrence-Edit (Exception mit geänderten Werten)~~ — schon in v1.3
-  ausgeliefert (vorgezogen)
-- [x] Konflikt-Dialog beim Speichern (Leitentscheidung 5): `EditSnapshot`
-      (Formular + rohe Row-Zeiten) wird beim Laden gemerkt und vor dem
-      Schreiben gegen einen frischen Read verglichen; Abweichung parkt den
-      Save in `AwaitingConflict` (Überschreiben/Verwerfen/Abbrechen,
-      OptionCard-Stil), gelöschtes Event → `Gone`-Dialog. "Überschreiben"
-      schreibt weiterhin nur dirty Felder
-- Kalender-Wechsel beim Bearbeiten → v3-Backlog (copy+delete-Modell)
-- [x] Polish: F-Droid-Description + README auf Write-Support + Reminder
-      aktualisiert (DE+EN)
-- [x] F-Droid-Screenshots (de-DE + en-US, je 6: Woche/Monat/Tag/Detail/
-      Formular/Onboarding) — mit Demo-Kalendern auf dem Gerät aufgenommen
-- [x] Changelog, Release-Tag v2.0.0 (ausgeliefert 2026-06-11 — Milestone 2
-      damit abgeschlossen)

docs/superpowers/plans/2026-06-11-04-reminder-notifications.md

@@ -1,119 +0,0 @@
-# Calendula - Plan 04: Reminder Notifications (v1.4)
-
-> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
-
-**Goal:** Calendula stellt Erinnerungen selbst als Notification zu (Etar-Modell).
-Der Provider plant die Alarme und broadcastet
-`android.intent.action.EVENT_REMINDER` — die sichtbare Notification postet er
-**nicht**, das muss eine Kalender-App tun. Für Nutzer, deren einzige
-Kalender-App Calendula ist, ist das essenziell, kein Nice-to-have.
-`./gradlew lint test assembleDebug` bleibt grün; Release erst nach
-On-Device-Review.
-
-**Architecture:** Eigenes kleines Datenmodul `data/reminders/` neben
-`data/calendar/` — der Receiver braucht weder Repository noch Flows. Schichtung
-wie gehabt: `EventReminderReceiver` (Hilt-EntryPoint) →
-`ReminderAlertStore` (Interface, Android-Impl auf `CalendarAlerts`) →
-`ReminderNotifier` (NotificationManager). Domain bleibt pure Kotlin
-(`ReminderAlert`-Modell, JVM-testbare Textformatierung).
-
-**Recherche-Befunde (AOSP `CalendarAlarmManager` + Etar, 2026-06-11):**
-
-1. Der Provider legt `CalendarAlerts`-Rows **nur für `METHOD_ALERT`-Reminder**
-   an (AOSP-Query: `AND method=1`). Der im Roadmap-Eintrag geforderte
-   METHOD-Filter (E-Mail überspringen) passiert also schon upstream — wir
-   filtern nicht doppelt. Calendula schreibt eigene Reminder ohnehin als
-   `METHOD_ALERT`.
-2. Der Broadcast ist implizit (Action + `content://com.android.calendar/…`-URI,
-   Extra `alarmTime`). Etars Manifest-Receiver ist `exported="true"` mit
-   `<data android:scheme="content"/>` — das übernehmen wir (plus Host,
-   enger gefasst). Den URI-Inhalt werten wir nicht aus; wir queryen selbst
-   "fällig & noch SCHEDULED".
-3. Etar postet aus dem Zustand `SCHEDULED ∪ FIRED` und verwaltet Dismiss über
-   eigene Services. Wir vereinfachen: nur `STATE_SCHEDULED AND alarmTime <= now`
-   posten, danach best-effort auf `FIRED` setzen (braucht `WRITE_CALENDAR`;
-   `SecurityException` wird geschluckt). Weggewischte Notifications kommen so
-   nie wieder, ohne deleteIntent-Maschinerie: FIRED-Rows fassen wir nicht an.
-   Re-Broadcasts ohne Write-Recht ersetzen still (Tag pro Alert +
-   `setOnlyAlertOnce`).
-
-**Leitentscheidungen:**
-
-1. **Kein eigenes Alarm-Scheduling** (kein `SCHEDULE_EXACT_ALARM`, kein
-   `BOOT_COMPLETED`, kein WorkManager): Zustellung hängt am Provider-Broadcast.
-   Etars Zusatz-Maschinerie (eigener AlarmScheduler) kommt erst, wenn sich
-   Zuverlässigkeit auf echten Geräten als Problem zeigt (Roadmap: bewusst
-   verschoben, ebenso Snooze-/Dismiss-Actions und Battery-Exemption).
-2. **Toggle default ON, Onboarding-Schritt danach:** Nach dem Kalender-Grant
-   folgt ein zweiter Onboarding-Screen (gleiche Shell wie der Permission-
-   Screen): erklärt Reminder, warnt vor Duplikaten (zweite Kalender-App mit
-   aktiven Notifications), fragt `POST_NOTIFICATIONS` an (nur API 33+ zeigt
-   einen Dialog; minSdk 29). "Später" schaltet den Toggle aus. Der Schritt
-   erscheint genau einmal (`reminder_onboarding_done`-Pref) — auch für
-   v1.0–v1.3-Upgrader, die das Feature so entdecken.
-3. **Settings-Spiegel:** Abschnitt "Erinnerungen" mit demselben Toggle +
-   Duplikat-Hinweis. Einschalten fordert `POST_NOTIFICATIONS` kontextuell an,
-   wenn sie fehlt.
-4. **Tap öffnet das Event-Detail:** Notification-Intent trägt
-   eventId/begin/end; `MainActivity` wird `singleTop`, reicht den Key als
-   Compose-State an `CalendarHost` durch (gleiches LongArray-Key-Muster wie
-   der Detail-Overlay selbst).
-5. **Ein Kanal, einfache Inhalte:** Kanal "Erinnerungen"
-   (`IMPORTANCE_HIGH`), pro Alert eine Notification (Tag = Alert-Id):
-   Titel = Eventtitel (Fallback "(Ohne Titel)"), Text = Zeitspanne
-   (ganztägig: Datum, UTC gelesen) + Ort. Kein Grouping/Summary, kein
-   Vollbild-Alarm.
-
----
-
-## Tasks
-
-**Manifest / Resourcen:**
-- [x] `POST_NOTIFICATIONS` ins Manifest; Receiver `.reminders.EventReminderReceiver`
-      `exported="true"`, Intent-Filter `EVENT_REMINDER` + `data scheme=content
-      host=com.android.calendar`; `MainActivity` → `launchMode="singleTop"`
-- [x] Monochromes Notification-Icon `drawable/ic_notification.xml`
-- [x] Strings DE+EN: Kanal, Onboarding-Copy, Settings-Abschnitt + Hinweis
-
-**Prefs:**
-- [x] `SettingsPrefs.remindersEnabled` (default **true**) + Setter;
-      `reminderOnboardingDone` (default false) + Setter; `SettingsPrefsTest`
-
-**Data layer (`data/reminders/`):**
-- [x] `ReminderAlert`-Modell (in `data/reminders/`, nicht domain — Alerts
-      erreichen nie einen Screen): alertId, eventId, begin/end als Millis,
-      title, location, isAllDay
-- [x] `ReminderAlertStore` (Interface) + `AndroidReminderAlertStore`:
-      `dueAlerts(nowMillis)` = `CalendarAlerts` mit
-      `STATE_SCHEDULED AND ALARM_TIME <= now`;
-      `markFired(ids, nowMillis)` setzt STATE/RECEIVED_TIME/NOTIFY_TIME,
-      `SecurityException` → Log (Write-Recht optional)
-- [x] `ReminderNotifier`: Kanal lazy anlegen, eine Notification pro Alert
-      (Tag = alertId, `setOnlyAlertOnce`, autoCancel, `when` = begin,
-      Category EVENT), Content-PendingIntent auf `MainActivity` mit
-      eventId/begin/end
-- [x] Zeitspannen-Text als pure Funktion (JVM-testbar) + Test
-
-**Receiver:**
-- [x] `EventReminderReceiver` (`@AndroidEntryPoint`): Action prüfen,
-      `goAsync()`; raus, wenn Pref aus, READ_CALENDAR fehlt oder
-      Notifications systemseitig geblockt; sonst posten → `markFired`
-
-**UI:**
-- [x] Onboarding-Shell aus `PermissionScreen` extrahieren
-      (`OnboardingScaffold` + BenefitRow, intern wiederverwendet)
-- [x] `NotificationOnboardingScreen` + ViewModel: Benefit-Rows (verpasst
-      nichts / Duplikat-Warnung), Primär-Button fordert `POST_NOTIFICATIONS`
-      (API 33+) und lässt den Toggle an, "Später" schaltet ihn aus; beide
-      setzen `reminder_onboarding_done`
-- [x] `RootScreen`: Kalender-Gate → Reminder-Schritt (einmalig) → `CalendarHost`
-- [x] `CalendarHost`: externer Detail-Key (Notification-Tap) wird wie ein
-      Event-Tap konsumiert; `MainActivity` parst Intent (onCreate +
-      onNewIntent) in Compose-State
-- [x] Settings: Abschnitt "Benachrichtigungen" — Toggle (mit kontextuellem
-      Permission-Request beim Einschalten) + Duplikat-Hinweistext
-
-**Abschluss:**
-- [x] `./gradlew lint test assembleDebug` grün
-- [x] CHANGELOG (`[Unreleased]`), ROADMAP-Status; **kein** Tag/Release vor
-      On-Device-Review

docs/superpowers/plans/2026-06-18-05-ics-export.md

@@ -1,150 +0,0 @@
-# Calendula - Plan 05: ICS Export (v2.7, Branch 1 von 2)
-
-> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
-
-**Goal:** Die Schreib-Hälfte des `.ics`-Themas. Calendula serialisiert eigene
-Events nach RFC 5545 — als Einzel-Event (Share-Sheet) und als
-Ganz-Kalender-Backup (SAF-Datei). Damit existiert für gerätelokale Kalender
-(`ACCOUNT_TYPE_LOCAL`) zum ersten Mal ein Backup; ohne Sync ist ein verlorenes
-Gerät sonst Totalverlust. Diese Branch baut **nur Export**; Import
-(Parser, Restore, Open-into-form) folgt in Branch 2 (`feat/ics-import`),
-beide landen zusammen in **einem** Release v2.7.0 — es gibt also keine
-Zwischenversion, die UIDs schreibt, ohne sie je zu lesen.
-`./gradlew lint test assembleDebug` bleibt grün; Release erst nach
-On-Device-Review (gemeinsam mit Branch 2).
-
-**Architecture:** Neue reine-Kotlin-Engine `domain/ics/` — kein
-`CalendarContract`, keine Android-Deps, voll JVM-testbar. Kern ist
-`IcsWriter` (nimmt eine Liste eigener Event-Modelle + Kalender-Metadaten,
-gibt einen `VCALENDAR`-String zurück). Keine ICS-Library: wir bleiben auf
-`kotlinx-datetime` (kein `java.time`-Desugaring) und hand-rollen wie schon
-bei RRULE in `Recurrence.kt`. Das Schreiben in eine SAF-Datei / das
-Share-Intent liegt in einer dünnen Android-Schicht
-(`data/ics/IcsExporter` o. ä.), die Provider-Reads → Domain-Modelle →
-`IcsWriter` → `OutputStream` verdrahtet.
-
-**Recherche-Befunde (Codebase, 2026-06-18):**
-
-1. **Keine ICS-Library, kein `java.time`-Desugaring** — Stack ist
-   `kotlinx-datetime` + `kotlin.time.Instant`. RRULE wird bereits in
-   `domain/Recurrence.kt` von Hand geparst/gerendert (inkl. der sorgfältigen
-   `UNTIL`/DST-Korrektur). `IcsWriter` reiht sich in genau diese Kultur ein und
-   nutzt `SimpleRecurrence.toRRule()` direkt.
-2. **Kein UID-Handling.** `Events.UID_2445` wird heute nirgends gelesen oder
-   geschrieben. Für idempotenten Restore in Branch 2 muss Import auf UID
-   matchen — ohne UID verdoppelt ein erneuter Import alles. Darum schreibt
-   **diese** Branch bereits UID bei jedem Insert (Vorarbeit; ohne Import noch
-   unsichtbar, zahlt sich erst in Branch 2 aus — beide im selben Release).
-3. **Zeitzonen werden gespeichert, aber nie vom Nutzer gewählt.** Lesen/Anzeige:
-   `EVENT_TIMEZONE` landet in `EventDetail.eventTimezone`, das Detail zeigt ein
-   Fremdzonen-Label nur bei Abweichung vom Gerät (`foreignTimeZoneLabel`).
-   Schreiben (`EventWriteMapper.toWriteTimes`): all-day → UTC-Mitternachten,
-   `EVENT_TIMEZONE="UTC"`; getimt → `EVENT_TIMEZONE = zone.id`, und alle Caller
-   übergeben `currentSystemDefault()` (kein Zonen-Feld im Formular). Jedes selbst
-   erstellte Event trägt also die Gerätezone zum Erstellzeitpunkt; eingesynkte
-   Events behalten ihre Originalzone.
-
-**Leitentscheidungen:**
-
-1. **Zeitzonen-Regel beim Schreiben (fallbasiert):**
-   - **All-day** → `DTSTART;VALUE=DATE:YYYYMMDD`, `DTEND` exklusiv
-     (Tag-danach). Keine Zone — trivial korrekt.
-   - **Getimt, nicht wiederkehrend** → UTC-Instant `…T…Z`. Ein Instant ist ein
-     Instant; die Anzeige rechnet beim Import wieder in die Gerätezone. Verlustfrei.
-   - **Getimt, wiederkehrend** → `DTSTART;TZID=<EVENT_TIMEZONE>:<lokale Wandzeit>`.
-     Eine Serie muss an der **Wandzeit** verankert sein, sonst driftet ein
-     „wöchentlich 9 Uhr" über die nächste DST-Grenze um eine Stunde. Die Zone
-     liegt bereits in `EVENT_TIMEZONE` vor; die lokale Wandzeit ist eine
-     `kotlinx-datetime`-Konversion (Instant → LocalDateTime in der Zone).
-   - **`VTIMEZONE`-Blöcke werden bewusst NICHT emittiert.** Beim eigenen
-     Round-Trip löst Branch-2-Import `TZID` gegen die OS-tz-Datenbank auf
-     (`kotlinx-datetime`/`java.time` kennen jede IANA-Id). Technisch nicht
-     RFC-konform; einziger Preis sind strenge Fremd-Parser ohne tz-DB — als
-     bekannte Lücke dokumentiert (Skip-and-report-Territorium des Imports),
-     kein Blocker. Voll-`VTIMEZONE` ist „später, falls nötig".
-2. **UID bei jedem Insert.** `insertEvent` schreibt fortan `Events.UID_2445`
-   (z. B. `<random-uuid>@calendula`). Bestehende Events ohne UID exportieren
-   wir mit einer **deterministischen, stabilen** Fallback-UID, abgeleitet aus
-   `event-id + DTSTART` (`<id>-<dtstart>@calendula`), damit derselbe Bestand
-   über mehrere Backups dieselbe UID behält und Branch-2-Restore nicht
-   verdoppelt. Bestehende Rows werden **nicht** rückwirkend gestempelt
-   (kein Migrations-Sweep über fremde Kalender).
-3. **Manueller Export, kein Background.** Backup via
-   `ACTION_CREATE_DOCUMENT` (SAF, MIME `text/calendar`, Default-Name
-   `calendula-backup-<datum>.ics`); Einzel-Event-Share via `ACTION_SEND` mit
-   einem `FileProvider`-Cache-File (`text/calendar`). Kein WorkManager, kein
-   geplantes/automatisches Backup (passt zum „kein Hintergrunddienst"-Ethos;
-   Auto-Backup bleibt explizit Roadmap-`later`).
-4. **Backup-Layout: eine kombinierte `VCALENDAR`-Datei** über alle
-   gerätelokalen (beschreibbaren) Kalender. Pro Event ein `VEVENT`; die
-   Kalender-Zugehörigkeit reist als `X-WR-CALNAME` / `CATEGORIES` o. ä. mit,
-   damit Branch-2-Restore wieder auffächern oder per Ziel-Picker einsortieren
-   kann. Eine Datei ist einfacher zu teilen/abzulegen als n Dateien.
-   *Offen, vor dem Backup-Task zu fixieren:* exaktes Property fürs
-   Kalender-Mapping (`X-WR-CALNAME` pro `VCALENDAR` erlaubt nur einen Namen;
-   für mehrere Kalender in einer Datei brauchen wir ein Pro-`VEVENT`-Property
-   wie `X-CALENDULA-CALENDAR` oder `CATEGORIES`).
-5. **Feldumfang = was Calendula modelliert.** `IcsWriter` serialisiert genau
-   die gelesenen Felder: `SUMMARY`, `DTSTART`/`DTEND` (Regel #1),
-   `LOCATION`, `DESCRIPTION`, `RRULE` (über `toRRule`), `VALARM` aus den
-   Remindern (DISPLAY, `TRIGGER` = `-PT<min>M`), `STATUS`
-   (CONFIRMED/TENTATIVE/CANCELLED), `TRANSP` (Free→TRANSPARENT/Busy→OPAQUE),
-   `UID`, `DTSTAMP`. Felder ohne sauberes Modell (Attendees, RECURRENCE-ID-
-   Ausnahmen) bleiben **vorerst weg** — Export erzeugt nichts, was Import in
-   Branch 2 nicht auch wieder lesen kann.
-6. **Korrekte RFC-5545-Mechanik:** Zeilen-Folding bei >75 Oktett (CRLF +
-   Space-Fortsetzung), Text-Escaping (`\` `;` `,` `\n`), CRLF-Zeilenenden,
-   `PRODID`/`VERSION:2.0`-Header. Eine reine, einzeln getestete Hilfsschicht
-   (`IcsLine`/`fold`/`escapeText`), nicht ad hoc im Writer verstreut.
-
----
-
-## Tasks
-
-**Domain-Engine (`domain/ics/`, reine Kotlin, JVM-Tests):**
-- [x] `IcsText`: `escapeText`, `foldLine` (75-Oktett, CRLF+Space) + Test
-      (`IcsTextTest`). Wert-Helfer (Instant→`…T…Z`, Wandzeit→`TZID`,
-      LocalDate→`VALUE=DATE`) leben als private Helfer in `IcsWriter`.
-- [x] `IcsEvent`-Eingabemodell (reine Kotlin: summary, start/end als Instant
-      + isAllDay + zoneId, recurrenceRule?, location, description,
-      reminderMinutes, status, availability, uid, calendarName) — entkoppelt
-      vom Provider-Modell
-- [x] `IcsWriter.writeCalendar(events, dtStamp)` → String: Header, pro Event
-      `VEVENT` nach Entscheidung #5, Zeitzonen-Regel #1, `VALARM`; JVM-Test
-      `IcsWriterTest` (all-day, getimt, wiederkehrend+TZID, unbekannte Zone,
-      Reminder, Escaping)
-- [x] UID-Ableitung `deriveIcsUid` (`uid ?: "<eventId>-<dtstartMillis>@calendula"`)
-      + Stabilitätstest
-
-**Provider → Domain (`data/calendar/IcsExportMapper.kt`):**
-- [x] Mapper Provider-Row → `IcsEvent` (`ColumnReader.toIcsEvent`) inkl.
-      DURATION→DTEND-Rekonstruktion (`parseRfc2445DurationMillis`),
-      `EventExportProjection`; Datasource-Methode `exportableEvents()` +
-      Repository `exportEvents()`; Test `IcsExportMapperTest`
-- [x] `insertEvent` schreibt `Events.UID_2445` (`UUID@calendula`) bei jedem
-      Create
-
-**Android-Export-Schicht:**
-- [x] `data/ics/IcsExporter`: `writeDocument(uri)` (SAF) + `stageShareFile`
-      (FileProvider-Cache) als UTF-8
-- [x] Einzel-Event-Share: Share-Action im Event-Detail → `IcsWriter` für ein
-      Event (one-off) → Cache-File über `FileProvider` → `ACTION_SEND`
-- [x] Ganz-Kalender-Backup: „Export as .ics file" in Settings → Calendars →
-      `ACTION_CREATE_DOCUMENT` → in den URI streamen; Ergebnis-Snackbar
-      (Plural „Exported N events")
-- [x] `FileProvider` + `file_paths.xml` im Manifest (Cache-Dir für Shares)
-- [x] Strings DE+EN: Share-Label/Chooser/Fehler, Backup-Sektion/Aktion/
-      Fehler + Plural, dateierter Default-Name
-
-**Abschluss:**
-- [ ] `./gradlew lint test assembleDebug` grün ← **nächster Schritt (Test)**
-- [x] CHANGELOG (`[Unreleased]`) ergänzt
-- [ ] On-Device-Review; **kein** Tag/Release vor Review und vor Merge von
-      Branch 2 (`feat/ics-import`)
-
-**Offene Detail-Calls (vor Review klären, nicht-blockierend):**
-- Kalender→Event-Mapping nutzt das per-`VEVENT`-Property `X-CALENDULA-CALENDAR`
-  (statt `X-WR-CALNAME`), damit eine kombinierte Datei mehrere Kalender trägt.
-- Backup = **eine** kombinierte `VCALENDAR`-Datei über alle lokalen Kalender.
-- EXDATE / `RECURRENCE-ID`-Ausnahmen werden beim Export ausgelassen
-  (`ORIGINAL_ID IS NULL`) — dokumentierter v1-Grenzfall, Import lässt sie auch aus.

docs/superpowers/plans/2026-06-18-06-ics-import.md

@@ -1,122 +0,0 @@
-# Calendula - Plan 06: ICS Import (v2.7, Branch 2 von 2)
-
-> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
-
-**Goal:** Die Lese-Hälfte des `.ics`-Themas, aufgesetzt auf den Writer aus
-Branch 1 (`feat/ics-export`, gemerged in `release/v2.7.0`). Calendula parst
-RFC-5545-Dateien und führt sie über zwei Wege ein: eine einzelne `VEVENT` öffnet
-das vorausgefüllte Erstellen-Formular (Review vor dem Speichern), eine Datei mit
-vielen Events geht in einen Bulk-Import mit Ziel-Kalender-Auswahl und
-Ergebnis-Report. Damit schließt sich der Backup→Restore-Kreis für lokale
-Kalender. Beide Branches landen in **einem** Release v2.7.0.
-`./gradlew lint test assembleDebug` bleibt grün; Release erst nach
-On-Device-Review.
-
-**Architecture:** `IcsParser` lebt rein in `domain/ics/` neben `IcsWriter` —
-kein Android, JVM-testbar, symmetrisch zum Writer. Ausgabe ist ein
-`IcsParseResult` (`events: List<ParsedIcsEvent>` + `warnings: List<String>`).
-`ParsedIcsEvent` ist die Parse-Variante von `IcsEvent` (gleiche Felder, aber
-`uid: String?` — eine eingelesene `VEVENT` kann ohne UID kommen). Zwei Adapter:
-`ParsedIcsEvent.toEventForm(zone)` (Einzel-Öffnen → `EventForm`) und eine
-Repository-Methode `importEvents(targetCalendarId, events)` → `ImportSummary`
-(Bulk). Datei-IO (`Uri` lesen, Intent) liegt in `data/ics/` bzw. der
-Activity/Compose-Schicht; Routing 1-vs-viele entscheidet anhand der geparsten
-Event-Anzahl.
-
-**Liberal-in/strict-out (Leitprinzip):** unbekannte Properties, fremde
-`VTIMEZONE`-Blöcke und `RECURRENCE-ID`-Ausnahmen werden **übersprungen und im
-Report vermerkt**, nie still verschluckt; ein einzelnes kaputtes `VEVENT` lässt
-den Rest der Datei durch.
-
-**Leitentscheidungen:**
-
-1. **Parse-Mechanik (Umkehr von `IcsText`):** zuerst **Unfolding** (CRLF +
-   Space/Tab → wegfalten), dann pro Zeile `NAME[;params]:value` zerlegen,
-   TEXT-Werte **unescapen** (`\\` `\;` `\,` `\n`). Eine reine, einzeln getestete
-   Schicht (`IcsLineParser`), nicht ad hoc im Walker.
-2. **Datum/Zeit-Parsing (Umkehr der Writer-Zeitzonenregel):**
-   - `VALUE=DATE` (`YYYYMMDD`) → all-day, Instant auf UTC-Mitternacht (wie der
-     Provider all-day speichert), exklusives `DTEND` bleibt exklusiv.
-   - `…T…Z` → UTC-Instant.
-   - `…T…` mit `TZID=<zone>` → lokale Wandzeit in der Zone, aufgelöst gegen die
-     **OS-tz-Datenbank** (`TimeZone.of`); unbekannte/fehlende `TZID` →
-     Gerätezone als Fallback (+ Warnung).
-   - Kein `VTIMEZONE`-Parsing — `TZID` wird gegen die OS-DB aufgelöst (s. Branch-1
-     Entscheidung); ein `VTIMEZONE`-Block wird übersprungen (Warnung nur, wenn
-     seine `TZID` nicht in der OS-DB ist).
-3. **Routing 1-vs-viele:** genau **eine** `VEVENT` → vorausgefülltes
-   Erstellen-Formular (`ParsedIcsEvent.toEventForm`, `calendarId=null` →
-   Formular wählt wie gehabt den zuletzt genutzten Kalender vor). **Mehr als
-   eine** → Bulk-Import-Screen (Ziel-Kalender-Picker, nur beschreibbare). Leere
-   Datei → freundlicher „nichts gefunden"-Hinweis.
-4. **UID-Dedup beim Bulk-Import:** vor dem Insert die vorhandenen
-   `Events.UID_2445` des Ziel-Kalenders lesen; eine eingelesene UID, die schon
-   existiert, wird **übersprungen** (gezählt als „bereits vorhanden"). v1:
-   skip-not-update — kein Überschreiben, das hält den Restore idempotent und
-   verlustfrei. Events ohne UID bekommen beim Insert eine frische
-   (`UUID@calendula`, wie `insertEvent`).
-5. **Empfang via Intent:** Manifest-`ACTION_VIEW`/`SEND` mit MIME `text/calendar`
-   (+ `.ics`-Pfadmuster für `file`/`content`-Schemes). `MainActivity`
-   (`singleTop`, wie beim Reminder-Tap) liest den `Uri`, parst, und reicht das
-   Ergebnis als Compose-State an `CalendarHost` (gleiches Key-Muster wie der
-   Notification-Deep-Link).
-6. **Reminder/Status/Transp zurück:** `VALARM` `TRIGGER` (negatives `-PT…`,
-   `PT0…`) → Lead-Minuten; `STATUS`/`TRANSP` → `EventStatus`/`Availability`.
-   `DURATION`-statt-`DTEND` über `parseRfc2445DurationMillis` (existiert aus
-   Branch 1). Attendees werden **nicht** importiert (kein Modell; Warnung wenn
-   vorhanden).
-
-**Recherche-Befunde (Codebase, 2026-06-18 — aus Branch 1):**
-- `IcsText.escapeText`/`foldLine` + `IcsWriter` existieren; Parser spiegelt sie.
-- `parseRfc2445DurationMillis` (in `IcsExportMapper.kt`) parst die
-  Provider-`DURATION`-Formen inkl. des nicht-standardkonformen `P<n>S`.
-- `EventForm` (Domain): Zeiten als `LocalDateTime` in Gerätezone, `calendarId`
-  nullable; das Formular wählt bei `null` den zuletzt genutzten Kalender vor.
-- `insertEvent` schreibt bereits `Events.UID_2445`; für den Import muss eine
-  **vorgegebene** UID durchgereicht werden (Insert-Variante / Parameter).
-
----
-
-## Tasks
-
-**Parser-Engine (`domain/ics/`, reine Kotlin, JVM-Tests):**
-- [x] `IcsText`: `unescapeText` + `unfold(lines)` ergänzen (+ Test)
-- [x] `IcsLineParser`: `NAME;PARAM=v;PARAM=v:VALUE` → (name, params-map, value);
-      Param-Werte ggf. in Quotes; Test (Kantenfälle: Doppelpunkt im Wert,
-      gequotete Params)
-- [x] `ParsedIcsEvent` (wie `IcsEvent`, aber `uid: String?`) + Datum/Zeit-Parser
-      (`VALUE=DATE` / `…Z` / `TZID` → Instant + isAllDay + zoneId)
-- [x] `IcsParser.parse(text)` → `IcsParseResult(events, warnings)`: VCALENDAR/
-      VEVENT-Walk, skip-and-report für `RECURRENCE-ID`/unbekannte `VTIMEZONE`/
-      Attendees; ein defektes VEVENT killt nicht den Rest. **Round-trip-Test**
-      gegen `IcsWriter`-Ausgabe (all-day, getimt, wiederkehrend+TZID, Reminder)
-      + Fremd-Quirks (gefaltete Zeilen, fehlende UID, `PT…`-Trigger)
-
-**Datenschicht (`data/calendar/` + `data/ics/`):**
-- [x] `ParsedIcsEvent.toEventForm(zone)` (Einzel-Öffnen → `EventForm`); Test
-- [x] Datasource: `existingUids(calendarId)` (Query `Events.UID_2445`) +
-      `insertImported(event, calendarId)` (Insert mit vorgegebener/erzeugter UID)
-- [x] Repository `importEvents(targetCalendarId, events)` → `ImportSummary`
-      (imported / skippedDuplicate / skippedUnsupported); UID-Dedup; Test mit
-      Fake-Datasource
-- [x] `IcsImporter` (`data/ics/`): `Uri` → Text lesen (UTF-8, `contentResolver`)
-
-**Intent + Routing:**
-- [x] Manifest: `ACTION_VIEW`/`ACTION_SEND`, MIME `text/calendar`, `.ics`-
-      Pfadmuster (`file`/`content`); `MainActivity` parst eingehenden `Uri`
-- [x] Routing in `CalendarHost`: 1 Event → Erstellen-Formular vorausgefüllt;
-      >1 → Bulk-Import-Screen; 0 → Hinweis
-
-**UI:**
-- [x] Bulk-Import-Screen: Ziel-Kalender-Picker (OptionCard, nur beschreibbare),
-      Anzahl/Vorschau, Import-Button → `ImportSummary` als Ergebnis
-- [x] Einzel-Öffnen: `EventEditScreen` mit vorausgefülltem Formular (neuer
-      Prefill-Pfad im `EventEditViewModel`, ohne `eventId`)
-- [x] Strings DE+EN: Import-Titel, Ziel-Auswahl, Ergebnis-Plurals
-      (importiert / übersprungen-vorhanden / übersprungen-nicht-unterstützt),
-      leere-Datei-Hinweis
-
-**Abschluss:**
-- [x] `./gradlew lint test assembleDebug` grün
-- [ ] CHANGELOG done; ROADMAP/STATE pending; v2.7 cut **erst** wenn beide
-      Branches gemerged sind und On-Device-Review durch ist

docs/superpowers/specs/2026-06-08-calendar-app-design.md

@@ -1,406 +0,0 @@
-# Calendula - V1 Design Spec
-
-**Date:** 2026-06-08
-**Status:** Draft for review
-**Author:** Jean-Luc Makiola (with Claude)
-
-## 1. Motivation & Goal
-
-Eine Android-native, Open-Source-Kalender-App im Material 3 Expressive Design.
-Schließt die Lücke, dass es derzeit keinen optisch zeitgemäßen Kalender abseits
-von Google Calendar gibt - speziell mit dem 2025er Expressive-Design.
-
-**Was die App NICHT macht:**
-- Eigene CalDAV/iCal-Synchronisation - das übernimmt der Android `CalendarContract`
-  bzw. Drittsoftware wie DAVx5
-- Eigene lokale Event-DB - alle Daten leben im `CalendarContract`
-
-**Was die App macht:**
-- Schöne, moderne UI über Android-Bordmittel
-- Liest aus `CalendarContract` (alle Quellen: Nextcloud/CalDAV via DAVx5,
-  Google, lokal, WebCal-Subscriptions)
-- V1 ist read-only; Schreibrechte kommen in V2
-
-## 2. Scope - V1 MVP (Variante "B")
-
-### In-Scope
-- 3 Hauptansichten: Monat, Woche, Tag
-- Event-Detail-Sheet (read-only Detailansicht)
-- Multi-Kalender-Toggle (Sichtbarkeit pro Kalender)
-- Heute-Button (Jump-to-Date gestrichen, siehe Out-of-Scope)
-- Settings-Screen (Theme, Dynamic Color, Wochenstart, Sprache)
-- Permission-Flow für `READ_CALENDAR`
-- Empty-States und Error-Recovery
-- DE + EN Lokalisierung
-- Tests + CI ab Tag 1
-
-### Out-of-Scope (V2+)
-- Jump-to-Date / Datum-Picker (aus V1-Scope gestrichen)
-- Event-Create/Edit/Delete (V2)
-- Home-Screen-Widget
-- Volltextsuche
-- Quick-Add
-- Notifications/Reminders (System macht das schon, nicht doppeln)
-- Tablet-/Foldable-spezifische Layouts
-- iOS (Kotlin-Native ist explizit Android-only)
-
-## 3. Tech Stack
-
-| Layer | Wahl | Begründung |
-|---|---|---|
-| Sprache | Kotlin 2.0+ | Android-Native-Standard |
-| UI | Jetpack Compose + Material3 Expressive (1.5+) | Echter M3 Expressive Support |
-| Min SDK | 29 (Android 10) | Modern, keine Compat-Pfade |
-| Target SDK | 36 (Android 16) | Aktuell, wie HouseHoldKeaper CI |
-| DI | Hilt | Industriestandard |
-| Persistenz Prefs | DataStore (Preferences) | Theme, Wochenstart, Filter-State |
-| Persistenz Daten | keine | Source of Truth bleibt `CalendarContract` |
-| Datum/Zeit | `kotlinx.datetime` (Domain), `java.time` an Provider-Grenze | Saubere API |
-| Navigation | Compose Navigation, Single-Activity | Standard |
-| Lokalisierung | Android Resources (`strings.xml`) + Plurals | DE + EN ab V1 |
-| Tests | JUnit5, Truth, Turbine, Compose UI Test | JVM-first, Instrumented nur für ContentResolver-Integration |
-| Build | Gradle Kotlin DSL + Version Catalog | Lesbar, typsicher |
-| CI | Gitea Workflows (adaptiert von HouseHoldKeaper) | Gleiche Konvention wie restliche Projekte |
-
-### Permissions
-- `READ_CALENDAR` (einzige Runtime-Permission)
-- `android.permission.QUERY_ALL_PACKAGES` **nicht** nötig (Maps-Intent geht ohne)
-
-### App-Identifier
-- **App-Name:** Calendula (vom lateinischen *kalendae* - "der erste Tag des Monats", Wortwurzel von "Kalender"; gleichzeitig der Name der Ringelblume)
-- **Package:** `de.jeanlucmakiola.calendula`
-- Convention identisch zu `HouseHoldKeaper`: `de.jeanlucmakiola.<app_name>`
-
-## 4. Architektur
-
-### Modul-Struktur
-Single Gradle module `:app` für V1. Feature-Split (`:core`, `:feature-*`) erst
-wenn nötig - YAGNI.
-
-### Package-Layout
-```
-de.jeanlucmakiola.calendula/
-├── CalendulaApp.kt + MainActivity.kt
-├── data/          ContentResolver-Wrapper, Repositories
-├── domain/        Pure-Kotlin Models (Event, CalendarSource)
-└── ui/
-    ├── theme/     M3 Expressive Theme, Dynamic Color
-    ├── month/     Monatsansicht (Composable + ViewModel + State)
-    ├── week/      Wochenansicht
-    ├── day/       Tagesansicht
-    ├── detail/    Event-Detail-Sheet
-    ├── filter/    Kalender-Filter-Sheet
-    ├── settings/  Settings-Screen
-    ├── permission/ Permission-Request-Screen
-    └── common/    Geteilte Composables (LoadingScreen-Helper, FailureScreen-Helper)
-```
-
-### Layer-Verantwortlichkeiten
-- **data/**: Nur Layer der Android-Klassen kennt (`ContentResolver`, `Cursor`,
-  `CalendarContract`). Mapped auf Domain-Modelle.
-- **domain/**: Pure Kotlin. Keine Android-Imports.
-- **ui/**: Compose-Code, ViewModels. Hängt von domain ab, niemals direkt an data.
-
-## 5. Datenfluss & Domain-Modell
-
-### Domain-Modelle (pure Kotlin)
-
-```kotlin
-data class CalendarSource(
-    val id: Long,
-    val displayName: String,
-    val accountName: String,    // z.B. "jlmak@nextcloud.example.com"
-    val accountType: String,    // z.B. "at.bitfire.davdroid" (DAVx5), "com.google" (Google), "LOCAL"
-    val color: Int,
-    val isVisibleInSystem: Boolean,  // CalendarContract.Calendars.VISIBLE
-)
-
-data class EventInstance(
-    val instanceId: Long,        // Instances._ID (eindeutig pro Vorkommen)
-    val eventId: Long,           // Events._ID (gleich für alle Vorkommen)
-    val calendarId: Long,
-    val title: String,
-    val start: Instant,
-    val end: Instant,
-    val isAllDay: Boolean,
-    val color: Int,              // Effektiv: Event.color ?: Calendar.color
-    val location: String?,
-)
-
-data class EventDetail(
-    val instance: EventInstance,
-    val description: String?,
-    val organizer: String?,
-    val attendees: List<Attendee>,
-    val rrule: String?,          // Read-only: nur "wiederkehrt wöchentlich" anzeigen
-)
-
-data class Attendee(val name: String, val email: String?, val status: AttendeeStatus)
-enum class AttendeeStatus { Accepted, Declined, Tentative, NeedsAction, Unknown }
-```
-
-### Repository
-
-```kotlin
-interface CalendarRepository {
-    fun calendars(): Flow<List<CalendarSource>>
-    fun instances(range: ClosedRange<Instant>): Flow<List<EventInstance>>
-    suspend fun eventDetail(eventId: Long): EventDetail
-}
-```
-
-**Implementation-Details:**
-- Hält `ContentObserver` auf `CalendarContract.CONTENT_URI` registriert
-- Bei Observer-Trigger: re-query, emit neuer Wert via SharedFlow
-- Queries laufen auf `Dispatchers.IO`
-- `instances(range)` nutzt `CalendarContract.Instances.CONTENT_BY_DAY_URI`
-  oder `CONTENT_URI` mit Time-Range - Recurrence-Expansion macht der Provider
-- App-eigene "ausgeblendete Kalender-IDs" leben in DataStore als `Set<Long>`,
-  kombinieren via `combine()` mit Calendar-Flow
-
-### ViewModel-Pattern
-
-Ein ViewModel pro Top-Level-Screen. State immer als sealed interface
-(siehe Section 7 - Loading/Failure/Success).
-
-ViewModel kennt aktuelle "Cursor"-Position (welcher Monat/Woche/Tag) und
-fragt Repository nur für sichtbaren Range an - kein "alle Events der Welt".
-
-## 6. Screens & Menüs
-
-### Hauptscreens
-
-**S1 - Monatsansicht**
-- Zeigt einen Monat im Überblick
-- Pro Tag erkennbar: hat-Events / keine-Events, ggf. Andeutung über Anzahl/Farbe
-- Navigation: vorwärts/zurück zwischen Monaten
-- Tap auf Tag → Tagesansicht für diesen Tag
-- Heute deutlich markiert
-
-**S2 - Wochenansicht**
-- Zeigt eine Woche mit Zeitschiene
-- Events auf ihrer Uhrzeit, Calendar-Farbe
-- Overlap-Events: nebeneinander aufgelöst
-- All-Day-Events extra dargestellt
-- Navigation: vorwärts/zurück zwischen Wochen
-- Tap Event → Event-Detail-Sheet
-
-**S3 - Tagesansicht**
-- Eine Spalte, mehr Detail pro Event als Wochenansicht
-- All-Day-Events extra
-- Navigation: vorwärts/zurück zwischen Tagen
-- Tap Event → Event-Detail-Sheet
-
-**S4 - Event-Detail-Sheet (Bottom-Sheet, ModalBottomSheet)**
-- Pflicht-Inhalte: Titel, Start/Ende oder "Ganztägig", Kalender-Zugehörigkeit
-- Konditional: Ort (Tap → Maps-Intent), Beschreibung, Teilnehmer, RRULE-Hinweis
-- Dismissable via Drag oder Back-Geste
-
-### Menüs
-
-**M1 - View-Switcher**
-- Wechsel zwischen Monat / Woche / Tag
-- Immer erreichbar von allen Hauptansichten
-- State persistent (zuletzt aktive Ansicht)
-
-**M2 - Heute**
-- Schnell zurück zu "heute" (Drawer-Eintrag, ausgeliefert in v0.5)
-- ~~Springe zu beliebigem Datum via Datum-Picker~~ — **gestrichen**, siehe Out-of-Scope
-- Erreichbar von allen Hauptansichten
-
-**M3 - Kalender-Filter (Bottom-Sheet)**
-- Sichtbare Kalender ein-/ausblenden
-- Gruppiert pro Account (Nextcloud / Local / Google / …)
-- Pro Eintrag: Name, Calendar-Farbe
-- Persistiert in DataStore
-- Erreichbar von allen Hauptansichten
-
-**M4 - Settings**
-- Theme: System / Light / Dark
-- Dynamic Color: an/aus (auto disabled wenn API < 31)
-- Wochenstart: Auto (aus Locale) / Mo / So
-- Sprache: Auto / DE / EN
-- About: Version, Lizenz, Link zum Quellcode (Gitea)
-
-### Spezial-Flows
-
-**F1 - Erst-Start / Permission-Flow**
-- Beim ersten App-Start: `READ_CALENDAR`-Request
-- Erklärungs-Text: "Wir lesen nur deinen Gerätekalender - keine Daten verlassen das Gerät"
-- Bei Denial: friendlicher Recovery-Screen mit Re-Request-Button + Link zu System-Settings
-
-**F2 - Empty-State (keine Kalender / keine Events)**
-- Keine Kalender konfiguriert: Hinweis "Füge in DAVx5 oder System-Settings einen Kalender hinzu" mit Intent-Link zu System-Calendar-Settings
-- Kalender da, aber aktuelle Ansicht leer: dezent, kein nerviger Placeholder
-
-**F3 - Reaktion auf externe Änderungen**
-- DAVx5/System-Calendar ändert sich → App aktualisiert sich automatisch via ContentObserver
-- Kein manueller Pull-to-Refresh
-
-## 7. UI-State-Modell: Loading / Failure / Success
-
-**Pflicht-Pattern für jeden Screen.** Keine Ausnahmen.
-
-### ViewModel-State
-
-```kotlin
-sealed interface MonthUiState {
-    data object Loading : MonthUiState
-    data class Failure(val reason: FailureReason) : MonthUiState
-    data class Success(
-        val month: YearMonth,
-        val eventsPerDay: Map<LocalDate, List<EventInstance>>,
-        val visibleCalendars: List<CalendarSource>,
-    ) : MonthUiState
-}
-
-enum class FailureReason {
-    PermissionRevoked,        // → Re-Request-Screen
-    NoCalendarsConfigured,    // → Empty-State mit Intent zu System-Settings
-    ProviderUnavailable,      // → Retry-Screen
-    EventNotFound,            // → nur für Event-Detail-Sheet
-    Unknown,                  // → Fallback
-}
-```
-
-### Composable-Dispatch
-
-```kotlin
-@Composable
-fun MonthScreen(viewModel: MonthViewModel) {
-    val state by viewModel.state.collectAsStateWithLifecycle()
-    when (val s = state) {
-        is MonthUiState.Loading -> MonthLoadingScreen()
-        is MonthUiState.Failure -> MonthFailureScreen(s.reason, onRetry = viewModel::retry)
-        is MonthUiState.Success -> MonthSuccessScreen(s, ...)
-    }
-}
-```
-
-### Pflicht-Composables pro Screen
-
-| Screen | Loading | Failure-Varianten | Success |
-|---|---|---|---|
-| Monat | Skelett-Grid (Shimmer) | Permission, NoCalendars, Provider | Grid mit Events |
-| Woche | Skelett-Schiene | Permission, NoCalendars, Provider | Schiene mit Events |
-| Tag | Skelett-Schiene | Permission, NoCalendars, Provider | Schiene mit Events |
-| Event-Detail | kompakter Skelett-Sheet | EventNotFound, Provider | Voll-Detail |
-| Kalender-Filter | Skelett-Liste | Provider | Liste |
-| Settings | sofort (DataStore ist instant) | - | direkt |
-
-**Regeln:**
-- Loading ist ein bewusst gestalteter Screen (Skeleton + Shimmer), kein loser Spinner
-- Failure ist ein eigener Screen mit Erklärung + Recovery-Action, kein Toast
-- Beim UI-Design später: alle drei Varianten pro Screen skizzieren, nie nur Success
-- Tests: pro Screen mindestens `renders_loading`, `renders_failure`, `renders_success`
-
-## 8. Error Handling & Edge Cases
-
-### Philosophie
-Calendar-Apps dürfen niemals an leeren/malformen Daten crashen. Defensive
-Validierung im Repository, kaputte Instanzen still droppen + via `Log.w` loggen.
-
-### Konkrete Fehlerfälle
-| Fall | Verhalten |
-|---|---|
-| ContentResolver-Query wirft (Permission revoked zur Laufzeit) | State → `Failure(PermissionRevoked)`, UI zeigt Re-Request |
-| Calendar `displayName` null | Fallback "(Unbenannter Kalender)" |
-| Event `title` null/leer | Fallback "(Ohne Titel)" |
-| `dtend < dtstart` | Event droppen, Warn-Log |
-| `dtstart` vor Unix-Epoch | Event droppen, Warn-Log |
-| Maps-Intent fehlt | SnackBar "Keine Karten-App installiert" |
-| DataStore-IO-Fehler | Defaults verwenden, weiter, Warn-Log |
-
-### Edge Cases im UI
-- **All-Day-Events über mehrere Tage:** in Wochen-/Tagesansicht über mehrere
-  Tage gespannter All-Day-Strip
-- **Events über Mitternacht:** in Wochen-/Tagesansicht am Folgetag fortsetzen
-- **Instant Events (start == end):** Mindesthöhe rendern für Tap-Target
-- **Viele Events an einem Tag:** in Monatsansicht "+N more" statt Overflow
-- **Timezones:** alle Berechnungen in Geräte-Local-TZ, außer all-day = floating
-
-## 9. i18n & Accessibility
-
-### i18n
-- `res/values/strings.xml` = englische Master-Strings
-- `res/values-de/strings.xml` = deutsche Übersetzungen
-- Alle Strings extrahiert, auch Plurals (`<plurals>` für "1 Event" / "N Events")
-- Wochentags-/Monatsnamen via `java.time.format.DateTimeFormatter` mit aktiver
-  Locale (kein Hardcoding)
-- Sprach-Override aus Settings via `AppCompatDelegate.setApplicationLocales`
-
-### Accessibility (V1-Minimum)
-- Alle interaktiven Elemente: `contentDescription`, Tap-Target ≥ 48dp
-- Event-Items: semantisches Label "Titel, Start-Zeit, Dauer, Kalender X"
-- Calendar-Color **immer** mit Label/Form kombiniert (nie nur-Farbe-Information)
-- Dynamic-Text-Size respektiert (keine fixen sp-Werte für Text)
-- Hoher-Kontrast: M3-Theme reagiert automatisch
-- TalkBack-Smoke-Tests im UI-Test-Plan
-
-## 10. Testing
-
-Best Practices, kein Diskussionsbedarf:
-- **Unit-Tests:** JUnit5 + Truth + Turbine. Repository, ViewModels, Date/Time-Helpers,
-  ContentResolver-Wrapper (mit Mock-Cursor)
-- **UI-Tests:** Compose UI Test pro Screen, mindestens `renders_loading` /
-  `renders_failure` / `renders_success` + 1-2 Interaktions-Tests
-- **Coverage-Ziel:** pragmatisch ~70% lines, 100% für Repository + Date-Logik.
-  Kein Coverage-Gate in CI, aber Pflicht-Run
-- **Instrumented-Tests:** nur für ContentResolver-Integration (echte
-  CalendarContract-Queries auf Emulator)
-
-## 11. CI/CD
-
-Adaption der `HouseHoldKeaper`-Pipeline, nur Flutter-Steps durch Gradle ersetzt.
-
-### `.gitea/workflows/ci.yaml` (push + PR)
-- Setup Java 17 + Android SDK 36
-- `./gradlew lint`
-- `./gradlew test`
-- `./gradlew assembleDebug`
-- Trivy Filesystem-Scan (HIGH/CRITICAL, `continue-on-error` wie HHK)
-
-### `.gitea/workflows/release.yaml` (auf Git-Tags)
-- Alles aus `ci.yaml`
-- Version aus Git-Tag in `app/build.gradle.kts`:
-  - `versionName = "${tag#v}"`
-  - `versionCode = MAJOR*10000 + MINOR*100 + PATCH` (HHK-Konvention)
-- Keystore aus Gitea Secrets (`KEYSTORE_BASE64`, `KEY_PASSWORD`, `KEY_ALIAS`)
-- `./gradlew assembleRelease`
-- F-Droid-Pipeline 1:1 wie HHK: Hetzner-Sync, `fdroid update -c`, Re-Upload
-
-### Repo-Konventionen
-- `CHANGELOG.md` wird beim Taggen gepflegt (patch/minor/major)
-- `fdroid-metadata/de.jeanlucmakiola.calendula/` Verzeichnis-Struktur
-- `LICENSE` = MIT, Jean-Luc Makiola, 2026
-- `.planning/` mit `PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md`, `STATE.md`
-
-## 12. Design-Decisions (gelöst)
-
-### Theme-Seed-Color (Fallback wenn kein Dynamic Color verfügbar)
-**`0xFF5C6B7A`** - desaturiertes Schiefer-Blaugrau.
-- Bewusst anders als HouseHoldKeaper's Sage (`0xFF7A9A6D`), damit beide Apps unterscheidbar sind
-- Mid-Saturation → M3 Expressive Dynamic Color generiert daraus eine ausgewogene Palette
-- Cool aber nicht kalt → passt zu "modern functional"
-- Funktioniert in Light- und Dark-Theme
-
-### App-Icon (Adaptive Launcher)
-**Statische "1" auf M3-Expressive-Squircle.**
-- **Foreground:** Stilisierte Ziffer "1" (bold), zentriert auf einem Squircle
-- **Background:** Seed-Color `0xFF5C6B7A` (slate)
-- **Bedeutung:** Die "1" referenziert *kalendae* (der erste Tag des Monats) - Wortwurzel sowohl von "Kalender" als auch "Calendula". Die App heisst Calendula, aber das Icon zeigt klar: dies ist ein Kalender.
-- Adaptive-Icon-Spec: Foreground 432dp x 432dp Safe-Zone in 108dp Tile, Background fest
-- Vektor-basiert (kein PNG), in `res/drawable/ic_launcher_*.xml` als VectorDrawable
-
-### Konkretes UI-Layout pro Screen
-**Bewusst offen** - wird in eigener UI-Design-Iteration nach Spec-Approval entworfen
-(Mockups pro Screen, alle drei States, vor Implementation).
-
-## 13. Nächste Schritte nach Spec-Approval
-
-1. Implementation-Plan via `writing-plans`-Skill aus diesem Spec ableiten
-2. Initiales Gradle-Projekt-Scaffolding
-3. Tooling: Lint-Config, Detekt o.ä., CI-Workflows initial
-4. Iterative UI-Design-Phase (Mockups pro Screen, alle drei States,
-   bevor implementiert wird)
-5. Feature-by-Feature-Implementation gegen den Plan