docs: add plugin feedback for Android post-reboot notification fallback text

Document bug where daily reminder shows fallback text after device restart
(Intent extras not surviving reboot). Includes root cause, recommended
plugin fixes (persist/restore title/body, use DB in recovery), and
verification steps for the daily-notification-plugin repo.

docs/plugin-feedback-android-post-reboot-fallback-text.md

@@ -0,0 +1,151 @@
+# Plugin feedback: Android daily notification shows fallback text after device restart
+
+**Date:** 2026-02-23  
+**Target repo:** daily-notification-plugin  
+**Consuming app:** crowd-funder-for-time-pwa (TimeSafari)  
+**Platform:** Android
+
+## Summary
+
+When the user sets a daily reminder (custom title/message) and then **restarts the device**, the notification still fires at the scheduled time but displays **fallback text** instead of the user’s message. If the device is **not** restarted, the same flow (app active, background, or closed) shows the correct user-set text.
+
+So the regression is specific to **post-reboot**: the alarm survives reboot (good), but the **content** used for display is wrong (fallback).
+
+---
+
+## Evidence from Logcat
+
+Filter: `DNP-SCHEDULE`, `DailyNotificationWorker`, `DailyNotificationReceiver`.
+
+**After reboot (boot recovery):**
+
+```
+02-23 16:28:44.489 W/DNP-SCHEDULE: Skipping duplicate schedule: id=daily_timesafari_reminder, nextRun=2026-02-24 16:28:44, source=BOOT_RECOVERY
+02-23 16:28:44.489 W/DNP-SCHEDULE: Existing PendingIntent found for requestCode=53438 - alarm already scheduled
+```
+
+So boot recovery does **not** replace the alarm; the existing PendingIntent is kept.
+
+**When the notification fires (after reboot):**
+
+```
+02-23 16:32:00.601 D/DailyNotificationReceiver: DN|RECEIVE_START action=com.timesafari.daily.NOTIFICATION
+02-23 16:32:00.650 D/DailyNotificationReceiver: DN|WORK_ENQUEUE display=notify_1771835520000 work_name=display_notify_1771835520000
+02-23 16:32:00.847 D/DailyNotificationWorker: DN|WORK_START id=notify_1771835520000 action=display ...
+02-23 16:32:00.912 D/DailyNotificationWorker: DN|DISPLAY_START id=notify_1771835520000
+02-23 16:32:00.982 D/DailyNotificationWorker: DN|JIT_FRESH skip=true ageMin=0 id=notify_1771835520000
+02-23 16:32:00.982 D/DailyNotificationWorker: DN|DISPLAY_NOTIF_START id=notify_1771835520000
+02-23 16:32:01.018 I/DailyNotificationWorker: DN|DISPLAY_NOTIF_OK id=notify_1771835520000
+```
+
+Important detail: the worker logs **`DN|JIT_FRESH skip=true`**, and there is **no** `DN|DISPLAY_STATIC_REMINDER`. So the **static reminder path** (title/body from Intent extras) is **not** used; the worker is using the path that loads content from Room/legacy and runs the JIT freshness check. That path is used when `is_static_reminder` is false or when `title`/`body` are missing from the WorkManager input.
+
+Conclusion: when the alarm fires after reboot, the receiver either gets an Intent **without** (or with cleared) `title`, `body`, and `is_static_reminder`, or the WorkManager input is built without them, so the worker falls back to Room/legacy (and possibly to NativeFetcher), which produces fallback text.
+
+---
+
+## Root cause (plugin side)
+
+### 1. PendingIntent extras may not survive reboot
+
+On Android, when an alarm is scheduled, the system stores the PendingIntent. After a **device reboot**, the alarm is restored from persisted state, but it is possible that **Intent extras** (e.g. `title`, `body`, `is_static_reminder`) are **not** persisted or are stripped when the broadcast is delivered. So when `DailyNotificationReceiver.onReceive` runs after reboot, `intent.getStringExtra("title")` and `intent.getStringExtra("body")` may be null, and `intent.getBooleanExtra("is_static_reminder", false)` may be false. The receiver still has `notification_id` (so the work is enqueued with that id), but the Worker input has no static reminder data, so the worker correctly takes the “load from Room / JIT” path. If the content then comes from Room with wrong/fallback data, or from the app’s NativeFetcher (which returns placeholder text), the user sees fallback text.
+
+### 2. Boot/force-stop recovery uses hardcoded title/body
+
+In `ReactivationManager.rescheduleAlarmForBoot` and `rescheduleAlarm` (and similarly in `BootReceiver` if it ever reschedules), the config used for rescheduling is:
+
+```kotlin
+val config = UserNotificationConfig(
+    ...
+    title = "Daily Notification",
+    body = "Your daily update is ready",
+    ...
+)
+```
+
+So whenever recovery **does** reschedule (e.g. after force-stop or in a code path that replaces the alarm), the new Intent carries this fallback text. In the **current** log, boot recovery **skips** rescheduling (duplicate found), so this is not the path that ran. But if in other builds or OEMs recovery does reschedule, or if a future change replaces the PendingIntent after reboot, the same bug would appear. So recovery should not use hardcoded strings when the schedule has known title/body.
+
+### 3. Schedule entity does not store title/body
+
+`Schedule` in `DatabaseSchema.kt` has no `title` or `body` fields. So after reboot there is no way to recover the user’s message from the plugin DB when:
+
+- The Intent extras are missing (post-reboot delivery), or  
+- Recovery needs to reschedule and should use the same title/body as before.
+
+The plugin **does** store a `NotificationContentEntity` (with title/body) when scheduling in `NotifyReceiver`, keyed by `notificationId`. So in principle the worker could get the right text by loading that entity when the Intent lacks title/body. That only works if:
+
+- The worker is given the same `notification_id` that was used when storing the entity, and  
+- The entity was actually written and not overwritten by another path (e.g. prefetch/fallback).
+
+If after reboot the delivered Intent has a different or missing `notification_id`, or the Room lookup fails (e.g. different id convention, DB not ready), the worker would fall back to legacy storage or fetcher, hence fallback text.
+
+---
+
+## Recommended fix (in the plugin)
+
+### A. Persist title/body for static reminders and use when extras are missing
+
+1. **Persist title/body (and optionally sound/vibration/priority) for static reminders**
+   - Either extend the `Schedule` entity with `title`, `body` (and optionally other display fields), or ensure there is a single, authoritative `NotificationContentEntity` per schedule/notification id that is written at schedule time and not overwritten by prefetch/fallback.
+   - When the app calls `scheduleDailyNotification` with a static reminder, store these values (already done for `NotificationContentEntity` in `NotifyReceiver`; ensure the same id is used for lookup after reboot).
+
+2. **In `DailyNotificationReceiver.enqueueNotificationWork`**
+   - If the Intent has `notification_id` but **missing** `title`/`body` (or they are empty), or `is_static_reminder` is false but the schedule is known to be a static reminder:
+     - Resolve the schedule/notification id (e.g. from `schedule_id` extra if present, or from `notification_id` if it matches a known pattern).
+     - Load title/body (and other display fields) from the plugin DB (Schedule or NotificationContentEntity).
+     - If found, pass them into the Worker input and set `is_static_reminder = true` so the worker uses the static reminder path with the correct text.
+
+3. **In `DailyNotificationWorker.handleDisplayNotification`**
+   - When loading content from Room by `notification_id`, if the entity exists and has title/body, use it as-is for display and **skip** replacing it with JIT/fetcher content for that run (or treat it as static for this display so JIT doesn’t overwrite user text with fetcher fallback).
+
+This way, even if the broadcast Intent loses extras after reboot, the receiver or worker can still show the user’s message from persisted storage.
+
+### B. Use persisted title/body in boot/force-stop recovery
+
+- In `ReactivationManager.rescheduleAlarmForBoot`, `rescheduleAlarm`, and any similar recovery path that builds a `UserNotificationConfig`:
+  - Load the schedule (and associated title/body) from the DB (e.g. from `Schedule` if extended, or from `NotificationContentEntity` by schedule/notification id).
+  - If title/body exist, use them in the config instead of `"Daily Notification"` / `"Your daily update is ready"`.
+  - Only use the hardcoded fallback when no persisted title/body exist (e.g. legacy schedules).
+
+This ensures that any time recovery reschedules an alarm, the user’s custom message is preserved.
+
+### C. Ensure one canonical content record per static reminder
+
+- Ensure that for a given static reminder schedule, the `NotificationContentEntity` written at schedule time (in `NotifyReceiver`) is the one used for display when the alarm fires (including after reboot), and that prefetch/fallback paths do not overwrite that entity for the same logical notification (e.g. same schedule id or same notification id). If the worker currently loads by `notification_id`, ensure that id is stable and matches what was stored at schedule time.
+
+---
+
+## App-side behavior (no change required for this bug)
+
+- The app calls `scheduleDailyNotification` once with `id: "daily_timesafari_reminder"`, `title`, and `body`. It does not reschedule after reboot; the plugin’s boot recovery and alarm delivery are entirely on the plugin side.
+- The app’s `TimeSafariNativeFetcher` returns placeholder text; that is only used when the plugin takes the “fetch content” path. Fixing the plugin so that after reboot the static reminder path (or Room content with user title/body) is used will prevent that placeholder from appearing for the user’s reminder.
+
+---
+
+## Verification after fix
+
+1. Set a daily reminder with a **distinct** custom message (e.g. “My custom reminder text”).
+2. **Restart the device** (full reboot).
+3. Wait until the scheduled time (or set it 1–2 minutes ahead for a quick test).
+4. Confirm that the notification shows **“My custom reminder text”** (or the chosen title), not “Daily Notification” / “Your daily update is ready” or the NativeFetcher placeholder.
+5. In logcat, after the notification fires, you should see either:
+   - `DN|DISPLAY_STATIC_REMINDER` with the correct title, or  
+   - A path that loads content from Room and displays it without overwriting with fetcher fallback.
+
+---
+
+## Files to consider in the plugin
+
+- **NotifyReceiver.kt** – Already stores `NotificationContentEntity` at schedule time; ensure the same `notificationId` used in the PendingIntent is the one used for this entity so post-reboot lookup by `notification_id` finds it.
+- **DailyNotificationReceiver.java** – In `enqueueNotificationWork`, add a fallback: if Intent has `notification_id` but no (or empty) `title`/`body`, look up title/body from DB (by `schedule_id` or `notification_id`) and pass them into Worker input with `is_static_reminder = true`.
+- **DailyNotificationWorker.java** – When loading from Room for a given `notification_id`, prefer that entity for display and avoid overwriting with JIT/fetcher content when the content is for a static reminder (e.g. same id as a schedule that was created as static).
+- **ReactivationManager.kt** – In `rescheduleAlarmForBoot` and `rescheduleAlarm`, load title/body from Schedule or NotificationContentEntity and use them in `UserNotificationConfig` instead of hardcoded strings.
+- **DatabaseSchema.kt** (optional) – If you prefer to keep title/body on the schedule, add `title` and `body` (and optionally other display fields) to the `Schedule` entity and persist them when the app calls `scheduleDailyNotification`.
+
+---
+
+## Short summary for Cursor (plugin-side)
+
+**Bug:** After Android device restart, the daily notification still fires but shows fallback text instead of the user-set message. Logs show the worker uses the non-static path (`JIT_FRESH`, no `DISPLAY_STATIC_REMINDER`), so Intent extras (title/body/is_static_reminder) are likely missing after reboot.
+
+**Fix:** (1) When the receiver has `notification_id` but missing title/body, look up title/body from the plugin DB (Schedule or NotificationContentEntity) and pass them into the Worker as static reminder data. (2) In boot/force-stop recovery, load title/body from DB and use them when rescheduling instead of hardcoded “Daily Notification” / “Your daily update is ready”. (3) Ensure the NotificationContentEntity written at schedule time is the one used for display after reboot (same id, not overwritten by prefetch/fallback).

package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "timesafari",
-  "version": "1.2.0",
+  "version": "1.3.2",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "timesafari",
-      "version": "1.2.0",
+      "version": "1.3.2",
       "dependencies": {
         "@capacitor-community/electron": "^5.0.1",
         "@capacitor-community/sqlite": "6.0.2",
@@ -9452,8 +9452,8 @@
       }
     },
     "node_modules/@timesafari/daily-notification-plugin": {
-      "version": "1.1.7",
+      "version": "1.1.8",
-      "resolved": "git+https://gitea.anomalistdesign.com/trent_larson/daily-notification-plugin.git#c2b1a608045abd403fd25732a10dff08f0a00014",
+      "resolved": "git+https://gitea.anomalistdesign.com/trent_larson/daily-notification-plugin.git#7188d32ae6cfd19f2120bd8e2026b557792b902a",
       "license": "MIT",
       "workspaces": [
         "packages/*"